Technical and Product News and Insights from Rackspace
This blog post explores the basics of Oracle® GoldenGate® and its functions. Because it’s decoupled from the database architecture, GoldenGate facilitates heterogeneous and homogeneous real-time capture of transactional change data capture and integration.
Oracle GoldenGate is a software product that allows you to replicate, filter, and transform data from one database to another database.
It enables the replication of data between Oracle databases and other supported heterogeneous databases.
Some reasons to use GoldenGate include the following items:
Use GoldenGate to meet the following business requirements:
There are many different architectures that can be configured, ranging from a simple unidirectional architecture to a more complex peer-to-peer one. Refer to the following image to see the various topologies supported by GoldenGate.
The following image shows the components, or processes, of the GoldenGate architecture, which are described in this section:
The manager is the process that starts the other GoldenGate processes. This process must run on both the source and target system for the configuration and must initiate all the other GoldenGate processes. The manager process also allocates disk space by purging the old trails or extract files. One manager process is required for every GoldenGate installation.
The extract process involves data extraction, which is called data capture in GoldenGate. Extract is the process that is configured to run against the source mining database.
Extract is responsible for capturing the committed data modeling language (DML) transactions and the data definition language (DDL) from Oracle redo logs. Extract writes these data changes into trails or extract files.
A trail is the series of files on the disk where GoldenGate stores the captured changes, which supports the continuous extraction and replication of database changes. These are platform-independent binary files at the OS level.
Replicat is the process that delivers data to a target database. It reads the trail on the target database, reconstructs the DML or DDL operations, and applies them to the target database.
The pump process, which is also an extract process, is optional in the GoldenGate setup. This process copies the trail files that contain data to the target system.
The extract pump and Replicat processes use checkpoints for tracking their respective progress. This mechanism marks the location of data changes that have been retrieved or applied from the trail files. This is useful when processes need to recover without any data loss or need to know the starting point after a failure.
The collector process runs on the target system and writes the data changes from the source database in the target trail files, which are known as RMTTRAIL. Before copying it to RMTTRAIL, the collector reassembles the files.
Oracle GoldenGate supports the following types of capture, which are described in this section:
Classic capture is the original GoldenGate capture mechanism, which reads data directly from the online redo logs and archived redo logs where possible. Additional data might be fetched from the database file where necessary.
Integrated capture (IC), introduced in Oracle GoldenGate version 11.2.1, was initially available for Oracle 220.127.116.11 with the 18.104.22.168 database-specific bundle patch for Integrated Extract 11.2.x (MOS Note 1411356.1). IC uses a log-mining server on the source system or in a downstream Oracle database, similar to a DataGuard logical standby or Oracle streams.
IC is a new form of the extract process, which has moved inside the source database. In the traditional classic extract process, the extract works on the redo logs outside the domain of the actual database. In IC, a server log miner process is started, which extracts all the DML data and DDL statements (create, alter, drop, and so on) and creates logical change records (LCR). These records are then handed to the GoldenGate memory processes, which write the LCR’s to the local trail files.
Before the release of version 12.1, Replicat applied transactions to the target database serially. To achieve parallelism, tables had to be split across multiple replicates for quicker data application and reduced lag. Drawbacks to this approach include the manual configuration of multiple replicates and trail files and the limiting inability to split tables that had foreign key relationships across replicates.
The new coordinated and integrated Replicat modes help you to apply transactions in parallel on the target database without having to manually split tables into multiple replicates.
The following sections describe the different Replicat modes.
With classic Replicat, a target database checkpoint tells the system which transactions have been committed and which have not. This is a key aspect of transactional replication.
Classic Replicat has the following characteristics:
The following image illustrates classic Replicat:
A configured Replicat is called a coordinator. This process starts additional replicates based on the specified number of threads. The Replicat name is limited to five characters, and the threaded replicates have this name appended with a three-digit number (for example, RGGMA, RGGMA001, RGGMA002, and so on). The coordinator sends SQL to the threads, which can be applied in parallel and in committed order.
The following image illustrates coordinated Replicat:
Integrated Replicat has the following characteristics:
The following image illustrates integrated Replicat:
This blog described how and why to use GoldenGate and discussed its architecture and components. It also detailed the capture modes and Replicat modes incorporated in the tool.
Use the Feedback tab to make any comments or ask questions.