0x01 / SCENARIO
Selected data. Another place.
Replicate selected tables to Oracle, PostgreSQL or Db2. No need to move the whole world when you need a part of it.
ORA-600 / CHARON / 0x600
Charon. A passage for your data.
Logical change replication from Oracle. Internals on our side. Data where you need it.
ORA-600 ENGINEERING / LOGICAL REPLICATION
Not magic.
We know our way through redo.
Charon moves logical changes from Oracle to Oracle, PostgreSQL and IBM Db2. Harvester captures. Weaver applies. Between them is something more important than a pretty arrow: the transaction boundary.
Run the crossing ↓
ORACLE INTERNALS. REAL ENGINEERING.
Follow one transaction.
Choose a stage or run the animation. Timing is illustrative — this is a mechanism, not a benchmark.
CAPTURE / ORACLE LOGMINER
Oracle decodes. We take it from there.
Oracle LogMiner interprets physical redo and change vectors. Charon reads SQL_REDO, assembles fragments and passes logical changes to the common pipeline.
- REDODBMS_LOGMNR
Oracle performs redo mining.
- ORACLE MININGV$LOGMNR_CONTENTS
Oracle returns SQL_REDO and metadata.
- CHARON / COLLECTORSQL_REDO → XID
Charon joins fragments and tracks transactions.
- COMMON PIPELINEminedRecord
Next: mapping, .dml and the COMMIT gate.
CAPTURE / CHRNATIVE / NO ORACLE LOGMINER
We take redo apart. Vector by vector.
Here, our own code does the mining. Charon reads physical redo, interprets change vectors and reconstructs logical operations itself. No DBMS_LOGMNR and no SQL_REDO fetched from V$LOGMNR_CONTENTS. “Manual” means our decoder — not a person transcribing logs.
- PHYSICAL READCURRENT / ARCHIVE
Read bytes from redo files.
- CHANGE VECTORSBYTES → VECTORS
Our own change-vector parsing and decoding.
- CHARON / DECODERStreamDecoder / XID
Assemble complete logical operations in transaction context.
- LOGICAL DMLEvent → minedRecord
Common format. The same mapping, .dml and COMMIT.
Above: inside Harvester. Below: the full flow. Reading and decoding change; the “apply only after COMMIT” rule does not.
SOURCE / ORACLE
Where change begins.
Oracle records changes in redo. Charon captures them with the selected provider: Oracle LogMiner or Native Redo.
HARVESTER / LOGMINER
Oracle decodes. Charon captures.
DBMS_LOGMNR starts mining. Oracle interprets change vectors and exposes SQL_REDO in V$LOGMNR_CONTENTS. Charon’s Collector reads the result, joins fragments and tracks XIDs.
MAPPING / .DML
The transaction is still waiting.
Mappings connect source and target tables. Operations accumulate in a .dml file. An open transaction is not yet applied to the target.
COMMIT GATE
No COMMIT. No crossing.
Only a source COMMIT makes the transaction available to Weaver. ROLLBACK is not an instruction to apply changes.
WEAVER / APPLY
Now, the other side.
Weaver reads committed transactions and executes operations on the selected target database. Capture and apply can run independently.
TARGET
Data where it belongs.
Oracle, PostgreSQL or IBM Db2. Versions, data types, configuration and the required build variant must be qualified for each deployment.
ROLLBACK
This transaction does not cross.
Rolled-back changes are not applied to the target. This illustrates an open source transaction, not undoing changes already committed at the destination.
PROVIDEROracle LogMiner
TX0x0600 / DEMO
SOURCEREDO
TARGETPostgreSQL
APPLYWAIT
Ready. Choose a stage or start.
Native Redo: currently continuous mode, one redo thread and one PDB per replication. Db2 requires the appropriate build variant.
// USE THE CURRENT
One engine.
Several destinations.
0x02 / SCENARIO
Reporting on the other shore.
Change capture as part of feeding a separate reporting or integration database. Architecture shaped by the use case, not the reverse.
0x03 / SCENARIO
First the snapshot. Then changes.
Initial loading followed by change capture can support migration preparation. Cutover planning and testing are agreed separately.
[ ENGINEERING > HYPE ]
No miracles promised. Clear conditions agreed.
CLI and REST controls. Table mappings. Separate capture and apply. Before deployment, we qualify versions, data types, topology and recovery behaviour. We do not sell an “exactly-once” slogan: recovery can replay a transaction after a crash. That is why restart and duplicate handling also need testing.
Let’s plan your crossing ↗