Logical log data file
The format of the logical log data file does not define an order for the records that the file contains. Normally the records in the data file are not in the same order as the original database changes reflected in DB2 log records.
Application programs that process a logical log data file might need to sort the records in the file before processing. For example, to duplicate the original order for units of recovery and the order of the changes within each unit of recovery, use the UORCOMMITLRSN and ORDERVALUE fields as sort keys. (If your logical log file contains segmented logical log records, be sure to account for multiple segments by using the SEGNUM field of the logical log header. For more information, see Normal and segmented logical log record formats).
Data change record (LLDF)
The logical log contains one instance of the Data Change Record for every change represented in the log that was defined (directly or indirectly) by your selection criteria.
The basic layout of the Data Change Record is shown in Normal and segmented logical log record formats. The record contains the following parts:
Logical log header
The header contains unit of recovery information, object identifiers, timestamp, and other information about the data change represented in the record. The layout of the logical log header is described in Data change header description record (XHDF).. The logical log control file also defines the layout of the logical log header in a set of description records. For more information, see
The length of the logical log header can change in different versions of the product. If you process output logical log files with a program other than Log Master, use the LENGTH field at the beginning of each logical log record to determine the length of the header. By using this technique, you can avoid changing your programs or processes when the length of the header changes.
The row image begins with a two-byte length value that defines the length of the succeeding row image. The content of the row image varies depending on the type of change that the Data Change Record represents:
Insert action (the content is an image of inserted row)
Delete action (the content is an image of deleted row)
Update action (the content is an image of the row before update is completed)
Within a row image, Log Master for DB2 places columns in order based on their logical position within the base table, regardless of their physical position within the table row. The column order is based on the COLNO column in the SYSIBM.SYSCOLUMNS table of the DB2 catalog.
Additional row image (when required)
If the Data Change Record represents an update action, the record includes another row image that contains the after image of the row. The additional row image starts with a two-byte length field that begins immediately after the update action’s before image.
Records in the logical log data file can be segmented, depending on the length of the data represented in the record and the system-determined block size of the device where Log Master for DB2 writes the logical log. For more information about how the product segments logical log records, see Normal and segmented logical log record formats.
Record status: DB2 specific
is updated for Log Master version 11.1 and later. However, Log Master allows for processing of earlier versions (back to version 7.3.00) of the logical log with normalization performed, as needed, to work with the new format.
In addition, Log Master version 11.1 and later supports extended precision of timestamp values.
Data change record (LLDF)
Length of the header
Originating DB2 system
Database ID of the object that the record is for
Table Space ID of the object that the record is for
Length of the TABLEOWNER field
Length of the TABLENAME field
Table space name
Owner ID for the table
Partition number (if table space)
Timestamp for this log record
LRSN for this update
RBA for this update
Data sharing member ID (zero if not data sharing)
Row ID (page | row number)
Type of update:
'UB' – update
'I ' – insert
'D ' – delete
'DM' – mass delete
'DT' – truncate
'DR' – truncate with reuse option
'IL' – insert due to load action
'CO' – catalog object (DDL information)
'E' – exchange
'CM' – DB2 command
'SC' - status change
U – UNDO
R – REDO
' ' (blank) – other
Disposition of log record (as opposed to disposition of URID):
C – Record was committed
A – Record was aborted (included in a
S – Record was included in a ROLLBACK
TO SAVEPOINT action
O – Record was reversed by DB2 (for example, in response in response to some negative SQL codes
R – Record generated by RI constraint
T – Record generated by trigger activity
B – Record generated by both RI constraint and trigger activity (RI takes precedence)
H – Record generated by history activity on a system-maintained temporal table
Number of bytes contained in DB2 log record(s) for this transaction
Number of log bytes that would have been saved had DATA CAPTURE CHANGES been off.
The number of additional bytes that would have been logged had DATA CHANGES been on.
Anomaly Anchor ID from RID
Tells why this record is in the logical log – N for normal record selected by the filter
RBA/LRSN of the anomaly anchor point
Timestamp for this unit of recovery
Timestamp value for the commit record for this unit of recovery
Disposition of unit of recovery:
C – committed
A – aborted
LRSN of unit of recovery record
RBA of unit of recovery record
Length of segment
Total number of segments
Sequence number of current segment
LRSN of the commit record for this unit of recovery
RBA of the commit record for this unit of recovery
Type of connection
Logical unit of work (LUW) network ID
LUW instance number
LUW commit sequence number
Y - record is part of a transaction (URID) that contains at least one log record that Log Master for DB2 cannot complete
Y - record is part of a transaction (URID) that might depend on another URID that contains at least one record that Log Master for DB2 cannot complete
Y - Part of a transaction (URID) that contains at least one compensation log record
N - Part of a transaction that contains no compensation log records
Used for sort key for SQL sort
A - Originating table space defined as PAGENUM ABSOLUTE, meaning that the page number in the RID field contains the embedded partition number
R - Originating table space defined as PAGENUM RELATIVE, meaning that the page number in the RID field contains only the page number
The PARTNUM field contains the partition number in both cases.
Length: First 2 bytes are a halfword value that contains total length of the data segment (including 2-byte length)
Content: After 2-byte length, content depends on update type:
For UB records (Update with both before and after data): before data is first; after data is next
Column order: within a row image, column order based on logical position within base table, not physical position within table row, column order based on COLNO column in SYSIBM.SYSCOLUMNS catalog table.
1 BIN(17) timestamps are of the format X'YYYYMMDDHHMMSSHHMMMMNNNPPPFFF00000' where:
YYYYMMDD is the date given as year, month, day
HHMMSS is the time given as hour, minute, seconds
HHMMMMNNNPPPFFF00000 represents fractional seconds and padding
BIN(10) LRSN is extended format LRSN.
Non-extended format LRSN, BIN(6) is placed at offset 1 (for example, X'CA670FBBF3D3' -> X'00CA670FBBF3D3000000').
BIN(10) RBA is extended format RBA.
Non-extended format RBA, BIN( 6) is placed at offset 4 (for example, X'123456789ABC' -> X'00000000123456789ABC').
The layout of the information in the DATA portion of the Data Change Record is similar to the layout of a DB2 log record, with the following exceptions:
All numeric fields (DB2 Types INT, SMALL INT, DEC, and FLOAT) are translated from the DB2 internal format to an external format. This translation enables the numeric value to be used in SAS or other application programs. However, if a column contains negative values, the translated value cannot be sorted correctly.
DATE, TIME, and TIMESTAMP fields are translated from the DB2 internal format to an external format (DB2, ISO, or SAS.) This translation means that more space is used to represent these fields in character format.
If a column (field) is nullable, the null byte precedes the data for that column.
Variable length fields contain a two-byte length attribute before the actual data. (This format is the same as in the DB2 log.)
For variable length fields that are nullable, the position of the null byte in the logical log is different than its position in the DB2 log. In the following example,
x'llll'represents the two-byte field length information and
x'nn'represents the null byte.
In addition to the null byte order being reversed, the length value in the DB2 log includes the one-byte length of the null byte. The extra byte is not included in the length value in the logical log.
If CHANGE TYPE is set to DM (mass delete), data segments might or might not exist. If the mass delete action is the result of a LOAD REPLACE of a specific partition, data segments will exist defining the limit key values.