Introduction

For enterprises running critical online transactional systems on Oracle databases, minimizing any additional workload on the primary production server is paramount to maintaining optimal performance This often presents a challenge when implementing data integration solutions like Oracle GoldenGate (OGG), as administrators might be hesitant to install OGG software directly on the primary system or allow direct connections from the extract process.

The good news? Oracle GoldenGate provides flexible deployment options to address these concerns. This white paper, “Oracle GoldenGate Downstream Capture with Real-Time Cascading Redo Logs from an Active Data Guard”, offers practical guidance for a specific architecture designed to offload the OGG capture workload from your vital primary database.

What Architecture does the paper detail?

The document focuses on a powerful deployment model: real-time downstream extraction from an Oracle Active Data Guard (ADG) standby database using cascading redo logs shipped to a downstream mining database.

This setup involves three key database components:

  • Source Oracle Database: Your primary transactional database.
  • ADG Standby Database: An Active Data Guard standby database for your source.
  • Downstream Mining Database: A separate, typically empty or “stub” Oracle database used exclusively for log mining. It must reside on different hardware than the ADG standby and its version must be the same or higher than the ADG standby.

The core flow is managed through cascading redo log shipping. Redo logs travel in two stages:

  1. From the Source database to the ADG standby database.
  2. Cascaded in real-time from the ADG standby database to the Downstream Mining database.

Crucially, redo continues to ship from the ADG standby to the mining server even if it’s not being applied to the ADG standby itself.

Downstream Oracle ADG deployment​ Downstream Oracle Active Data Guard deployment 

 

The Oracle GoldenGate Extract process runs on the Downstream Mining Database. It utilizes the database’s Logminer server, also on the mining database, to capture changes from the redo stream. Log mining cannot occur on the ADG standby directly because Integrated Extract components require a READ/WRITE database.

Why Choose This Deployment? What are the Benefits?

Offloads Workload from Source: The primary benefit is relocating the OGG Extract process and the resource-intensive log mining workload away from the production source database to the dedicated downstream mining server.

Highly Decoupled Solution: By leveraging redo cascade, the downstream mining database is separate from both the source and the ADG standby, offering architectural flexibility. This separation allows for tasks like patching the mining database without impacting the source systems.

Preserves Real-Time Capture: Despite the offloading, the use of real-time cascading redo ensures that change data capture remains real-time.

Offloads Fetches to ADG: Any data fetches required by the Extract (for information not in the redo logs) are directed to the ADG standby database instead of the primary source database, further reducing the load on the source.

Leverages Existing ADG Infrastructure: It integrates seamlessly with an already established Active Data Guard setup.

This specific configuration directly addresses the concerns of administrators who want to minimize the footprint and potential performance impact of OGG on their primary transactional systems.

What Guidance Does the Paper Provide?

This document serves as a practical guide for implementing this architecture. It covers:

  • A detailed Setup Overview outlining the necessary steps on the Source, ADG Standby, and Downstream Mining Server.
  • Key Prerequisites, including database requirements (like force logging and minimal supplemental logging), Oracle Net services configuration (including necessary aliases and connections), and OGG requirements.
  • Step-by-step Configuration Instructions for enabling cascading redo log shipping, setting up supplemental logging, creating necessary database users, configuring GoldenGate credentials and aliases, and creating/starting the downstream Extract process.
  • Important Best Practices for running OGG, including checking report files, periodically dumping the data dictionary, monitoring long-running transactions, and carefully managing foreign archive logs on the mining server.
  • A dedicated Troubleshooting appendix covering common issues like redo transport failures and ensuring real-time mining is active.

Summary

The white paper Oracle GoldenGate Downstream Capture with Real-time Cascading Redo Logs from an Active Data Guard provides a guide for implementing Oracle GoldenGate downstream capture using cascading redo logs from an Active Data Guard standby database. It explains the benefits of this architecture, such as offloading the data capture process from the primary database to improve performance. The document outlines the necessary configurations and steps across the source database, ADG standby, and downstream mining server, including enabling logging and creating GoldenGate users. It also includes best practices for monitoring and troubleshooting this specific GoldenGate setup, such as checking report files and managing foreign archive logs.

The details of setting up the downstream capture configuration can be found on Oracle Support, MOS article 

Contributing Authors: Tracy West, Sourav Bhattacharya, Somu Rajarathinam (Oracle GoldenGate A-Team)