One of the key aspects for replication is checkpointing. A target database checkpoint tells which transactions are actually committed and which not yet. This is a key aspect of transactional replication. Let’s look how that works for the Oracle GoldenGate Classic Replicat.
Year: 2018
Oracle GoldenGate remote Classic Extract
Most people I have spoken to are are absolutely convinced that the Extract process has to be running on the source database host. This thinking comes from all Oracle diagrams where the Extract process is located on the source database host. Till OGG version 11.1.1 this was indeed true. Some have heard that the Extract process can be removed from the source host but it can only done with the Integrated Extract process.
There is however the TRANLOGOPTIONS DBLOGREADER parameter which allows the Classic Extract can be run remotely without any need of accessing the redo/archive logs file system (or ASM).
How Oracle GoldenGate Replicat handles Foreign Key Constraints
According to the Oracle database documentation there are two types of constraints: DEFERRED and NOT DEFERRED. The first one can be evaluated at the and of the transaction, and the second one if validated immediately. On the other hand Oracle GoldenGate can handle the replication when the target uses both of them. Let’s find out how this works.
Oracle GoldenGate Classic Extract together with RMAN recovery catalog
In my previous post I have analyzed what happens if you would like to prevent archive logs from deletion so that they can be further processed by Oracle GoldenGate. I have assumed that it would work the same if the RMAN recovery catalog was being used. Lets find out what happens.