Forum Discussion
Helper ISuper long refresh times despite incremental refresh
Anonymous Hi!
After some more experimenting and remaking all the calculated columns, reinstalling power bi etc it now works. I also noticed during on of the tests where a refresh took 2 hours, that it completed with a warning, and that warning was referencing a table that wasn't even loaded into the model.
So seems that perhaps some metadata or other stuff had been slightly corrupted? Either way now after rebuild it's only taking 3 minutes to refresh, with the idenditcal aggregation etc...
Super UserGood follow-up questions!
Model 1 — pivoting: It depends on what "pivot" means in context. If you mean transposing wide columns into rows (unpivoting), that would actually help a lot — fewer columns means less VertipAQ encoding work, and narrow tall tables compress far better than wide flat ones. If you mean something else, share more detail. But as a general rule: reducing from 45 columns to something leaner (even 20-25) would noticeably cut that VertipAQ CPU time.
Model 2 — the execution delay: You're right that the actual processing in the logs is trivial — the real work takes maybe 3-4 minutes total. The 110-minute wait is entirely executionDelayMs, which is capacity queuing, not your transformation. The transformation itself isn't the problem at all.
The reason capacity queuing happens even at 40-50% compute is that Premium capacity throttling isn't purely CPU-based — it uses a CU (Capacity Unit) smoothing algorithm that averages usage over a 24-hour rolling window. If earlier jobs consumed a burst of CUs, your capacity can be in a throttled state even while the instantaneous CPU looks fine. Check the Fabric Capacity Metrics app and look at the CU smoothing chart around the time of the refresh — you'll likely see the throttling period clearly there, even if the raw compute graph looks okay.
Short-term fix: schedule model 2's refresh during off-peak hours when the CU bucket has recovered.
Helper IThanks again,
Yes that's what I meantwith pivoting, it did however having the effect of running out of memory when trying to refresh the model:
Data source errorResource Governance: This operation was canceled because there wasn't enough memory to finish running it. Either reduce the memory footprint of your dataset by doing things such as limiting the amount of imported data, or if using Power BI Premium, increase the memory of the Premium capacity where this dataset is hosted. More details: consumed memory 24880 MB, memory limit 24775 MB, database size before command execution 824 MB
For model 2, I did try and recreate the model one table at a time and at every step it worked perfectly and eventually the whole model was uploaded in and it all worked great, the only thing that wasn't added to the model was the measures. Other than that the model was exactly the same. Except for the final step, when I added a direct query to one of our large semantic models that feeds a couple of other reports. Then it stopped refreshing and we encounterd the previously mentioned super long execution delay.
Which is very weird, since it's working with a bunch of other reports?
Also weird is that the version of this report that is in the production workspace also has this connection and there it works?
Hi F003Yum ,
What you’re seeing comes down to two separate issues. For the first model, the memory error after unpivoting shows that the problem isn’t just VertiPaq CPU but the memory required during processing. While unpivoting reduces columns, it significantly increases row count and cardinality, which can quickly push you over the capacity limit. Instead of unpivoting, a better approach here would be to keep the table narrower without increasing rows, for example splitting the 45 column table into a fact table and a few dimension or attribute tables, and reducing high cardinality columns like text or timestamps.
For the second model, the key clue is that everything works fine until the DirectQuery connection to another semantic model is added. At that point, the dataset becomes a composite model, which introduces cross model dependencies and can lead to Premium capacity queuing. The long executionDelayMs means the refresh is waiting for resources rather than actually processing, even if CPU usage looks low. The reason it works in other reports or production is likely due to differences in capacity load or timing. The most reliable fix is to avoid using DirectQuery to another semantic model in this dataset, either pull the data directly from the source like Snowflake or move that DirectQuery piece into a separate dataset and keep this model import only. If that’s not possible, scheduling during off peak hours can help, but the root issue is architectural rather than performance tuning.
- F003Yum
Anonymous
Hi, thanks for the assist,
I'm now mostly having issues with the second model. For some reason the first just started working on its own.
The second is still behaving very weird.
Like previously mentioned I tried creating a separate file and re-adding one table with all transformations and calculations at a time, + the same incremental refresh settings, and it worked great that way. But then got stuck when adding the connection to the other semantic model.
I've now added the needed table from that model into this report, which is only 240k rows across 7 columns, for one month. And the incremental settings is 12 months archive 14 days refresh. And the only transformations are some filters and removing columns.
So this should be a very fast refresh.
But now yesterday it again took almost hours and failed the second after running for 5 hours!!
Here's the log of the successful run that took forever:
{
"timeStart": "2026-03-12T15:22:45.2800000Z",
"timeEnd": "2026-03-12T17:16:51.5990000Z",
"durationMs": 6846319,
"externalQueryExecutionTimeMs": 158280,
"vertipaqJobCpuTimeMs": 55469,
"mEngineCpuTimeMs": 44234,
"queryProcessingCpuTimeMs": 1156,
"totalCpuTimeMs": 7405500,
"executionDelayMs": 1701765,
"approximatePeakMemConsumptionKB": 12120131,
"tabularConnectionTimeoutMs": 17999000,
"commandType": "Batch",
"discoverType": 129,
"queryDialect": 4,
"refreshParallelism": 6,
"vertipaqTotalRows": 362835436,
"intendedUsage": 2,
"mEnginePeakMemoryKB": 1116324,
"qsoReplicaVersion": 134178094053182000
}- F003Yum
Anonymous
Here's another execution log from Power BI service, this time there's no delay, but it's still taking two hours despite the snowlake queries and processing is 20 minutes total (this refresh was a full refresh across 12 months)
{
"timeStart": "2026-03-19T09:05:03.7350000Z",
"timeEnd": "2026-03-19T11:07:23.4060000Z",
"durationMs": 7339671,
"externalQueryExecutionTimeMs": 572287,
"vertipaqJobCpuTimeMs": 279266,
"queryProcessingCpuTimeMs": 1750,
"totalCpuTimeMs": 9037406,
"executionDelayMs": 465,
"approximatePeakMemConsumptionKB": 13291915,
"tabularConnectionTimeoutMs": 17999000,
"commandType": "Batch",
"discoverType": 129,
"queryDialect": 4,
"refreshParallelism": 6,
"vertipaqTotalRows": 428585739,
"intendedUsage": 2,
"mEngineCpuTimeMs": 348906,
"mEnginePeakMemoryKB": 4295808
}