DBA Trainer

Oracle RAC + Data Guard – The Perfect Architecture for Mission Critical Databases

Oracle RAC in the Primary – Availability, Scalability & Load Sharing Oracle RAC in the primary site delivers three major advantages: High Availability (HA) If one database server/node fails, another node continues serving users. Database stays online Sessions re-route to surviving nodes No outage for applications Planned maintenance can be done node-by-node Result: Continuous availability for the primary database Scalability Multiple nodes work together as a single database. Add more nodes when user load increases Increase throughput without downtime Ideal for large OLTP workloads Result: System capacity grows as business demands grow Load Balancing User connections automatically spread across multiple RAC nodes. No single-node overload Balanced CPU & memory usage Better response time during peak hours Result: Efficient resource utilization and stable performance Data Guard Standby RAC – Disaster Recovery & Workload Offloading Data Guard with RAC on the standby site provides powerful advantages: Disaster Recovery (DR) If the entire primary site fails: Standby RAC becomes the new primary Minimal downtime (seconds to minutes) Minimal or zero data loss (SYNC/ASYNC mode) Result: Business continues even if the main site is lost Offloading Workloads (Active Data Guard) The standby RAC database can run real workloads, not just sit idle. You can offload: Reporting BI queries Long read-only operations Backup jobs ETL extractions Result: Primary RAC focuses on OLTP while standby handles heavy reads This significantly improves performance and reduces resource pressure on the primary site. Combined Outcome – What RAC + Data Guard Deliver Together Using both gives unmatched resilience: Near-zero downtime Node failure → RAC handles it Site failure → Data Guard handles it. Predictable performance Workload spread across nodes Scalable growth Add RAC nodes or standby nodes anytime Better resource utilization Move reporting & heavy reads to standby End-to-end resilience Highly available primary + disaster-protected secondary So Here , Oracle RAC and Data Guard together provide an enterprise-class foundation that eliminates single points of failure, keeps systems responsive under growing workloads, and protects data against site-level failures. RAC handles node-level resilience and performance, while Data Guard ensures site-level continuity and operational efficiency through offloading. When implemented correctly, this architecture delivers unmatched uptime, flexibility, and operational confidence.

Oracle RAC + Data Guard – The Perfect Architecture for Mission Critical Databases Read More »

Lag at Checkpoint and Time Since Checkpoint in Oracle GoldenGate

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.

Oracle RAC + Data Guard – The Perfect Architecture for Mission Critical Databases

Lag at Checkpoint and Time Since Checkpoint in Oracle GoldenGate

Subscribe to Newsletter