In the world of real-time replication, Oracle GoldenGate Extract is a high- performance piece of the replication pipeline responsible for capturing changes with speed and precision.

But even a well-tuned replication component can struggle when the underlying hardware infrastructure doesn’t keep up with the demands of workloads.

A common yet frequently overlooked performance bottleneck occurs when batch-style workloads are executed on databases originally designed for OLTP (Online Transaction Processing).

The Problem: Batch Workloads in an OLTP World

GoldenGate Extract is designed to buffer uncommitted transactions in memory. In standard OLTP environments, transactions are typically short and frequent. But when large, long-running batch transactions—such as end-of-day processing, reconciliations, or bulk updates—enter the mix, they bring a new set of challenges.

Large batch transactions consume significant memory, and the Extract process holds them in memory until they are committed or rolled back. This is where system infrastructure can become the bottleneck.

Memory Allocation: The CacheMgr Catch

GoldenGate Extract’s memory use is governed by the CACHEMGR parameter. On Linux systems, the default CACHESIZE is 64 GB. But here’s the catch: that 64 GB is requested from the operating system—it doesn’t guarantee that it all comes from resident physical memory (RAM).

If the server is under memory pressure, the OS may allocate only part of that from RAM (say, 48 GB), and assign the rest(16GB) from swap space. And when the total allocated memory(64GB) is consumed, Extract will begin writing to memory-mapped files on disk—using disk as a painfully slow extension of RAM.

The result? Performance tanks. Extract throughput drops sharply, latency increases, and the entire pipeline is throttled as backpressure builds up. Suddenly, your replication lags, alerts go off, and SLAs are at risk.

How to Detect If Batch Transactions Are in Play

Detecting batch-style transactions early is key to diagnosing memory pressure and performance degradation in Oracle GoldenGate. Here are a few reliable ways to identify if batch transactions are currently being processed:

  • Use showtrans to view open transactions
    The showtrans command provides visibility into long-running open transactions that are being buffered by the Extract process. Transactions opened for prolonged duration with high number of items often signals batch activity.
    open transactions
    open transactions
  • Monitor memory cache usage
    Check if the Extract’s memory usage is approaching the defined CACHEMGR CACHESIZE value. When batch transactions are active, memory consumption often pushes toward this upper threshold.
Extract's current cache size
Extract’s current cache size 
  • Run top to check memory consumption
    A quick look at the system using top -p <extract_pid> can reveal if the Extract process is consuming large amounts of resident memory (RES). Sustained high memory usage is a strong signal that large transactions are being buffered. Heavy swapping is also another indication.
    top output showing extract's high memory consumption
    top output showing extract’s high memory consumption
    Heavy swapping when server is in memory pressure
    Heavy swapping when server is in memory pressure

     

How to Fix It

To avoid hitting this wall, here’s what we recommend:

  • Increase Cachesize and Prioritize Resident Memory

If your workload is batch intensive, allocate enough physical RAM so that the server running Extract can hold the entire batch in the resident memory. Increase cachesize  from default 64GB if needed depending on your batch size.

This would allow the Extract process to buffer even large batch transactions entirely in memory—without being forced to spill over to swap or disk.

  •   Optimize Swap Space (When RAM Isn’t Enough)

   If allocating enough resident memory isn’t feasible, then the next best option is to ensure that the system has a large swap space on a high-speed disk (such as SSD or NVMe). While this won’t match RAM performance, it will at least mitigate the   severity of disk-based slowdowns.

 

Final Thoughts

GoldenGate Extract is remarkably resilient, but it’s only as efficient as the infrastructure beneath it. As batch workloads become more common in hybrid OLTP environments, understanding and addressing these memory dynamics is critical for keeping your replication pipeline flowing smoothly.

If your Extract performance seems to “mysteriously” slow down during batch runs, now you know where to look—and how to fix it.

Other Blog Posts by the Author

https://blogs.oracle.com/dataintegration/post/oracle-goldengate-parallel-replicat-performance-tuning