GoldenGate Downstream deployment – Basics

GoldenGate Downstream deployment allows you to offload the source database extract load to intermediate or target server. The source database ships its redo logs to a downstream database, and Extract uses the logmining server at the downstream database to mine the redo logs. A downstream mining database can accept both archived logs and online redo logs from a source database

Oracle GoldenGate Change Data Capture (CDC) Extract is commonly installed on the Source database server, but an Integrated Extract can optionally be installed on a secondary database server, known as a Downstream Mining database, where the Source database’s redo and archive logs are shipped and finally data will flow from Downstream database to target database.

When deploying Integrated Extract in a downstream mining database you can choose between two options:

Option 1 is real-time mining:  This option can be used to capture changes only from a single source database. You need to create standby redo logs on the target side so that the source database can use Oracle Data Guard redo transport to send redo to the downstream mining database as it is written to the online redo log at the source. In a real-time downstream capture environment, the primary database is configured so that the transport services use the log writer process (LGWR) at the source database to send redo data to the downstream database either synchronously or asynchronously.

Option 2 is archive log mining:   In this option you can use the downstream mining database to capture changes for single or multiple source databases. You don’t need standby redo logs in the downstream database for this configuration. Note that using this option will incur additional latency. In this option downstream extract is not configured for real time capture, it waits for next archive log, which will be available after a log switch on source database. The latency of Downstream Extract can be controlled by setting the source database init.ora parameter ARCHIVE_LAG_TARGET. This parameter is set to a  number of seconds. Since this parameter forces a log switch on all nodes, it is not recommended to set this very low. The recommended setting should be around 15 minutes or 900 seconds.

BENEFITS OF GOLDENGATE DOWNSTREAM DEPLOYMENT:

• Since the logmining activity imposes additional overhead on the source database where it is running because it adds additional processes as well as consumes memory from the SGA from the source database, it is beneficial to offload this processing from the source database to the downstream database. The only impact would be the cost to ship redo via ASYNC transport which is extremely lightweight. This is major benefit.

LIMITATIONS  OF GOLDENGATE DOWNSTREAM DEPLOYMENT:

• This configuration requires the deployment and maintenance of another database.
• Downstream Integrated Extract can be configured to process either in real-time mode or archive log only mode.  Real-time mining can be only be configured for one source database at a time. Downstream mining database can accept online redo logs from only one of those source databases. The rest of the source databases must ship archived logs.
• The source database and mining database must be of the same platform. For example, if the source database is running on Linux 64-bit, the downstream database must also be on the Linux 64-bit platform.
• This feature is specific to Oracle databases only.
• Every time any PSU patches need to be applied to Source side,  then first associated mining database need to be patched. Downstream capture can mine logs from lower release databases, but not from higher release databases.