Architecture for Oracle Golden gate

 

Components of the golden gate:

1. Source database.
2. Manager process @ source database/target database- manages all GG operations
3. Capture process or Extract process (Local Extract)
4. Source Trail / Trail files @ Source db side
5. Pump process @ source database.
6. Network (high speed network to avoid replication lagging)
7. Remote Trail / Trail files @ Target db side
8. Delivery process or Replicat process
9. Target database.
10. Manager process @ target database.

Source Data base: The oracle database or any other database from which the data will be replicated.

Target Database: The oracle or any other database where the data need to be replicated.

Manager process: This is the common process which is present at both source golden gate and target golden gate tool, which needs to be started before any other process needs to be started.

• Manager process is used for coordination of tool, if manager process is not running rest of the process will not work/start.
• The Manager process is the first Golden Gate process to be started.

Capture/Extract Process: Capture/Extract process is the process of extracting data that is inserted into, updated on, or deleted from the source database.

• Extract is an operating-system process that runs on the source server and captures changes from the database redo logs (and in some exceptional cases, the archived redo logs) and writes the data to a file called the Trail File.
• Extract only captures committed changes and filters out other activity such as rolled-back changes.

Source Trail / Trail files: The Extract process sequentially writes committed transactions as they occur to a staging file which is called as source trail file.

• Data that is written to the trail is queued for distribution to the target server or another destination to be processed by another Golden Gate process.

Note: Each of the Golden Gate processes keeps track of its position in the trail files using checkpoints,

Pump process: The data pump is another Golden Gate process. The data pump reads the records in the source trail written by the Local Extract, pumps or passes them over the TCP/IP network to the target, and creates a target or remote trail.

• Although the data pump can be configured for data filtering and transformation (just like the Local Extract), in many cases the data pump reads the records in the source trail and simply passes all of them on as is.

Network: Using TCP/IP these trail files are sent.

Remote Trail / Trail files: The remote trail is similar to the source trail, except it is created on the remote server, which could be the target database server or some other middle tier server.

• The source trails and the remote trails are stored in a file system directory named dirdat by default.

Note: The trail files are named as two-character prefix followed by a six-digit sequence number. The two characters makes the difference whether it’s a source trail or target trail.

Delivery process or Replicat process: Delivery is the process of applying data changes to the target database. In Golden Gate, delivery is done by a process called the Replicat.

• The Replicat process applies data changes written to the trail file by the Extract process in the same order in which they were committed on the source database. This is done to maintain data integrity.

Extract capture types:

1. Classic capture:

• In this Mode the Oracle Golden Gate Extract process captures data changes from the Oracle redo or archive log files on the source system.

2. Integrated capture:

• In integrated capture mode, the Oracle Golden Gate Extract process interacts directly with a database log mining server to receive data changes in the form of logical change records (LCR).
• Database log mining server is just an interface (where LCR get generated) between oracle source database and the extract process.

        2.1. local deployment: In this deployment, the source database and the mining database are the same. The source database is the database for which you want to mine the redo stream to capture changes.

        2.2. Downstream deployment: In this deployment, the source database and the mining database are the different databases, we need to configure in a way that redo’s will be transported to downstream database, from where the extract process captures the changes in the form of LCR's

Note: When using a downstream mining configuration, the source database and mining database must be of the same platform.