Quando um modelo semantico do Power BI cresce para dezenas de gigabytes, o comportamento padrao da plataforma deixa de ser suficiente. Refresh completo estoura a janela, o commit de memoria dobra durante a atualizacao e o dataset simplesmente para de abrir no Service. A resposta nao e \"comprar mais capacidade\" — e mudar o formato de armazenamento e orquestrar o refresh no nivel de particao via XMLA. Este post trata do que muda na pratica para quem opera modelos grandes em Premium/Fabric.
\nO que o Large semantic model storage format realmente faz
\nPor padrao, um dataset usa o formato small, que carrega o modelo inteiro na memoria como um unico bloco e tem limite rigido de tamanho. O Large semantic model storage format (ligado por dataset nas Settings, ou via API/Capacity settings) muda a representacao interna para um formato paginavel, apoiado em armazenamento premium, com estas consequencias concretas:
\nNao e um botao gratuito: ligar large format em datasets pequenos pode ate piorar performance de carga inicial. O ganho aparece em modelos grandes, com refresh particionado e muitos usuarios concorrentes.
\nPor que o refresh completo nao escala e onde entram as particoes
\nUm refresh completo reprocessa todas as tabelas do zero. Numa fato de 400 milhoes de linhas, isso significa reler a fonte inteira toda noite, reconstruir todos os dicionarios VertiPaq e dobrar o commit de memoria no processo. O incremental refresh (RangeStart/RangeEnd) resolve parte disso criando particoes automaticas por periodo — mas ele e uma caixa fechada: voce nao controla quando cada particao e processada, nao reprocessa uma particao historica pontualmente e nao combina facilmente janelas de granularidade diferentes.
\nCom XMLA read/write, voce assume o controle das particoes manualmente (via TMSL no SSMS, Tabular Editor ou a API de refresh enhanced). Isso abre cenarios que o incremental sozinho nao cobre:
\nOs tipos de operacao de refresh que importam
\nO modelo tabular nao tem so \"refresh\" — e aqui mora a diferenca entre estourar ou nao a memoria. Ao disparar via XMLA/TMSL ou enhanced refresh API, voce escolhe o processing type:
\nO padrao escalavel e um Data em paralelo por particao seguido de um unico Calculate no modelo no final. Processar Data nas particoes quentes e um Calculate global custa muito menos memoria e tempo do que N refreshes Full. O parametro de maxParallelism na enhanced refresh API controla quantas particoes processam juntas — mais paralelismo acelera, mas aumenta o pico de commit.
\nControle de memoria: o que derruba o dataset em producao
\nTres limites da capacidade decidem se o refresh conclui:
\nMedir isso nao e opcional: a Metrics App da capacidade (Fabric/Premium) e as DMVs via XMLA (como $System.discover_memoryusage) mostram onde a memoria esta indo. Em producao, o diagnostico comeca por olhar o pico de commit durante a janela de refresh, nao a media.
Um padrao de referencia para modelo corporativo grande
\nPara um dataset de dezenas de GB servindo centenas de usuarios:
\nQuando isso ainda e exagero
\nSe o modelo cabe confortavelmente no formato small, tem refresh que termina dentro da janela e nao sofre com memoria, ligar large format e orquestrar XMLA so adiciona complexidade operacional sem retorno. O gatilho e concreto: modelo grande + janela de refresh apertada + necessidade de reprocessar particoes seletivamente + muitos usuarios concorrentes. Abaixo disso, incremental refresh nativo resolve.
\nArquitetar modelos semanticos grandes, calibrar capacidade Fabric/Premium e montar esteiras de refresh via XMLA e exatamente o tipo de trabalho em que a Dynamic Solucoes atua. Se sua empresa opera datasets corporativos no limite da janela de atualizacao, nossos planos de suporte e consultoria em dados ajudam a tirar o maximo da plataforma sem desperdicio de capacidade.
\nWhen a Power BI semantic model grows into the tens of gigabytes, the platform's default behavior stops being enough. A full refresh blows past the window, memory commit doubles during the update, and the dataset simply stops opening in the Service. The answer isn't \"buy more capacity\" — it's changing the storage format and orchestrating refresh at the partition level via XMLA. This post covers what actually changes for teams running large models on Premium/Fabric.
\nWhat Large semantic model storage format really does
\nBy default, a dataset uses the small format, which loads the entire model into memory as a single block and has a hard size cap. The Large semantic model storage format (enabled per dataset in Settings, or via API/Capacity settings) switches the internal representation to a pageable format backed by premium storage, with these concrete consequences:
\nIt's not a free switch: enabling large format on small datasets can actually hurt initial load performance. The payoff shows up in large models, with partitioned refresh and many concurrent users.
\nWhy full refresh doesn't scale and where partitions come in
\nA full refresh reprocesses every table from scratch. On a 400-million-row fact table, that means rereading the entire source every night, rebuilding every VertiPaq dictionary, and doubling memory commit in the process. Incremental refresh (RangeStart/RangeEnd) solves part of this by creating automatic partitions by period — but it's a closed box: you don't control when each partition is processed, you can't reprocess a single historical partition on demand, and you can't easily combine windows of different granularity.
\nWith XMLA read/write you take manual control of partitions (via TMSL in SSMS, Tabular Editor, or the enhanced refresh API). That opens scenarios incremental alone doesn't cover:
\nThe refresh operation types that matter
\nThe tabular model doesn't just have \"refresh\" — and this is where the difference between blowing memory or not lives. When triggering via XMLA/TMSL or the enhanced refresh API, you choose the processing type:
\nThe scalable pattern is a parallel Data per partition followed by a single model-wide Calculate at the end. Processing Data on the hot partitions plus one global Calculate costs far less memory and time than N Full refreshes. The maxParallelism parameter in the enhanced refresh API controls how many partitions process together — more parallelism speeds things up but raises the commit peak.
\nMemory control: what takes the dataset down in production
\nThree capacity limits decide whether the refresh completes:
\nMeasuring this isn't optional: the capacity Metrics App (Fabric/Premium) and DMVs via XMLA (such as $System.discover_memoryusage) show where memory is going. In production, diagnosis starts by looking at the commit peak during the refresh window, not the average.
A reference pattern for a large corporate model
\nFor a dataset of tens of GB serving hundreds of users:
\nWhen this is still overkill
\nIf the model fits comfortably in small format, refreshes finish within the window, and memory isn't an issue, enabling large format and orchestrating XMLA only adds operational complexity with no return. The trigger is concrete: large model + tight refresh window + need to selectively reprocess partitions + many concurrent users. Below that, native incremental refresh does the job.
\nArchitecting large semantic models, sizing Fabric/Premium capacity, and building XMLA-based refresh pipelines is exactly the kind of work Dynamic Solucoes does. If your company runs corporate datasets at the edge of the refresh window, our support plans and data consulting help you get the most out of the platform without wasting capacity.
"}},"pageContext":{"slug":"/blog/power-bi-large-semantic-models-xmla-escala/","previousPost":null,"nextPost":{"frontmatter":{"title":"Dataverse: business rules vs client scripting em model-driven"},"fields":{"slug":"/blog/dataverse-business-rules-vs-client-scripting-model-driven/"}}}},"staticQueryHashes":["2269431855"]}