Replication Agent for UDB Behavior

These Replication Agent issues are unique to Replication Agent for UDB.

Table Marking Immediately After Resume When LTM Locator Is Zero

When the Replication Agent instance goes to Replicating state, the Log Reader component reads the primary database transaction log and uses the value of the origin queue ID to determine the position in the log to start reading. When the value of the LTM locator is 0 (zero), the Log Reader starts reading at the end of the log.

Because the Log Reader operation is asynchronous, the Replication Agent instance can return to the operating system prompt after the resume command but before the Log Reader has completed its start-up process. If you immediately invoke the pdb_setreptable command to mark a table for replication after the resume command returns, the mark object entry can be placed in the transaction log before the Log Reader finds the end of the log. In that event, the Log Reader misses the mark table entry, and table marking fails.

To avoid this problem, wait 5 to 10 seconds after invoking resume before invoking pdb_setreptable to mark a table.

DB2 FORCE APPLICATION Command

The DB2 FORCE APPLICATION command causes the data server to drop its connections with an application. FORCE APPLICATION ALL causes the data server to drop its connections with all applications.

If you invoke FORCE APPLICATION and specify either the Replication Agent application handle or the ALL keyword, the data server drops its connections with the Replication Agent instance. In that event, the Replication Agent receives DB2 error code -30081 and cannot recover, so the Replication Agent instance shuts itself down.

To avoid this situation, invoke the Replication Agent shutdown command before using FORCE APPLICATION.

Read Buffer Size

The Replication Agent for UDB Log Reader component uses the value of the lr_read_buffer_size parameter to determine the maximum number of bytes to be read from the transaction log during each scan. Because the Log Reader reads bytes, it requires a buffer to store the bytes read.

It is difficult to identify a minimum buffer size that always works. The value range of lr_read_buffer_size is 10000 to 2147483647. Sybase recommends that you set value of lr_read_buffer_size to the default value (64000).

If the read buffer size is too small to read one operation, Replication Agent goes into the Admin state, and the Log Reader component shuts down and reports the DB2 -2650 error. Unfortunately, this error message covers general communication errors, not just an insufficient buffer size.

LOB Replication

When replication is enabled for a LOB column, Replication Agent makes an entry in the prefixvblob_columns_ table to support replication for that column.

When Replication Agent processes a transaction that affects a LOB column, the LOB data may not be stored in the transaction log because of its possible size. Instead, the Replication Agent Log Reader component reads the LOB data directly from the primary database at the time it processes the transaction.
Note: If you do not specify the primary key for a table that contains columns with approximate numeric datatypes, the LOB and long field columns may be replicated as NULL values.

For instructions on enabling and disabling replication for LOB columns, see the Replication Agent Administration Guide.

Transaction Integrity and LOB Data

Because of the way Replication Agent processes the LOB column data when replicating transactions, transaction integrity may be compromised. For example, if two transactions change the data in a LOB column and the Log Reader does not process the first transaction until after the second transaction has been committed, when the LOB data is read from the primary database, the value of that data is the result of the second transaction. In this event, the value of the LOB data in the first transaction is never sent to the replicate database. After the second transaction is processed by the Log Reader, the primary and replicate databases are synchronized again, but for a period of time between processing the first and second transactions, the replicate database contains data that does not match the originating transaction.

This problem occurs only when a LOB column is changed more than once by a sequence of transactions. The period of time over which the problem exists may be significant if the replication system throughput is slow or if a replication system component fails. As soon as the last transaction that changes the LOB column is processed at the replicate site, the problem is corrected.