Categories
- All Categories
- Oracle Analytics and AI Learning Hub
- 44 Oracle Analytics and AI Sharing Center
- 20 Oracle Analytics and AI Lounge
- 278 Oracle Analytics and AI News
- 56 Oracle Analytics and AI Videos
- 16.2K Oracle Analytics and AI Forums
- 6.4K Oracle Analytics and AI Labs
- Oracle Analytics and AI User Groups
- 103 Oracle Analytics and AI Trainings
- 20 Oracle Analytics and AI Challenge
- Find Partners
- For Partners
Question on FDR v2: Data Access Security (Row‑Level) Refresh Timing
Our FDI implementation began last year leveraging FDR v1. During SIT, it became clear that production go‑live on FDR v1 would not be supported, as our instance was not grandfathered under the original eligibility model.
As we assess the required transition to FDR v2, we’ve identified a clarification point that is not explicitly addressed in the available documentation.
To avoid confusion up front, this is not about duty roles, authentication, or OCI IAM. Those sync independently.
This question is specifically about data access security (row‑level / data‑level security) — i.e., what data a user can see after they successfully log in — which is populated through the Fusion Data Intelligence data pipeline.
Why this matters
Before enabling Frequent Data Refresh, changes to data access security only became effective after the large incremental or full pipeline refresh. While FDR was clearly introduced to support intra‑day visibility of financial and other fast‑moving data, in practice FDR v1 also resulted in data access security being refreshed intra‑day (24 time a day), which significantly improved user onboarding, access correction, and revocation timeliness.
With FDR v2:
- The refresh mechanism has changed
- The set of tables eligible for frequent refresh is more explicitly scoped
- Some non‑transactional datasets are excluded by design
What isn’t clear from the documentation is whether data access security continues to participate in frequent refresh, or whether it now remains tied to daily/incremental refresh cycles.
Operational impact if security refresh lags behind data refresh
If data refresh is intra‑day but data access security refresh is not:
- New users may log in successfully but see no data
- Access fixes may appear to “not work” until the next day
- More importantly, access revocations may not take effect within the hour, creating a temporary over‑provisioning window
Even same‑day lag can drive ticket re‑opens, manual workarounds, and uncomfortable governance conversations.
Question to the group / Oracle
Has anyone:
- Confirmed whether data access security (row‑level security) participates in FDR v2 frequent refresh?
- Observed changes in grant/revoke timing after upgrading?
- Received guidance from Oracle on how security freshness is intended to align with data freshness in FDR v2?
Answers
-
In FDR 2.0 there is an option to pick user table to refresh. Is your FDI environment integrated deployment or standalone?
0
