GoldenGate

Oracle GoldenGate Microservices Architecture (OGG MA) was introduced starting with Oracle GoldenGate 12.3 to modernize replication management, improve security, enable automation, and simplify large-scale GoldenGate deployments. Oracle GoldenGate Microservices Architecture is a service-oriented deployment model where each GoldenGate function runs as an independent service. Instead of tightly coupled background processes (Manager, Collector, Data Pump), MA uses dedicated servers that communicate using secure RESTful APIs over HTTPS. This design enables: Centralized management Better fault isolation Easier upgrades Automation and DevOps integration Core Components of Oracle GoldenGate Microservices Architecture:- OGG MA consists of five core services plus the Admin Client. Each service has a clear and well-defined role. 1. Service Manager – The Watchdog Supervisor Service Manager is the central watchdog and entry point for Oracle GoldenGate Microservices Architecture. Manages one or multiple GoldenGate deployments on a host One Service Manager supports multiple Administration Services Can run: Manually As a Daemon Integrated with XAG Agent Used to: Start/stop deployments Manage users, certificates, and security profiles Access all microservices (Admin, Distribution, Receiver, Metrics) Monitor logs and enable debug tracing  Each GoldenGate installation has only ONE Service Manager 2. Administration Service – The Central Brain Administration Service is the control plane of a GoldenGate deployment. Manages Extract and Replicat processes Provides REST API and Web UI Allows: Create, start, stop, alter Extracts & Replicats Manage parameter files, checkpoints, reports Configure supplemental logging Manage credential store and encryption keys Admin Client communicates with this service using REST APIs 3. Distribution Service – Modern Data Pump Distribution Service handles source-side trail distribution. Replaces classic Data Pump Extract Sends trail files to one or more targets Supports: WebSockets (HTTPS) UDP Classic OGG protocol (for interoperability) Performs routing only (no transformations or filtering) Supports proxy and cloud environments 4. Receiver Service – Modern Collector Receiver Service is the target-side trail receiver. Replaces classic Collector Receives trails from Distribution Service Supports: WebSockets (default) UDP Classic OGG protocol 5. Performance Metrics Service – Monitoring & Observability Performance Metrics Service provides centralized monitoring. Collects metrics from all GoldenGate processes Enables: Performance monitoring Resource utilization tracking Error and status visibility Integrates with third-party monitoring tools Metrics storage is separate from Admin metadata 6. Admin Client – Command Line Interface for MA The Admin Client is the command-line alternative to the web UI, similar to GGSCI but designed for Microservices Architecture. Communicates with Administration Server using REST APIs Create and manage Extracts and Replicats Start and stop processes View lag, status, and reports Summary Table – Classic vs Microservices Components :- Microservice Component Purpose Classic Equivalent Service Manager Deployment and Service Watchdog No Direct Equivalent Administration Server Central control Manager Distribution Server Sends trails Data Pump Receiver Server Receiver trails Collector Performance Metrics Server Monitoring Monitoring datastore Admin Client CLI Control GGSCI

When monitoring your Oracle GoldenGate setup, two important metrics often appear on your GGSCI dashboard — Lag at Checkpoint and Time Since Checkpoint , understanding them is key to knowing whether your data replication is healthy and up-to-date. Lag at Checkpoint – “How Far Behind Am I?” Lag at Checkpoint works like a stopwatch that shows how far behind GoldenGate is in processing the latest database changes. If this number is small, GoldenGate is keeping up — changes on the source database are being captured and applied almost instantly on the target. If this number is large (in seconds, minutes, or even hours), replication is falling behind. Example:If your source database time is 10:05:00, and the last transaction captured was from 10:04:45,then: Lag at Checkpoint = 15 secondsMeaning the Extract or Replicate process is 15 seconds behind real time. So, a growing lag means the replication process isn’t catching up fast enough — perhaps due to heavy data load, slow I/O, or network delay. Next ,  Time Since Checkpoint – “When Did I Last Save My Progress?” Time Since Checkpoint tells you how long it’s been since GoldenGate last saved its progress (called a checkpoint). Checkpoints are like save points in a game — they allow GoldenGate to remember where to resume if a process stops or crashes. If Time Since Checkpoint keeps increasing: The process may be stuck, waiting on resources, or not processing new data. It can also indicate that the system hasn’t written a new checkpoint due to a long-running transaction or lag in applying records. Example:If the Extract process last wrote a checkpoint 3 minutes ago, and it’s still running without updating it, that could mean it’s waiting to process a big transaction or facing a performance bottleneck.   Metric Think of it as… What It Tells You When It’s a Problem Lag at Checkpoint A stopwatch How far behind replication is When lag > your normal baseline Time Since Checkpoint A timer How long since last checkpoint was saved When it keeps growing steadily  In Short, Both these metrics act like health indicators for your replication setup: Lag at Checkpoint → Tells you how delayed the data movement is. Time Since Checkpoint → Tells you when progress was last saved. Keeping these numbers low ensures faster, reliable, and real-time data replication between your databases.