Golden Gate (OGG) provides real-time capture, transformation, and delivery of transaction data in heterogeneous environments.
The heterogeneous environments supported by OGG are:
Features of Ogg:
- Small impact on production systems: real-time transaction log reading, real-time replication of large volume data with low resource occupancy
- Transaction-based replication to ensure transactional consistency: only the submitted data is synchronized
- Performance
- Intelligent transaction reorganization and operation merging
- Accessing using the Database local interface
- Parallel processing System
- Flexible topology: Support for a pair of one or one-to-many, many-to-one, many-to-many and bidirectional replication
- Supports data filtering and conversion
- You can customize filter rules based on tables and rows.
- You can perform flexible innuendo and transformations on real-time data.
- Provides data compression and encryption: reduces the bandwidth required for transmission and improves transport security.
How OGG works:
The process of Ogg:
- The manager process is a goldengate control process that runs on both the source and target sides. It mainly functions in the following aspects: Start, monitor, restart other processes of goldengate, report errors and events, allocate data storage space, publish threshold report, etc. There is only one manager process on the target side and the source side
- Extract runs on the source side of the database and is responsible for capturing data from the source-side data tables or logs. The role of the extract can be divided into stages as follows:
- Initial time Load phase: During the initial data load phase, the extract process extracts data directly from the source-side data table
- Synchronization change capture phase: After initial data synchronization is complete, the extract process is responsible for capturing the source-side data changes (DML and DDL)
- The data pump process runs on the source side of the database, which is often recommended as a local trail file generated by the source, sending the trail as a block of data through the TCP/IP protocol to the target. Pump process essence is a special form of the extract process, if the trail file is not used, then the extract process is delivered directly to the target side after extracting the data, and a remote trail file is generated.
- The collector process is called the server collector process that corresponds to the data pump process, and this process does not need to cause my attention because it is transparent to us because it does not require us to configure it in the actual operation. It runs on the target side, and its task is to reassemble the data posted by extract/pump into a remote Ttrail file.
- Replicat process, we also call it the application process. Running on the target side is the last station of data delivery, which reads the contents of the target Trail file and resolves it to a DML or DDL statement and then applies to the target database.
Trail file on Ogg:
- For more efficient and more secure delivery of database transaction information from the source side to the target. Goldengate introduced the concept of trail file. As mentioned earlier, when extract extracts the data, Goldengate will convert the extracted transaction information into a goldengate proprietary format file. Then the pump is responsible for delivering the trail file from the source to the target, so the source and target will have this file at either end.
- The purpose of the trail file is to prevent a single point of failure, persist transactional information, and use the checkpoint mechanism to record its read-write location, and if a failure occurs, the data can be re-transmitted according to the location of the checkpoint record.
