Replication requires an entire “before” and “after” image of the row that has been changed by an update. When you mark a table for replication using the Replication Agent interface dialog panels, the table is altered with the DATA CAPTURE CHANGES clause. As the number of DB2 tables marked for replication increases, so do the DASD space requirements for the DB2 active log data sets.
There are no increases in the amount of data written to the log for deletes or inserts, because for deletes and inserts, the entire “before” image and “after” image is captured in the log.
When a table receives an update, DB2 has to log before and after copies of the data in case it is necessary to restore that data. DB2 writes nine different types of update log records to minimize the amount of data written to the logs.
The additional DB2 log usage caused by using DATA CAPTURE CHANGES can be significant if the row size is large or if the number of updates is large.
DB2 also minimizes the amount of data written to a log record by writing only data from the first changed byte in the table row up to the end of the row. The entire copy of the table row before the change is then copied to the log record.
The effect of the change is minimal if the number of updates is small, if the row size is small, or if the updates are normally applied near the end of the row.
DB2 does not log transactions for an update in which the entire new table row matches the entire old table row. Replication Agent does not replicate transactions of this nature because the transactions do not appear in the DB2 logs.
Begin records can be written long before data records are written to the log file and transaction data can be interleaved. Because this is the case, begin records are not sent to the Replication Server until just before the first data record is sent. Begin records use information from the data record to keep the log sequence in ascending order.
There are multiple commit records and multiple abort records. A commit is sent to the Replication Server when the final commit is received; rollbacks are sent when the final rollback record is received.
