--- 格式版本: 2 标题: "Keep Downstream Systems Current with Frequent Data Refresh V2 | analytics" 原文链接: "https://blogs.oracle.com/analytics/keep-downstream-systems-current-with-frequent-data-refresh-v2" 发布日期: "2026-08-21" 发布时间校准状态: "found" 发布时间需复核: "否" 发布时间来源: "rule:local:strict_original_body" 发布时间证据: "August 21, 2026 9 minute read" 发布时间校准原因: "规则确认唯一严格发布时间，来源 local:strict_original_body" 发布时间校准置信度: "high" 发布时间候选数量: 6 发布时间严格候选数量: 1 发布时间原页读取状态: "source template page reused from URL open" 发布时间未找到原因: "" 发布时间校准时间: "2026-08-21T10:05:59+08:00" 发布时间仲裁状态: "skipped" 发布时间仲裁尝试次数: 0 发布时间仲裁耗时毫秒: 0 发现时间: "2026-08-21T09:56:58+08:00" 入库时间: "2026-08-21T02:05:59.314Z" 来源平台: "固定入口" 搜索渠道: "fixed_url" 搜索词: "https://blogs.oracle.com/?page=news" 匹配关键词: [] 相关厂家: - "Oracle" 相关专家: [] 内容类型: "网页" 抓取工具: "CDP Render" 清洗工具: "CDP Text + Defuddle/Readability 正文提取" 原始附件: [] AI优质: "否" AI打分: 8 AI分档: "非优质" AI质检状态: "不通过" AI打分理由: "文章介绍Oracle Fusion Data Intelligence的FDR V2数据刷新功能，与超节点、AI Rack、机柜级AI基础设施、高速互连、供电散热等核心主题完全无关，属于明显无关内容。" AI质检模型: "tx-deepseek-v4-flash" AI质检时间: "2026-08-21T10:06:16+08:00" AI主题相关性: 0 AI来源权威性: 8 AI新颖性: 0 AI技术细节: 0 AI商业部署信号: 0 AI完整性: 0 AI摘要: "本文介绍如何配置 Oracle Fusion Data Intelligence (FDI) 的 Data Share 功能。" AI摘要模型: "ali-deepseek-v4-flash" AI摘要时间: "2026-09-07T02:13:13.666Z" 采集批次: "2026年8月21日9点50分40秒" 采集批次ID: "20260821-095040-035" 去重键: "https://blogs.oracle.com/analytics/keep-downstream-systems-current-with-frequent-data-refresh-v2" --- With input from Abhiram Gujjewar, Product Management, Oracle Fusion Data Intelligence This is Part 1 of a two-part blog on how to use the FDI platform for downstream integrations. - This article describes how to configure the FDI Data Share feature and publish FDR-enabled tables to Object Storage. - Read [Part 2](https://blogs.oracle.com/analytics/understanding-row-level-changes-with-table-change-format-in-oracle-fdi) to learn how to consume FDI data using the Table Change Format change feed. Oracle Fusion Data Intelligence (FDI) is a family of prebuilt, cloud-native analytics applications for Oracle Fusion Cloud Applications. It delivers ready-to-use insights and can be extended with additional data and semantic-model content. ## Why downstream data can fall behind Frequent Data Refresh V2 (FDR V2) keeps selected FDI data current throughout the day. But downstream applications that consume only the daily incremental load don’t see those intra-day changes until the next scheduled refresh. ## A common business scenario Consider accounts payable. Finance teams might update invoices several times during the day, while reporting systems, operational dashboards, or custom databases need those changes before the next daily load. Waiting can leave downstream decisions based on data that’s already out-of-date. FDR V2 closes this gap by capturing insertions, updates, and deletions during each frequent refresh. Downstream integration can consume those changes from the FDR Delta and delete tables or from change files published to Oracle Cloud Infrastructure (OCI) Object Storage. ## How FDR V2 represents the latest data When you enable FDR for a module, FDI creates a Lambda view that combines the stable daily-refresh data with the changes captured during frequent refreshes: - **Base table:** Stores data from the most recent daily incremental refresh and remains unchanged during an FDR run. - **Delta table:** Stores insertions and updates captured during each FDR run. - **Delete table:** Stores deletions captured during each FDR run. Depending on the implementation, an update can appear as a deletion followed by an insertion. Lambda view = Base table – Delete table + Delta table The Lambda view also applies the Oldest Data to Report setting. For example, if you retain 13 months, the view filters the base data to that period before applying the FDR changes. ![Lambda view query with a 13-month Oldest Data to Report filter.](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/Lambda_view.jpg) Lambda view query with a 13-month Oldest Data to Report filter ## Choose the downstream integration pattern This article focuses on OCI Object Storage because it separates change capture from downstream processing and provides a durable, structured handoff in Parquet format. For a decoupled integration that can scale across external targets, publish change files to OCI Object Storage. ## Recommended pattern: Publish changes to OCI Object Storage ### Before you begin You need, 1. Access to an OCI compartment where you can create a bucket or use an existing one, with the required IAM policies in place. 2. The Object Storage namespace and compartment OCID. The following workflow creates the bucket, configures an FDI target connection, publishes a warehouse table, and validates the exported change files. *Note: Feature names and labels can vary by release. Confirm the available options in your FDI environment and current Oracle documentation.* ### 1\. Create and authorize the Object Storage bucket 1. In the OCI Console, open **Storage**, and then select **Buckets**. ![Open Object Storage buckets from the OCI Console.](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/1-1.png) Open Object Storage buckets from the OCI Console 2. Select the target compartment, and then select **Create bucket**. ![Create a bucket in the selected compartment](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/2.png) Create a bucket in the selected compartment ![Complete the bucket settings and create the bucket](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/3-1.png) Complete the bucket settings and create the bucket 3. Add the required bucket policies. See the linked prerequisite topic in the Oracle documentation for the latest policy [guidance](https://docs.oracle.com/en-us/iaas/analytics-for-applications/doc/perform-prerequisites-sharing-warehouse-tables-oracle-cloud-infrastructure-object-storage-preview.html). `allow any-user to { BUCKET_INSPECT, BUCKET_READ, OBJECT_INSPECT, OBJECT_READ, OBJECT_OVERWRITE, OBJECT_CREATE, OBJECT_DELETE } in tenancy where all {     request.principal.type = 'fawbeyondpublish',     target.compartment.id = request.principal.compartment.id,     target.bucket.name = 'BUCKET_NAME_CREATED_BY_CUSTOMER' }` ### 2\. Create and test the FDI target connection 1. In the Oracle Fusion Data Intelligence Console, open **Manage Connections**. ![Open Manage Connections in the FDI Console](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/4-2.png) Open Manage Connections in the FDI Console 2. On the Manage Connections page, click **Create**, select **Data Publish** in **Usage Type**, select **Oracle Object Storage Service Targets** in **Connection Type** to create an Oracle Object Storage Service Targets connection. ![Select Oracle Object Storage Service Targets](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/5.png) Select Oracle Object Storage Service Targets 3. In the Oracle Object Storage Service Targets connection dialog, enter a meaningful name, a unique **Connection Code**, **Namespace**, **Bucket Name,** and **Compartment OCID**. Select **FDI\_TABLE\_CHANGE\_FORMAT** as the **Type**. ![Configure the Object Storage target connection](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/6.png) Configure the Object Storage target connection 4. Save the connection and then test it. 5. Open **Activity** and confirm that the test is completed successfully. ![Verify that the connection test completed successfully](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/7.png) Verify that the connection test completed successfully ### 3\. Enable Data Share for frequent refreshes 1. Open **Enable Features**. Under **Application Settings**, enable **Data Share**. Under **Pipeline Features**, enable **Data Share for Frequent Data Refresh**. ![Enable Data Share under Application Settings](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/8.png) Enable Data Share under Application Settings ![](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/9.png) Enable Data Share for Frequent Data Refresh under Pipeline Features 2. Under **Data Configurations**, select **Data Share**. ![Open Data Share under Data Configurations](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/10.png) Open Data Share under Data Configurations ### 4\. Publish the table and include FDR changes 1. On the Data Share page, find the warehouse table whose changes you want to publish, open its actions menu, and select **Edit**. ![Open the action menu for the warehouse table](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/11.png) Open the action menu for the warehouse table ![](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/12.png) Add the Object Storage target connection to the table 2. In Update Target Connections, add **Oracle Object Storage Service Targets** in **Target Connections**, and then select **Update**. 3. Select **Include Frequently Refreshed Data** to ensure that the share includes changes from FDR runs. ![Include frequently refreshed data in the share](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/13.png) Include frequently refreshed data in the share 4. Select the table, and then select **Publish**. FDI now writes table changes to the bucket according to the FDR schedule. ![Publish the selected table configuration](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/14.png) Publish the selected table configuration ### 5\. Validate the exported change files 1. Sign in to OCI and open the bucket used by the target connection. 2. Select **Objects** to review the files published by FDI. ![Open the Objects tab for the target bucket](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/15.png) Open the Objects tab for the target bucket ### 6\. Understand the Object Storage hierarchy FDI stores the changes as Parquet files in a predictable hierarchy: 1. Source, such as Fusion Applications or Oracle Analytics Publisher (BI Publisher or BIP). ![The first hierarchy level identifies the source](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/16.png) The first hierarchy level identifies the source 2. Warehouse table, such as DW\_AP\_INVOICE\_CF. ![The next level identifies the shared warehouse table](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/17.png) The next level identifies the shared warehouse table 3. SCN (System Change Number), such as fdi\_scn\_id=999999. ![Each frequent refresh is grouped by change SCN](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/18.png) Each frequent refresh is grouped by change SCN 4. Refresh type, such as Full, Incremental, or transient refresh for FDR V2. ![FDR V2 output uses the transient refresh type](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/19.png) FDR V2 output uses the transient refresh type 5. Change-type: insert, update, or delete. ![The change-type folder separates insertions, updates, and deletions](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/20.png) The change-type folder separates insertions, updates, and deletions 6. Open fdi\_change\_type=update to find the Parquet file that contains updated records. ![The update folder contains the corresponding Parquet file](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/21.png) The update folder contains the corresponding Parquet file 7. The export includes metadata that identifies: - Refresh completion - The exported schema - The latest change and most recent full refresh. ### 7\. Process the change records 1. Read the Parquet file and apply its records to the downstream target. ![Updated records read from the exported Parquet file](https://blogs.oracle.com/analytics/wp-content/uploads/sites/86/2026/08/22.png) Updated records read from the exported Parquet file 2. Process the insert and delete folders in the same way. Apply each change type using the target system’s merge rules so it remains synchronized with the latest FDR V2 state. ## Keep downstream data synchronized throughout the day FDR V2 makes intra-day warehouse changes available without waiting for the next daily incremental load. Publishing those changes in FDI Table Change Format to OCI Object Storage gives downstream teams a durable, scalable feed of insertions, updates, and deletions. Start with one high-value table, validate the target system’s merge behavior for every change type, and then expand the pattern to additional workloads. ## Call to action Try this pattern with a business process where intra-day changes materially improve decisions or operations. Share questions, implementation patterns, and feedback with your Center of Excellence or the Oracle Analytics Community. ### Related resources - [Oracle Fusion Data Intelligence documentation](https://docs.oracle.com/en/cloud/saas/analytics/26r1/fawag/administering-oracle-fusion-data-intelligence.pdf) - [Prerequisites for sharing warehouse tables with OCI Object Storage](https://docs.oracle.com/en-us/iaas/analytics-for-applications/doc/perform-prerequisites-sharing-warehouse-tables-oracle-cloud-infrastructure-object-storage-preview.html) - [Row Level Changes with Table Change Format](https://blogs.oracle.com/analytics/understanding-row-level-changes-with-table-change-format-in-oracle-fdi) - [Oracle Fusion Data Intelligence](https://www.oracle.com/business-analytics/fusion-data-intelligence/) - [Oracle Analytics Community](https://community.oracle.com/products/oracleanalytics/)