Forum Discussion
Semantic Model Incremental Schedule Refresh
Hii All,
We have created a semantic model using OData connector to get data from BC. And incremental refresh is configured for semantic model. It is noticed that on demand refresh is taking lesser time as compared to scheduled refreshes.
Has anyone else also noticed something similar? Apart from other entity consuming capacity at similar time, could there be any other reason?
Hi Saum02,
Yes, this can happen, but I would not expect scheduled refresh to be inherently slower simply because it is scheduled.
Microsoft documents both on-demand semantic model refresh and scheduled semantic model refresh as background operations, and both should apply the same incremental refresh policy.
I would first check whether you are comparing the actual refresh duration in Refresh history or the elapsed time from the scheduled time.
Microsoft notes in the scheduled refresh documentation that a scheduled refresh is targeted to start within 15 minutes of the configured time, but it can be delayed by up to an hour if the service cannot allocate resources. A manual refresh started at a quieter time would not necessarily see the same delay.
Since your source is Business Central through OData, I would also check the source side rather than only Fabric capacity.
Business Central has documented OData concurrency and rate limits, and requests can be queued or throttled when the service is busy. Microsoft's Business Central web-service performance guidance specifically calls out 429, 503 and 504 responses for throttling, temporary unavailability and long-running requests.
If your scheduled refresh runs at the same time as other BC integrations, API jobs or reporting workloads, the OData source could therefore be slower even when the Fabric capacity itself is not heavily loaded.
I would also verify query folding for the incremental-refresh table.
Microsoft's incremental refresh troubleshooting guidance explains that Power BI creates a query for each partition. The RangeStart and RangeEnd filters should ideally be pushed back to the source. If they are not folding correctly, significantly more data can be retrieved than expected.
My troubleshooting order would be:
- compare actual Refresh history durations rather than scheduled start times
- check the Fabric Capacity Metrics app for contention/throttling at both timestamps
- check whether the RangeStart/RangeEnd filters are folding to Business Central
- check Business Central telemetry/logs for OData throttling or slow requests during the scheduled window
- compare whether the same number of incremental partitions were processed in both runs
If the manual and scheduled runs process the same partitions with the same folded source queries, but the scheduled run is still consistently slower, the timing of capacity usage and Business Central OData activity would be the next places I would investigate.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
5 Replies
Murtaza_GhafoorSuper User
Apart from capacity contention, I suggest to check these settings:
Query folding — verify that the RangeStart/RangeEnd filters are pushed down to the BC OData source.
Incremental refresh partitions — confirm scheduled and on-demand refreshes are processing the same partitions.
BC OData/API response time — source-side throttling or variable response times can impact refresh duration in your case.
And finally check the fabric capacity metrics app.
Capacity metrics — check CU, memory pressure, and concurrent workloads during the refresh window.Refresh history — compare actual processing duration versus any scheduling/start-up delay.For an OData-based model, query folding and source-side response time would be the first areas to investigate and Microsoft Power BI API service response timings could also be reason for the delay.
If this helps, ✓ Mark as Kudos | Help Other
v-sathmakuriCommunity Support
Hi Saum02 ,
Could you review the suggestion provided above and let us know if you have any additional questions, we are happy to address.
Thanks!!
- v-sathmakuri
Hi Saum02 ,
Could you check the suggestion provided above and let us know if you have any additional queries?
Thanks!!
- ShivekMaharaj
Community Champion
Hi Saum02,
Yes, this can happen, but I would not expect scheduled refresh to be inherently slower simply because it is scheduled.
Microsoft documents both on-demand semantic model refresh and scheduled semantic model refresh as background operations, and both should apply the same incremental refresh policy.
I would first check whether you are comparing the actual refresh duration in Refresh history or the elapsed time from the scheduled time.
Microsoft notes in the scheduled refresh documentation that a scheduled refresh is targeted to start within 15 minutes of the configured time, but it can be delayed by up to an hour if the service cannot allocate resources. A manual refresh started at a quieter time would not necessarily see the same delay.
Since your source is Business Central through OData, I would also check the source side rather than only Fabric capacity.
Business Central has documented OData concurrency and rate limits, and requests can be queued or throttled when the service is busy. Microsoft's Business Central web-service performance guidance specifically calls out 429, 503 and 504 responses for throttling, temporary unavailability and long-running requests.
If your scheduled refresh runs at the same time as other BC integrations, API jobs or reporting workloads, the OData source could therefore be slower even when the Fabric capacity itself is not heavily loaded.
I would also verify query folding for the incremental-refresh table.
Microsoft's incremental refresh troubleshooting guidance explains that Power BI creates a query for each partition. The RangeStart and RangeEnd filters should ideally be pushed back to the source. If they are not folding correctly, significantly more data can be retrieved than expected.
My troubleshooting order would be:
- compare actual Refresh history durations rather than scheduled start times
- check the Fabric Capacity Metrics app for contention/throttling at both timestamps
- check whether the RangeStart/RangeEnd filters are folding to Business Central
- check Business Central telemetry/logs for OData throttling or slow requests during the scheduled window
- compare whether the same number of incremental partitions were processed in both runs
If the manual and scheduled runs process the same partitions with the same folded source queries, but the scheduled run is still consistently slower, the timing of capacity usage and Business Central OData activity would be the next places I would investigate.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
