QueryWell
For ERP, data & audit leadsPractitioner guide

How to replicate Oracle Fusion tables
into a database you own

Oracle Fusion Cloud exposes no SQL*Net or JDBC, so "replicate the table" really means "choose an extraction surface and build a loader around it." There are five routes worth knowing, each designed for a different job. Here is what Oracle's own guidance says about them, what a correct mirror has to get right, and where a scoped, governed desktop replicator fits — and where it doesn't.

See the Data Loader Start a free 14-day trial
Why it's harder than it sounds

Three facts about Fusion that shape every replication design

None of these are quirks. They are how a multi-tenant SaaS ERP protects its own database — and every route below is an answer to them.

There is no database connection

Toad, SQL Developer, Data Pump and GoldenGate all need a listener. Fusion Cloud doesn't publish one. Everything leaves the pod through a supported application surface — bulk extract tooling, REST, BI Publisher, or a packaged analytics service — and each surface has its own throughput, paging and timeout behaviour.

Secured views declare no keys

The views you can query through BI Publisher expose no primary-key constraints, so a naive loader can't tell an update from a new row. Fusion's own application dictionary does record the keys for its base tables — a mirror that reads them can MERGE; one that doesn't is stuck with full reloads or duplicates.

The pod is shared, and Oracle says so

Oracle's April 2026 extraction guidance is blunt: "Avoid using REST API / SOAP services for extracting/exporting high-volume data set," and custom-SQL BI Publisher reports for extracts should consider "performance, timeout, file size, and formatting." Any route that pulls through a reporting surface must pace itself. Oracle A-Team, Data Extraction Options and Guidelines, April 2026

The routes

The five routes compared — and where the Data Loader fits

Most replication debates go wrong by comparing tools built for different jobs. Start from the job.

Route Built for Where the data lands Incremental? What to watch
Oracle's bulk extract tooling
Data Extraction Tool (26A+) and BICC (BI Cloud Connector), the extract it is positioned to replace		Whole-pillar warehouse feeds — every object, every nightFiles in OCI Object Storage; you build or buy the pipeline that loads them into a database (Oracle Data Transforms is one)Yes, on supported objectsNeeds OCI storage, a load pipeline and Oracle Support to enable the 26A tool; object coverage is still being added; CX not yet covered
Oracle Fusion Data IntelligencePackaged, Oracle-maintained analytics on Fusion dataAn Oracle-managed Autonomous Data Warehouse provisioned with the subscriptionYes, Oracle-scheduledA product, not a table you administer: subscription pricing, Oracle's model and refresh cadence, extensibility through its own tooling
REST APIsReal-time, record-level integrationWherever your integration writesBy query filter, if you build itOracle advises against REST for high-volume extraction; pages of up to 500 rows via offset paging, and paging behaviour varies by resource
BI Publisher scheduled reportsReporting, and small-to-medium scheduled file dropsA file on FTP, UCM or email; you build the loadOnly if your SQL and your loader both track a watermarkOracle discourages custom-SQL BIP reports for extraction; you own timeouts, chunking, resume and key handling
Third-party ELT connectors and analytics platformsMulti-source warehouses on a subscriptionUsually the vendor's cloud, then your warehouseUsuallyPer-user or per-row subscriptions and, commonly, a managed data layer between you and your own ERP data — a residency question as much as a cost one
QueryWell Data LoaderScoped, governed mirrors — GL and AP, not the whole pod — into a database you already runYour own Oracle Autonomous Database, over ORDSYes — watermark refresh with MERGE on Fusion's real keysOracle ADB targets only; LOB columns excluded; deletes detected, not propagated; paced by a pod request budget

Not on the list: desktop SQL tools. Fusion Cloud exposes no SQL*Net or JDBC endpoint, so Toad, SQL Developer and their kin cannot connect at all, regardless of credentials.

Doing it properly

What a correct mirror has to get right

Whichever route you take, the same four problems turn up. This is the checklist to hold any tool — including ours — against.

  1. 1

    Read the schema and the real key from the dictionary

    Column names, types, precision and nullability should come from the pod's dictionary, not from guessing at a CSV — and so should the primary key, validated against the pod. A table with a key can MERGE; a table without one needs a reload-and-swap that never leaves the target half-loaded. Decide up front what happens to LOBs, XMLTYPE and time-zoned timestamps.

  2. 2

    Load in chunks you can replay

    Keyset-paginate, keep each request inside the surface's timeout, and make every chunk idempotent so a failure mid-table resumes rather than restarts. Verify staged rows against applied rows before moving on.

  3. 3

    Refresh on a watermark — with an overlap

    Track LAST_UPDATE_DATE per table in the target itself, so lineage survives reinstalls. Re-read a few minutes behind the watermark on every run: late-committing transactions are normal in Fusion, and idempotent loads make the overlap free.

  4. 4

    Pace the pod and keep a ledger

    Bound how many requests you hold open against the pod, back off on 429/503, and record every load somewhere an auditor can read — ideally in the pod, where the policy that allowed it also lives.

