Oracle CDC: stream Oracle changes to new systems while Oracle stays in production

Oracle often sits at the centre of systems that cannot stop: billing, finance, core operations. When the organisation modernises, the new pieces need Oracle's data, and they need it current. A nightly export answers yesterday's question; Oracle change data capture delivers each committed change, in order, while Oracle keeps serving production. It is used in three situations:

• A phased migration. A new database is loaded once, then kept in step with Oracle through a parallel run. Our Oracle migration page covers the full route.
• New services. New applications consume changes from a stream instead of querying the production database.
• Analytics. A separate copy is fed continuously, so heavy queries leave Oracle.

The general mechanics are in our change data capture guide; this page covers the Oracle side.

Relatedchange data capture guide

Three common ways to find what changed all apply to Oracle:

• Polling a "last changed" column. Simple, but heavier as tables grow, and blind to rows deleted outright.
• Triggers that write each change to a change table. They see deletes, but add work to every write and become part of the schema.
• Reading the log of committed changes, in Oracle the redo log and its archived copies. No change to the application or tables and little added load, so it is the usual choice for production.

Streaming Oracle to Kafka lets new services react to an order, a payment or a status change without touching the production database. Apache Kafka is among the systems iblync's website lists; the exact pairing for your versions is confirmed in scoping. The design points that decide whether the stream can be trusted:

• Topics and keys. Usually one topic per table or entity, keyed by the primary key, so changes to one record stay in order.
• Duplicates. After a restart a change can arrive twice, so consumers must handle repeats safely.
• Schema changes. A new or renamed column changes the event shape; agree how consumers learn about it.
• Sensitive columns. Decide which columns may leave Oracle at all, and mask or drop the rest.

A live stream needs watching: consumer lag, broker health, throughput. Our Kafka monitoring page covers that side.

iblync is Interkey's own data migration and replication platform, built in Saudi Arabia for moving data between systems that were not designed to exchange it. Oracle is on its published connector list. For Oracle real-time replication it brings the parts that protect production and the target:

• Continuous replication after one initial load, and two-way synchronisation where both sides must accept writes.
• Throttling, so replication does not compete with production, even while catching up after an outage.
• A queue that holds changes while the target is unavailable and delivers them when it returns.
• Resume and validation. iblync's site states that interrupted work resumes where it stopped and that validation uses checksums and row counts.

Relatediblyncreal-time replication page

A change stream is production data in motion, so residency applies to it too. Many Saudi organisations must keep certain data inside the Kingdom under the National Cybersecurity Authority's controls (nca.gov.sa) and the Personal Data Protection Law overseen by SDAIA (sdaia.gov.sa). Where the capture process, the queue and the target run is confirmed per engagement, against your residency rules, before the first change moves. Our data residency guide lists the questions to settle.

Support comes from Riyadh, in Arabic and English, from scoping through operation.

Relatednca.gov.sasdaia.gov.sadata residency guide

If a target only needs yesterday's figures, a scheduled batch load is simpler. If you are moving one Oracle database to another and the downtime window is enough, Oracle's own tooling is the first thing to evaluate, and iblync may not be needed. And a replicated copy is not a backup: a table deleted by mistake is deleted on the target too.

We do not publish a price or a duration for Oracle CDC, because the estate decides both. The drivers are:

• tables in scope and daily change volume;
• the number of targets and how far their data models are from Oracle's;
• how fast the target must follow Oracle;
• approvals from the Oracle and security teams;
• where the bridge must run;
• whether the stream is temporary or permanent.

Scoping turns these into a schedule and a quotation. Deciding between batch loads and a stream? Our ETL vs CDC comparison sets out the trade-offs.

RelatedETL vs CDC comparison