Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!The Power BI Data Visualization World Championships is back! Get ahead of the game and start preparing now! Learn more
I have implemented incremental refresh in power bi for my dataset and wanted to validate something about the initial seeding refresh behavior.scenario:
1. Total data range: 6 months
2. Refresh policy: Store 6 months, refresh 1 day
3. Two large fact tables with multiple use cases.
4. source: Oracle
5. Workspace: Premeium
I used RangeStart and RangeEnd parameters in Power Query.Instead of loading all 6 months at once, i split the range into multiple 1.5 month chunks(eg., apr-may, may-june, etc)Pulished each version seperately and manually refreshed in pbi service to seed the data month by month. after completing 6 months,(Note: All the partitions took 2 to 3 hrs for the successful refresh) i created one more pbix file with one date range and enabled incremental refresh (6months, 1 day).
Now when i publish and try to refresh, it fails - the incremental refresh doesnt seem to recognize or build from the seeded data. (Note: loading all the 6 months data and refresh got fail after 5hrs)
****We are in critical deadline. please help us.
Solved! Go to Solution.
Hi @VMariapp
Your issue arises because the incremental refresh in Power BI is partition-aware only within the same dataset—it cannot recognize or build on previously published “seeded” datasets, even if those contain identical table structures or date ranges. When you manually split and published data in multiple PBIX files (each covering partial ranges such as April–May, May–June, etc.), Power BI treated those as separate datasets, not as preloaded partitions of a single dataset. Therefore, when you later published the consolidated PBIX with incremental refresh enabled, Power BI attempted to perform a full initial refresh to generate its own partition structure (for the 6-month storage policy), which explains why it failed after several hours—your model was trying to reload all data from Oracle in one go.
The correct approach is to configure incremental refresh in a single PBIX file from the beginning, publish it once, and then allow Power BI Service to perform the initial full load (the first refresh builds all partitions internally). Once this seeding is complete, subsequent refreshes will process only the 1-day refresh range as defined. Unfortunately, there’s no supported way to manually seed data across multiple datasets and have Power BI “merge” or reuse them as part of an incremental refresh. Given your time constraints, the best recovery option is to increase refresh capacity (by assigning the dataset to a larger Premium capacity or temporarily increasing resources), optimize your Oracle query performance (using query folding or pre-aggregations), and perform a single full refresh to establish the incremental refresh partitions properly. Once seeded, the subsequent daily refreshes will be much faster and stable.
Hi @VMariapp
Your issue arises because the incremental refresh in Power BI is partition-aware only within the same dataset—it cannot recognize or build on previously published “seeded” datasets, even if those contain identical table structures or date ranges. When you manually split and published data in multiple PBIX files (each covering partial ranges such as April–May, May–June, etc.), Power BI treated those as separate datasets, not as preloaded partitions of a single dataset. Therefore, when you later published the consolidated PBIX with incremental refresh enabled, Power BI attempted to perform a full initial refresh to generate its own partition structure (for the 6-month storage policy), which explains why it failed after several hours—your model was trying to reload all data from Oracle in one go.
The correct approach is to configure incremental refresh in a single PBIX file from the beginning, publish it once, and then allow Power BI Service to perform the initial full load (the first refresh builds all partitions internally). Once this seeding is complete, subsequent refreshes will process only the 1-day refresh range as defined. Unfortunately, there’s no supported way to manually seed data across multiple datasets and have Power BI “merge” or reuse them as part of an incremental refresh. Given your time constraints, the best recovery option is to increase refresh capacity (by assigning the dataset to a larger Premium capacity or temporarily increasing resources), optimize your Oracle query performance (using query folding or pre-aggregations), and perform a single full refresh to establish the incremental refresh partitions properly. Once seeded, the subsequent daily refreshes will be much faster and stable.
Hi @VMariapp ,
Thank you for reaching out to the Microsoft Community Forum.
As you mentioned that, When your are trying to refresh, it is failing. Their are various reasons for refresh fail. Could you please share the failed or error screenshot for this issue, it will help us to assist you to fix the issue.
Regards,
Dinesh
Hi @VMariapp ,
We haven’t heard from you on the last response and was just checking back to see. Please provide the failed or error screenshot for this issue, it will help us to assist you to fix the issue.
Regards,
Dinesh
Hi @VMariapp ,
We haven’t heard from you on the last response and was just checking back to see. Please provide the failed or error screenshot for this issue, it will help us to assist you to fix the issue.
Regards,
Dinesh
The Power BI Data Visualization World Championships is back! Get ahead of the game and start preparing now!
| User | Count |
|---|---|
| 58 | |
| 56 | |
| 35 | |
| 18 | |
| 14 |