Where QueryWell fits

A scoped, governed mirror — engineered around all four

The Data Loader is not a whole-pod warehouse feed; that is what Oracle's bulk tooling exists for. It is for the team that needs a handful of modules in a database it already governs, refreshed unattended, with an audit trail — without a vendor analytics cloud in the middle.

How it answers the checklist

  • Schema and keys — table structures read from the pod and recreated near 1:1 on your Autonomous Database over ORDS, with primary keys read from Fusion's application dictionary; full reload only when a table genuinely has none. Oracle's Always Free tier works for evaluation and modest replicas
  • Chunks — keyset-paginated chunks through BI Publisher, staged and applied in one set-based MERGE, verified chunk by chunk; failed chunks re-run harmlessly and runs resume after a restart
  • Watermark — LAST_UPDATE_DATE tracked in a QW_LOAD_STATE table in your own schema, with a 5-minute overlap window on every refresh
  • Pacing and ledger — one pod request budget bounds every simultaneous report request across all tables and runs, backing off automatically on 429/503; every load is written to a registry-governed audit ledger in the pod's BI Catalog
  • Unattended — schedule from every 15 minutes to weekly; close the window and QueryWell stays in the menu bar or tray, with a desktop notification when a run completes

Honest limits

  • Oracle Autonomous Database targets only today (ORDS REST-enabled SQL)
  • LOB, RAW, CLOB, BLOB and XMLTYPE columns are excluded, with a visible warning; TIMESTAMP WITH TIME ZONE lands as plain TIMESTAMP
  • Deletes at source are detected by an optional sweep, never propagated automatically
  • Watermark columns must be DATE or TIMESTAMP; rows with a NULL watermark are skipped by incremental refresh
  • It pulls through BI Publisher, the surface Oracle reserves for reporting — which is exactly why the pod request budget exists: faster per call, not louder on your pod
  • Pace is measured, not promised: on our test environment, a million-row table lands in about 3 minutes across four bounded streams

Which route should you actually pick?

If the requirement is "every object from every pillar into a lake, nightly," use Oracle's bulk extract tooling — BICC or the 26A Data Extraction Tool — and a pipeline; that is the job it was built for. If the requirement is packaged dashboards with no engineering, Fusion Data Intelligence is the packaged answer. If the requirement is "GL, AP and a few HCM tables in the Oracle database our team already runs, refreshed every hour, with an audit trail and no new subscription," that is a scoped mirror — and it is what the Data Loader was built for.

Common questions

Replicating Fusion tables — the questions that come up

Can I connect SQL Developer or Toad directly to Oracle Fusion Cloud?

No. Fusion Cloud does not expose a SQL*Net or JDBC endpoint to customers, so desktop database tools cannot connect regardless of credentials. Replication has to go through a supported application surface.

Can I replicate Fusion tables with the REST APIs?

For record-level, near-real-time integration, yes. For bulk table replication Oracle's own guidance advises against it: results page at up to 500 rows with offset paging, and paging behaviour differs between resources.

Can BI Publisher replicate a table incrementally?

Only if you build the rest: a watermark in your SQL, chunking inside the report timeout, a resumable loader and key handling on the target. That loader is what the Data Loader is — it uses the same supported BI Publisher surface, and adds the schema, key, watermark and governance work around it.

Why does an incremental refresh re-read rows that didn't change?

Because a correct mirror re-reads a short overlap window behind its stored watermark to catch transactions that committed late. With idempotent MERGE loads the overlap costs nothing and the target row count doesn't move.

Does replicating Fusion data into my own database change my data-residency position?

It can improve it: the copy lives in a database in a region you chose, under access controls you administer, with no vendor analytics cloud holding a second copy. The pod-side registry can restrict loads to approved targets only. See Oracle Fusion reporting with data residency.

How much does replicating Fusion tables cost?

With the Data Loader, a perpetual Studio licence plus a database you already govern — Oracle's Always Free Autonomous tier is enough to evaluate. There is no per-user-per-month analytics layer and no per-row metering. See pricing.

References

Oracle's own guidance, not forum folklore

Oracle official

Practitioner & community

Mirror the modules you need into a database you already own

Evaluate the Data Loader on your own Fusion pod for 14 days — point it at an Autonomous Database, scope GL and AP, and watch the first tables land.

Start a free 14-day trial See the Data Loader