How recovery works in a data sharing group
In case you need to recover data, it can be helpful to understand how data recovery works in a data sharing environment.
Logs that are needed for recovery
Assume that three members of a data sharing group are making updates to table space TS1, as shown in the figure below.
- DB1A updates TS1 between Time 1 and 4 (SYSLGRNX record 1) with two updates (U1 and U4).
- DB3A updates TS1 between Time 2 and 5 (SYSLGRNX record 2) with three updates (U2, U3, and U5).
- DB2A updates TS1 between Time 6 and 13 (SYSLGRNX record 3) with three updates (U6, U8, and U13).
- DB1A updates TS1 again between Time 7 and 11 (SYSLGRNX record 4) with three updates (U7, U10, and U11).
- DB3A updates TS1 again between Time 9 and 15 (SYSLGRNX record 5) with four updates (U9, U12, U14 and U15).
Now, assume that you want to recover TS1 to time 9. The full image copy taken at T0 is used as the recovery base. All the SYSLGRNX records mentioned previously are selected to determine the log ranges of each system for the log scan. Updates U1 through U9 are applied in order.
How log records are applied
Db2 can access the logs of other Db2 subsystems in the group and merge them in sequence. The log record sequence number (LRSN) identifies the log records of a data sharing member. Multiple row insert might produce duplicate LRSNs for changes to the same page. The following figure illustrates the structure of the log record.
The log record header contains an LRSN. The LRSN is a 6-byte or 10-byte value that is greater than or equal to the timestamp value truncated to 6 or 10 bytes. This value also appears in the page header. During recovery, Db2 compares the LRSN in the log record to the LRSN in the page header before applying changes to disk. If the LRSN in the log record is larger than the LRSN on the data page, the change is applied.