Help SQL Replication

Memory used by the Capture program

The Capture program uses memory when it reads the DB2® recovery log. It stores individual transaction records in memory until it reads the associated commit or abort record. Data associated with an aborted transaction is cleared from memory, and data associated with a commit record is written to the CD table and the UOW table. The committed transactions stay in memory until the Capture program commits its work when it reaches its commit interval.

To monitor how much memory the Capture program is using, look in the CURRENT_MEMORY column of the IBMSNAP_CAPMON table.

You can set the memory_limit parameter when you start the Capture program to ensure that Capture uses a specified amount of memory for storage that is associated with transactions. Other storage use is not limited by this parameter. You can also change the memory_limit parameter while the Capture program is running. If Capture reaches the memory limit, it writes some transactions to a spill file. You need to consider the memory resources that are used by the Capture program in relation to its storage space requirements.

You should also consider the size of user transactions and the commit interval when planning for the Capture program's memory requirements. Long running batch jobs without interim commits take a lot of memory when you run the Capture program. Generally, the smaller the commit interval, the less memory required by the Capture program.

Information about active registrations is read and stored in memory when you start an instance of the Capture program and when you add registrations dynamically while the Capture program is running.

z/OS®, Linux, UNIX, Windows
When replication reads log records it uses a memory buffer. The default size on the z/OS operating system is sixty-six 1 KB pages, and it is ECSA (extended common service area) storage. Replication uses ECSA only in this situation. The default size of the buffer on Linux, UNIX and Windows operating systems is fifty 4 KB pages.
IBM® i
CURRENT_MEMORY is the up-to-date account of extra memory allocated for holding the transaction records beyond the memory used by standard I/O buffers for the active CD tables. It is an indication of how much extra memory is being used to hold the large number of transactions. It is not an accurate sum of all the memory used by the specific journal job.

Information stored in the IBMSNAP_CAPMON table provides operational statistics to help you tune memory usage. Note that the values in this table are for a particular Capture monitor interval, they are not cumulative across monitor intervals. The data in the CURRENT_MEMORY column does not contain an additive count. It reflects the memory in use at the end of the monitor interval when the record is created. The Capture monitor interval determines how frequently the Capture program inserts data into this table. Use one of the following methods to tune the amount of memory being used by the Capture program:

Tuning memory limit to allow for spills:
  1. When you start the Capture program, use the default memory limit.
  2. Check if data spilled from memory to a temporary file by looking at the TRANS_SPILLED column in the IBMSNAP_CAPMON table. This column shows the number of source system transactions that spilled to disk due to memory restrictions during a particular Capture monitor interval.
  3. If data spilled from memory, either use a higher memory limit or a lower commit interval.
Tuning memory limit to prevent spills:
  1. When you start the Capture program, set a high memory limit. (How high depends on your system resources.)
  2. Check how much memory is being used by looking at the CURRENT_MEMORY column in the IBMSNAP_CAPMON table. This column shows the amount of memory (in bytes) that the Capture program used during a particular Capture monitor interval.
  3. If much less memory is being used than what you specified for the memory limit, set a lower value for the memory limit.


Send your feedback | Information roadmap | The Q+SQL Replication Forum

Update icon Last updated: 2013-10-25