Frequent Data Refresh V2 FAQs - A Complete Scheduling and Management Guide
Updated: Oct 19
At a glance - Frequent Data Refresh V2 gives Oracle Fusion Data Intelligence a faster, lighter way to keep data current between full incremental loads - but lambda views, delta tables, and FDR flags behave differently from what you're used to. Here's a quick, practical rundown of how scheduling and semantic-model management actually work.
◷ Scheduling Frequent Data Refresh V2
Control, Delta Tables, and Lambda Views:
No lockout, but full visibility: Oracle doesn't restrict other users from changing schedules you created - but audit history lets you track every change made.
Tables build and reset themselves: Lambda and delta tables - even for custom facts and dimensions - are created automatically when you run a refresh. Delta tables aren't cleared after every run, though; they're truncated only when the next incremental refresh happens.
V1 vs. V2: V1 updated the same base warehouse tables as the incremental refresh. V2 instead stores changes in delta tables while lambda views blend base data with those changes, resetting each incremental cycle - a more efficient design that supports higher-frequency refreshes. Oracle recommends every V1 customer migrate.
Moving data downstream: For enterprise data lake integrations, capture data changes rather than pulling from lambda views or delta tables directly.
Limits, Support, and Scaling:
Two hard limits: FDR V2 doesn't capture hard deletes from Oracle Fusion Cloud Applications, and you can't schedule bi-weekly refreshes multiple times a day.
V1 support and pricing: Oracle still supports V1 but recommends upgrading; talk to your account representative about licensing and cost when migrating.
Need more than 20 tables? Ask Oracle Support to raise your limits - higher limits can carry cost implications, and adding more modules or tables can affect performance, so scale thoughtfully.
Finding filter columns: For the Oldest Date to Report field, check the Recommended Tbls FilterDateCols tab in the FDR V2 database objects spreadsheet. Check pillar lineage for ERP and SCM.
⚙︎ Managing Frequent Data Refresh V2 in the Semantic Model
What's Automatic vs. Manual:
Mixed availability: Some refreshed data becomes available in the semantic model automatically; other scenarios require manually adding it. Oracle documents examples for enabling FDR V2 in semantic model extensions, as well as scenarios that aren't supported at all.
Configuring the FDR Flag:
Custom subject areas don't inherit it: Even if derived from a prebuilt subject area using FDR-recommended tables, you must manually go to the semantic model extensions page, expand the “FDR flag” folder under Available Data Elements, and add it as a filter.
The module has to be active: Selecting only the recommended fact table isn't enough the functional area's module must also be enabled, or the flag won't appear in the subject area.
But modules alone are sufficient: Enabling a required module without picking specific tables still triggers FDR for every supported fact in it, automatically applying the folder and flag to the recommended facts and their degenerate dimensions.
Automatic linking is limited to three cases: An extended prebuilt fact, or an adjoined degenerate dimension of a new or existing data augmentation. Every other data augmentation needs a manual semantic model extension.
The One-Flag Rule:
One subject area, one flag: Even with multiple fact tables, use only one FDR flag - it's enough to pull intra-day data for every supported fact in that functional area.
Conformed dimensions need a manual push: Enabling FDR V2 across a functional area, fact, and conformed dimension flags the facts and their degenerate dimensions automatically, but you still have to manually switch the conformed dimension itself.
Reports, Joins, and Edge Cases:
Pick one view, not both: You can't show new and existing data together without changing the flag - enable it with lambda views or disable it for the base table. Lambda views show no data while an incremental refresh is in progress.
Prebuilt workbooks: Since they're read-only, copy the workbook first, then add the FDR flag as a filter on your copy.
Joins and system extensions: Standard joins between custom dimensions and prebuilt facts switch automatically to the lambda fact; complex joins must be defined manually. And if “Manual Execution of Apply System Extensions” is enabled, you must apply system extensions before the flag becomes visible.
Key Things to Remember -
Lambda and delta tables build automatically on every refresh - delta tables reset with the next incremental refresh, and hard deletes aren't captured.
One FDR flag per subject area covers intra-day data for every supported fact, no matter how many fact tables are involved.
Custom subject areas and conformed dimensions need a manual step to get the FDR flag - it doesn't carry over automatically.
You can view lambda data or base-table data, not both at once, and lambda views go empty mid-refresh.
Oracle recommends migrating from V1 to V2 for better performance; check with your account rep on licensing.
Ready to Put Frequent Data Refresh V2 to Work?
Whether you’re upgrading from V1 to reduce pipeline friction, configuring lambda views for custom subject areas, or setting up high-frequency intra-day reporting across your ERP, SCM, and HCM modules, this release gives you a powerful framework to streamline your data pipelines.
Frequent Data Refresh V2 only pays off once your refresh schedules, lambda views and FDR flags are set up around how your teams actually report. CLODAIN’s Quick Start Configuration gets Oracle Fusion Data Intelligence deployed, connected and validated in a 8 week engagement, so your ERP, SCM and HCM data stays fresh where it matters.
→ See where you stand: Take the free Oracle FDI Readiness Assessment.
→ Or talk it through: Book a free introductory call to map out your FDI architecture and align your refresh schedules with where your business is headed next!!