Golden Gate (OGG for short) provides real-time capturing, conversion, and delivery of transaction data in heterogeneous environments.
OGG supports the following heterogeneous environments:
OGG features:
- Small impact on the production system: reads transaction logs in real time to replicate large transaction volumes in real time with low resource usage
- Copies data in transaction units to ensure transaction consistency: only submitted data is synchronized.
- High Performance
- Intelligent transaction restructuring and operation Merging
- Access through local database Interfaces
- Parallel Processing System
- Flexible topology: one-to-one, one-to-multiple, multiple-to-one, multiple-to-many, and bidirectional replication are supported.
- Supports data filtering and conversion
- You can customize filtering rules based on tables and rows.
- Flexible projection and transformation of real-time data can be performed.
- Data Compression and encryption: reduces the bandwidth required for transmission and improves transmission security.
How OGG works:
OGG process:
- The Manager process is the control process of GoldenGate and runs on the source and target ends. It is mainly used in the following aspects: Start, monitor, restart other Goldengate processes, report errors and events, allocate data storage space, and release threshold reports. There is only one manager process on the target and source end.
- Extract runs on the database source and is responsible for capturing data from the source data table or log. The role of Extract can be divided into the following phases:
- Initial loading phase: In the initial data loading phase, the Extract process extracts data directly from the data table at the source end.
- Synchronization change capture phase: after the initial data synchronization is complete, the Extract process is responsible for capturing source data changes (DML and DDL)
- The Data Pump process runs on the database source end. It serves to send the local trail files generated by the source end to the target end in the form of Data blocks through the TCP/IP protocol, this is usually recommended. The pump process is essentially a special form of extract process. If the trail file is not used, the extract process directly delivers the data to the target end after extracting the data to generate a remote trail file.
- The Collector process corresponds to the Data Pump process and is called the Server Collector process. This process does not need to concern me, because we do not need to configure it during actual operations, so it is transparent to us. It runs on the target end. Its task is to reassemble the data delivered by Extract/Pump into a remote ttrail file.
- The Replicat process is also called an application process. Running on the target end is the last station for data transmission. It is responsible for reading the content in the target end's trail file, parsing it as DML or DDL statements, and then applying it to the target database.
About the OGG Trail file:
- In order to deliver the database transaction information from the source end to the target end more effectively and securely. GoldenGate introduces the concept of a trail file. After extract extracts data, Goldengate converts the extracted transaction information to a file in GoldenGate proprietary format. Then, pump is responsible for shipping the source trail file to the target end, so such files exist at both ends of the source and target.
- The purpose of the trail file is to prevent single point of failure (spof), persist transaction information, and use the checkpoint mechanism to record its Read and Write locations. If a fault occurs, data can be retransmitted based on the position recorded by the checkpoint.
