F64 Import Model Refresh Fails Due to Memory: Can Data Duplication Be Avoided
Hello, We are experiencing refresh failures for a large Power BI Import semantic model on an F64 Microsoft Fabric capacity. The refresh fails because the operation exceeds the available memory. Our main objective is to resolve the refresh failure. We are also trying to understand how the model is compressed and which objects consume the most storage, because reducing the model size may help reduce the refresh-time memory requirement. Current Environment The semantic model contains three fact tables and multiple dimension tables. The data source is an Azure Synapse Analytics dedicated SQL pool. The semantic model and reports run on an F64 Microsoft Fabric capacity. The semantic model uses Import storage mode. The semantic model size is approximately 14.8 GB. We import only the columns required for reporting, relationships, calculations, and security. One fact table contains approximately 3.8 billion rows. This large fact table is divided into partitions of approximately 100 million rows using XMLA. We refresh only the partitions that contain changed data. The other two fact tables have been denormalized by adding only the required descriptive attributes that were previously obtained from dimension tables. We denormalized those two fact tables because some table visuals were failing with the following error when using the normalized design: Query exceeded available resources. The denormalized design improved the table visual behaviour, but it increased the semantic model size. Main issue: Refresh failure due to memory usage Even though we refresh only the affected partitions of the 3.8-billion-row fact table, the semantic model refresh is failing because of the memory constraint on the F64 capacity. We would like to understand how memory is used during an Import semantic model refresh. Our understanding is that Power BI needs to preserve the currently queryable version of the model or partition while it processes a new version. This could temporarily require memory for both existing and newly processed data, along with additional memory for compression, dictionaries, relationships, indexes, and transaction commit operations. Could you please clarify the exact refresh behaviour? Specifically: Does Power BI temporarily maintain two copies of the complete semantic model, or only two versions of the partition being refreshed? Which model structures may be duplicated or rebuilt during a partition refresh? How much additional working memory is normally required beyond the stored semantic model size? Could a 14.8 GB semantic model exceed the F64 memory limit during refresh because the existing model, refreshed partition, dictionaries, relationship indexes, and processing workspace are held in memory at the same time? Does refreshing one partition at a time materially reduce peak memory, or can model-level structures still cause high memory consumption? Can refresh-time model duplication be disabled? Is there any supported way to prevent or reduce the apparent duplication of data during refresh? For example, can an Import refresh directly modify or update the existing data in a partition instead of building a separate replacement version and switching to it after processing completes? We would like to know whether any of the following is possible: Update existing compressed data in place. Append new rows directly to an existing processed partition. Delete or modify individual rows without recreating the affected partition. Disable the refresh transaction or shadow-copy behaviour. Disable the retention of the old partition version during processing. Commit the refresh in smaller stages to reduce peak memory. Release the old partition from memory before loading the replacement. Process only model metadata, relationships, or calculations without creating another data copy. Configure a lower-memory refresh mode for large Import semantic models. Control the number of rows or segments processed in each refresh transaction. If in-place updates or disabling refresh-time duplication are not supported, what is the recommended approach for refreshing a model of this size on F64? We understand that transactional refresh behaviour may be required to keep the existing semantic model available to report users and to allow rollback if processing fails. However, we would like confirmation of whether this behaviour can be changed or optimized. VertiPaq dictionary and compression question We are also investigating which columns contribute most to the semantic model size. Consider the following simplified example: LargeFact[EntityIdentifier] SecondFact[EntityIdentifier] EntityDimension[EntityIdentifier] All three columns use the same data type and contain many of the same identifier values. Does VertiPaq create: one shared dictionary for the identifier across the complete semantic model, one dictionary per table, one independent dictionary per physical column, or separate dictionaries or encoding structures at the partition or segment level? Does the relationship between the fact and dimension tables allow the key dictionaries to be reused, or does every physical column maintain its own dictionary and encoded value storage? For example, suppose the fact table containing 3.8 billion rows has a foreign-key column referencing another table. If that foreign-key column contains substantially fewer distinct values than the total row count, is its storage broadly composed of: a dictionary containing the distinct values, encoded references for the 3.8 billion rows, column segments, relationship indexes, hierarchy structures, and other internal storage objects? We would like to understand whether the storage is primarily caused by: the dictionary, the encoded values across 3.8 billion rows, internal relationship structures, partition-related structures, or a combination of these. Storage query used I used the following DAX query to identify the columns and internal storage objects consuming the most space: // Check largest storage entity EVALUATE VAR SegmentSizes = GROUPBY ( INFO.STORAGETABLECOLUMNSEGMENTS(), [TABLE_ID], [COLUMN_ID], "Records", SUMX ( CURRENTGROUP(), [RECORDS_COUNT] ), "SegmentUsedBytes", SUMX ( CURRENTGROUP(), [USED_SIZE] ), "SegmentAllocatedBytes", SUMX ( CURRENTGROUP(), [ALLOCATED_SIZE] ) ) VAR ColumnDetails = SELECTCOLUMNS ( INFO.STORAGETABLECOLUMNS(), "TABLE_ID", [TABLE_ID], "COLUMN_ID", [COLUMN_ID], "Table", [DIMENSION_NAME], "Column", [ATTRIBUTE_NAME], "ColumnType", [COLUMN_TYPE], "DataType", [DATATYPE], "Encoding", [COLUMN_ENCODING], "DictionaryBytes", [DICTIONARY_SIZE] ) VAR Combined = NATURALLEFTOUTERJOIN ( SegmentSizes, ColumnDetails ) RETURN SELECTCOLUMNS ( Combined, "Table", [Table], "Column or object", [Column], "Object type", [ColumnType], "Data type", [DataType], "Encoding", [Encoding], "Records", [Records], "Segment MB", DIVIDE ( [SegmentUsedBytes], 1024 * 1024 ), "Dictionary MB", DIVIDE ( [DictionaryBytes], 1024 * 1024 ), "Approximate total MB", DIVIDE ( [SegmentUsedBytes] + COALESCE ( [DictionaryBytes], 0 ), 1024 * 1024 ), "Allocated MB", DIVIDE ( [SegmentAllocatedBytes], 1024 * 1024 ) ) ORDER BY [Approximate total MB] DESC The query showed identifier columns from multiple tables among the largest storage objects. The most significant result was a foreign-key column in the 3.8-billion-row fact table. The query reported that this column, or its related internal storage object, was consuming up to approximately 13 GB. Could you please confirm whether this query correctly estimates storage usage by column or internal storage object? Main questions Our primary questions are: How can we resolve the refresh failure caused by the F64 memory constraint? Does Import refresh temporarily duplicate the complete model, or only the affected partition and related structures? Is there any supported way to update an existing Import partition in place? Can refresh-time duplication or transactional processing be disabled? Is there a supported configuration that reduces peak refresh memory? Is the storage query above correct, particularly the approximately 13 GB reported for a foreign-key object? Are VertiPaq dictionaries maintained per column, per table, per partition, or per model? What architecture would Microsoft recommend for an Import semantic model containing a 3.8-billion-row fact table on F64? Our immediate objective is to complete the refresh successfully. Model-size optimization is important mainly because it may reduce the peak memory required during processing. At the same time, we need to avoid reintroducing the 'Query exceeded available resources.' error in the report table visuals. Thank you.
Barra de formula do Power BI
Estou com um problema de interface no Power BI Desktop na Exibição de Relatório. Quando clico em 'Nova medida' ou tento editar uma medida existente, a barra de fórmulas DAX não aparece na parte superior da tela de jeito nenhum (ela só funciona e aparece quando mudo para a Exibição de Tabela). Detalhes do meu ambiente: Na guia 'Exibição' do menu superior, a opção/caixa de seleção 'Barra de fórmulas' não existe. Já tentei clicar com o botão direito na medida e selecionar 'Editar', mas a barra continua oculta. A barra de opções superior está visível, mas a caixa de texto para digitar a fórmula DAX não abre no modo de relatório. Como posso resolver esse problema de interface no Power BI Desktop para forçar a barra de fórmulas a reaparecer na Exibição de Relatório?Share your thoughts on the New Power Query experience in Power BI Desktop (Preview)
Update (September 2026): The new Power Query experience in Power BI Desktop now includes both Get Data and Power Query Editor in preview. When we opened this thread in May, the preview focused on Get Data and the new editor was still ahead of us. You can now try the redesigned editor too, and we'd love your feedback on the full experience. We're working toward a more consistent, accessible, and streamlined way to prepare data across Power BI Desktop and other Power Query experiences. The preview now covers: Get Data: Discover data sources, use recent connections or the OneLake catalog, and start a connection in the redesigned flow. Power Query Editor: Shape your data using the ribbon, Queries pane, data preview, and Applied steps. You can also explore schema and diagram views, and edit M in the formula bar or Advanced Editor. How to try it: In Power BI Desktop, go to File > Options and settings > Options > Preview features, select New Power Query experience, and choose OK. The same preview setting enables both Get Data and the new editor. Select Transform data on the Home tab to open Power Query Editor. It's still a preview. Some connectors and workflows use the legacy experience, and there are known limitations in both Get Data and the editor. If a limitation blocks your work in Desktop, you can clear the New Power Query experience preview checkbox to return to the legacy experience; no restart is needed. The limitations article explains specific gaps and workarounds, including where that fallback applies. Learn more: Get Data in Power BI Desktop (new experience) Power Query Editor in Power BI Desktop (new experience) Known limitations and workarounds We still want to hear from you. What works well in Get Data or the editor? What's missing or getting in your way? If you encounter an issue, please tell us where it happened, what you expected, and what happened instead. Share your thoughts in the replies below, and please avoid posting credentials or confidential data. Thanks for helping us improve Power Query!How can i Join (create relationship) multiple tables in Power BI
Dear Team, I am reaching out to you to requested your support in linking (Join) these three tables. In fact, I would like to link (join) these three tables in order to carry out the following analyses: - Number of projects recorded per cluster - Number of projects reported per cluster - Number of projects recorded by Admin1 - Number of organisations (T_Organisation) recorded by Admin1 - Comparison of recorded projects and reported projects by cluster - Comparison of recorded projects and reported projects by Admin1 Note: The Cluster column in the tables (T_Project and T_Reporting) is a multi respons column with values separated by commas. Please see the snapshot below and enclosed the Excel file as an example.
Power BI Business Central Connector – Header Table Loading Issue
Subject Power BI – Business Central Connector: Header Table Taking Excessively Long to Load Problem Description We are using the Dynamics 365 Business Central connector in Power BI. The connector is working successfully for other related tables: Line table – loads successfully. Customer table – loads successfully. Header table – takes significantly longer to load/evaluate and remains in a prolonged loading state. Important Validation We have validated the same Header data source directly within Business Central. The following are working as expected from the Business Central side: Header table is accessible and functioning normally. The related API is also working as expected. We are not seeing the same prolonged loading behavior within Business Central. The issue is observed specifically when the data is consumed through Power BI using the Business Central connector. Validation Performed We have already checked: Business Central environment Company selection Connector configuration Authentication/access Environment parameters Table selection Required columns Power Query transformations We also tested the Header table with minimal Power Query transformations, but the prolonged loading/evaluation time continues. The other related tables using the same connector configuration load successfully. Assistance Required We would like Microsoft Support to investigate why the Header table works normally within Business Central but takes significantly longer to load through the Power BI Business Central connector. Specifically, please help us determine whether the behavior could be related to: Business Central connector behavior. Power BI–Business Central communication. API/OData response handling. Server-side processing or response time. Data volume or server-side paging. Connector timeout/request handling. Business Central Web Service configuration. Any known issue or limitation affecting this type of table through the Power BI connector. We would also appreciate checking whether there are any long-running requests, throttling, timeout conditions, or server-side errors when the Header data is requested from Power BI. Expected Outcome We would like to identify the root cause of the prolonged loading time and determine whether the issue requires a change in: Power BI Business Central connector Business Central API/OData configuration Business Central server-side settings We can provide Power BI diagnostic information, screenshots, timestamps, session/activity IDs, Power Query code, and refresh details if required.
Reports shared via dashboard not showing up in Recent/Favorites areas
I shared a dashboard with several reports on it. And multiple users have experienced viewing reports, favoriting them, and then having them not show up on the Recent or Favorites areas on the Home page or Browse page. Once I shared the report with them directly and not only via sharing the dashboard, it then appeared in both areas of Power BI Service. This is incredibly annoying as sharing via dashboards is how I share most content so that I do not need to go to multiple reports to share with users and only have to share one dashboard. (We do not use Apps for the most part, just dashboards. So that's not going to be a solution). Has anyone else experienced this? I feel like it is a bug, but can't find any information on this scenario anywhere.
Dynamic default Year Value
Hello ! I'm looking for a way to have a Year slicer that displays all available years, while automatically selecting the current year by default (e.g., 2026 today, 2027 next year). The default selection should be dynamic, so that when users open the report or use "Reset to default," the slicer automatically points to the current year. Is there a native Power BI solution to achieve this behavior? Thank you !
