DEVOURED
Hunting Replication Lag: A Queue-by-Queue Method for Diagnosing Oracle GoldenGate
Diagnosing Oracle GoldenGate replication lag requires treating the pipeline as a series of queues rather than reflexively increasing process parallelism.
What: Author Zalak Shroff explains that adding more 'applier' processes often fails because the bottleneck is usually upstream or due to serialized dependencies like hot rows or missing indexes. She recommends heartbeat tables to measure latency at each hop.
Why it matters: Engineers often treat 'lag' as a generic symptom, but in distributed replication, the bottleneck shifts dynamically. Measuring the correct stage is the only way to avoid wasted resource allocation.
Takeaway: Deploy heartbeat tables immediately. Before scaling parallelism, check the target's index status on hot tables and look for serialized transactions that cannot be parallelized.
Deep dive
- Queueing Problem: Lag is the sum of delays across capture, trail write, distribution, and apply stages.
- Process-level Lag: Can be misleading as it only measures the staleness of the record a process is currently handling.
- Heartbeat Tables: The most reliable way to measure end-to-end latency across hops.
- Common Bottlenecks: Missing indexes on target tables, 'hot' rows causing serialization, or network congestion.
- Resolution: Parallelism only works if the apply stage is the bottleneck and the workload is truly independent.
Decoder
- GoldenGate: Oracle's software for data replication and real-time data integration.
- Replicat: The GoldenGate process that applies data changes to the target database.
- Trail: A series of files containing the captured data changes that the Replicat process consumes.
Original article
Full article content is not available for inline reading.
Explore all 69 articles in today's digest
Fresh dev news, AI-digested daily. Never miss a trend at devoured.fyi