Golden Gate architecture: GoldenGate Concepts

From Robs_Wiki
Revision as of 18:37, 28 August 2017 by Qadmin wiki (talk | contribs) (Golden Gate configuration: Cascading replication)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Commit Sequence Number (CSN)

Each kind of database management system generates some kind of unique serial number of its own at the completion of each transaction, which uniquely identifies the commit of that transaction. For example, the Oracle RDBMS generates a System Change Number, which is a monotonically increasing sequence number assigned to every event by Oracle RDBMS. The CSN captures this same identifying information and represents it internally as a series of bytes, but the CSN is processed in a platform-independent manner. A comparison of any two CSN numbers, each of which is bound to a transaction-commit record in the same log stream, reliably indicates the order in which the two transactions completed.

The CSN is cross-checked with the transaction ID (displayed as XID in Oracle GoldenGate informational output). The XID-CSN combination uniquely identifies a transaction even in cases where there are multiple transactions that commit at the same time, and thus have the same CSN. For example, this can happen in an Oracle RAC environment, where there is parallelism and high transaction concurrency.

The CSN value is stored as a token in any trail record that identifies the commit of a transaction. This value can be retrieved with the @GETENV column conversion function and viewed with the Logdump utility.

Oracle GoldenGate works with commit sequenced data. When a unit of work is started on the database, the Extract process reads the transaction log storing the retrieved data in a local or extended memory space, depending upon the size of the unit of work. This data remains in the process memory space until either a rollback is initiated or the unit of work completes via a database COMMIT.

When the COMMIT is recorded by the database, the Extract process flushes the queued transaction information to a designated disk storage location for further processing, transmission, and apply to the target. Therefore all data processed by OGG is in commit sequence order.

All tables with foreign key relationships must be processed by the same Change Data Capture (Extract), Extract Data Pump, and Change Data Apply (Replicat) process.

Golden Gate uses the CSN (commit sequence number) to enforce data integrity. The CSN can be required to position Extract in the transaction stream, to reposition Replicat in the trail, or for other purposes. It is returned by some conversion functions and is included in reports and certain GGSCI output.

Golden Gate topology: Multitarget replication

In a multitarget replication the source database is replicated to multiple target databases. The best practise is to configure seperate pump processes for each target, but you can also use the same pump extract process for multiple targets.

Golden Gate topology: Cascading replication

In a cascading replication the target database, in its turn, will replicate the changes to a third (or more) target database. This topology is often used if you want to replicate those changes to multiple systems, but you also want to reduce the overhead of the replication on the primary (source) system.

Relative Byte Address (RBA)

The relative byte address (RBA) is the location within the trail file to indicate the current transaction. It is basically a marker within the trail file to identify the location of the transaction.