Many teams hesitate to use Oracle Fusion BI Publisher for data extraction after reading Oracle's guidance that flags it as an anti-pattern. That guidance is easy to misread. Oracle is not saying never use BI Publisher to extract data. It is saying that a specific way of using it puts the platform under strain.
This article explains that nuance and shows how BI Connector lets you extract all the data you need, without row limits, while staying fully within Oracle's guidance.
The concern: is BI Publisher an anti-pattern for data extraction?
Oracle's A-Team article on synchronous BI Publisher extraction is often quoted as a blanket warning. Read closely, it targets how BI Publisher is used, not the module itself. Oracle flags three usage patterns as problematic:
- Extracting a large volume of data in a single fetch
- Synchronous fetches that hold the connection open until all rows return
- Firing a large number of concurrent requests at the platform
How BI Connector aligns with Oracle's guidance
BI Connector is designed around exactly these three points. It fetches all the data you need, with no row limits, by turning one risky pattern into three safe ones:
- Optimal-volume extraction — large datasets are fetched in automatically sized batches, never in one giant pull.
- Asynchronous fetch — data is pulled on a schedule you control, using incremental loads.
- Controlled concurrency — simultaneous requests are capped and spread out.
1. Optimal-volume extraction through automatic chunking
The most common worry is: "We need to extract a large volume of data through BI Publisher, but Oracle advises against it." The nuance usually missed is volume per fetch, not total volume. If a Data Model returns 10 million rows, it is pulling all 10 million in one go that Oracle warns against, not the fact that you need them.
BI Connector's chunking engine handles this automatically. It breaks the extraction into manageable batches and makes as many round-trips as needed to fetch every row, so a large dataset is retrieved as a series of small, server-friendly fetches rather than a single heavy request.
2. Asynchronous, scheduled data fetch
BI Connector extracts data asynchronously. You schedule a refresh and the data is pulled in the background on your cadence.
For Fusion raw tables, the standard approach is the incremental load: the full table is pulled only once, for the initial load. Every run after that pulls only new or changed rows, tracked by an id column or a date column such as last_updated_date, typically once or twice a day.
3. Controlled number of concurrent requests
For data pipelines
BI Connector's pre-built pipeline templates for Microsoft Fabric and ADF / Azure Synapse are configured to control the number of concurrent requests automatically, so you stay within safe concurrency without manual tuning.
For Power BI and Tableau refreshes
Here you set the cadence, so schedule with concurrency in mind:
- Make full use of the incremental load option instead of full refreshes.
- Schedule the majority of report refreshes during non-peak hours.
- During peak hours, keep scheduled refreshes low and limited to critical reports only (preferably incremental), so people reading reports directly in BI Publisher and the background Power BI / Tableau refresh jobs do not compete for the same resources.
- Refresh only when needed. A month-end report only needs to run near month-end. Use the options in Power BI or Tableau to maximise the time between refreshes while still meeting user needs.
Key takeaways
What would you like to do next?
| Next step | Go to |
|---|---|
| Get started with BI Publisher Data Models in BI Connector | Set Up a BI Connector Data Source |