Forum Discussion
Incremental Refresh
Hi Anonymous
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 Anonymous
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.