Oracle Fusion BICC incremental extraction: what actually controls what you get
Why the same rows keep coming back, why a “full load” returns 43 rows, and the two job settings that really decide what an extract contains.
BICC (BI Cloud Connector) is Oracle's supported way to bulk-extract Oracle Fusion Cloud data. Every extract is a job over one or more PVOs (Public View Objects), and each job carries metadata that decides which rows come back. Most “BICC is re-extracting everything” or “my full load is missing data” problems come down to two settings people don't look at closely enough.
The two controls: lastExtractDate and filters
| Setting | Where it lives | What it does |
|---|---|---|
lastExtractDate | Job data-store metadata; BICC advances it after each run | BICC's own watermark. A non-null value caps what the next run returns. |
filters | Job data-store metadata (a SQL predicate) | An explicit row filter — typically a window on the PVO's …LastUpdateDate columns. |
initialExtractDate | Job data-store metadata | The starting point used when no lastExtractDate exists yet. |
Symptom 1: the same rows come back every run
A classic report: a PVO returns the same handful of rows on every incremental run, even though the job's
lastExtractDate advances each time. The rows are real — they're the most recently changed records — but
they keep reappearing long after the watermark has moved past their LastUpdateDate.
The cause is relying on BICC's cached watermark alone. Depending on tenant configuration it does not gate the
extract the way you expect. What reliably gates it is a filters predicate. Setting the predicate to a
future window returns 0 rows; widening it changes the count — proof that the predicate is the control.
*LastUpdateDate columns,
col >= TIMESTAMP 'last_watermark' AND col <= TIMESTAMP 'now', OR-ed together. Advance your
watermark only after the run is delivered.(ProjectBasePEOLastUpdateDate >= TIMESTAMP '2026-09-20 22:00:00'
AND ProjectBasePEOLastUpdateDate <= TIMESTAMP '2026-09-27 22:00:00')Symptom 2: a “full load” returns almost nothing
The opposite trap. You clear the filter and fire the job to backfill — and get a fraction of the table. In one case, the same PVO returned:
| How it was fired | Rows |
|---|---|
| Incremental fire with an empty lower bound | 0 |
No filter, but the old lastExtractDate left in place | 43 |
Job re-created with lastExtractDate = null | 225,903 |
A stale lastExtractDate silently caps the extract. For a true full load, re-create (or re-PUT) the job
with lastExtractDate: null and an empty filter, then fire it once.
Always count rows from the status file
Each BICC run writes an EXTRACT_STATUS_…JSON alongside its data. Its statuses[].rowCount is
the authoritative count. Don't infer “0 rows” from a missing zip: zips are named by batch number, not request ID, and
an empty window produces no data file at all.
Checklist
- Own the watermark per PVO; drive incrementals with a
filterswindow. - Full load =
lastExtractDate: null+ empty filter, not an incremental fire with an empty bound. - Read
rowCountfrom the status JSON. - Watch for watermarks that stop advancing — self-heal them from the source's max
LastUpdateDate.
See it on your own Fusion data
The free SQL editor queries tables and PVOs, and the catalog shows every PVO's columns and underlying SQL.
Request free access