The extended 10-byte RBA and LRSN in Db2 12

Beginning in Db2 11, Db2 uses the extended format 10-byte RBA and LRSN values, and conversion of the BSDS to the extended format is required at migration to Db2 12.

Differences between the 6-byte and 10-byte formats

The terms basic and extended are sometimes used to refer to the 6-byte and 10-byte formats. When these terms are used, basic format refers to the 6-byte format, and extended format refers to the extended 10-byte format.

Conversion of RBA values

A 6-byte RBA value is converted to the 10-byte format value by adding zeros to the 4 most significant bytes. That is, the zeros are added to the beginning of the value, as shown in the following table.

6-byte RBA value:	10-byte RBA value:
`112233445566`	`00000000112233445566`

Conversion LRSN values

A 6-byte LRSN value is converted to a 10-byte value by adding one zero byte to the beginning and 3 bytes added to the end of the value, as shown in the following table.

6-byte LRSN value:	10-byte LRSN value:
`112233445566`	`00112233445566000000`

The 3 bytes on the right side might be might be zero or x'FF', depending on the situation. For the beginning of an LRSN range, zeros are used. For the end of an LRSN range, x'FF' is used.

Internally, the values that are kept in memory are all 10 bytes, except when they need to be externalized to structures that remain in the 6-byte format. The values are stored internally as 10 bytes even in conversion mode. The conversion from the 10-byte values to 6-byte format is done at end points, such as when a log record is written, or when the PGLOGRBA field in a data or index page is updated.

When 10-byte format values are externalized

Extended RBA and LRSN values are externalized in the following contexts before objects are converted:

Messages

In Db2 12, all messages use 10-byte RBA and LRSN values, so that all messages have consistent formats. End of change

Sometimes Db2 needs an LRSN value that is not associated with a specific update. In this case, a log record with a matching LRSN might not exist. Such LRSN values are often generated with non-zero precision in the last 3 bytes, regardless of mode. Such full-precision 10-byte values might be seen in message output.

Database objects

The RBA (non-data sharing) or LRSN (data sharing) of the last change is stored in each page of every table and index.

When objects are in the basic format, the stored RBA or LRSN values are always 6 bytes. In the extended format, the stored RBA or LRSN values are 10 bytes. An installation typically converts objects from basic to extended format by using the REORG utility, but other methods exist. Start of change In addition, the installation can decide which format is used to create new database objects. End of change Database objects can be converted from extended to basic unless prohibited by a subsystem parameter.

Objects in basic format cannot be updated when the RBA or LRSN value is beyond the 6-byte range. For data sharing groups, the 6-byte LRSN range applies to the entire group and the 6-byte RBA range applies to each member. The 6-byte LRSN range does not apply to non-data sharing environments.

Recovery logs

The log records are assigned RBA values so that they can be located. In a data sharing environment, each log record has an associated LRSN value that is based on the time the log record was created. The LRSN value can be used to sequence log records from multiple members in a data sharing group.

All values that are passed to other Db2 components internally are 10-byte values padded with zeros. To all components outside of the log manager, the log always appears to be in the 10-byte format. Conversion of the log content to the new format that supports 10-byte RBA and LRSN values is completed when the installation converts the BSDSs to the 10-byte format. These two actions must be completed in lock step because the old BSDS format cannot accommodate larger RBA and LRSN values. For more information, see How RBA and LRSN values are displayed and .

Bootstrap data sets (BSDS)

The BSDS contains the LRSN and RBA values that bound each active and archive log data and a number of others that have various purposes.

Attention: In Db2 subsystems that are not data sharing members, if Db2 is already at risk of reaching the 6-byte RBA limit, it is strongly recommended that you first convert all catalog and directory objects, then convert all user objects to the 10-byte RBA format, before migrating to Db2 12.

Before you can convert the BSDS, the Db2 subsystem or data sharing member must be started in Db2 11 new-function mode.

In data sharing, you must convert the BSDS for each Db2 member separately.

At migration to Db2 12, you cannot start Db2 12 until the BSDS is converted to use the 10-byte RBA and LRSN formats. You can convert the BSDS before or during the Db2 12 migration process.

Attention: After the BSDS is converted to the 10-byte format, Db2 stops issuing messages to warn you about the risk of reaching the 6-byte RBA or LRSN limits. The increased size of all log records also accelerates progress toward the 6-byte RBA logging limit.

Continuously monitor the RBA and LRSN values until all catalog, directory, and user objects are converted to the 10-byte RBA or LRSN format. Failure to convert page sets before the 6-byte soft logging limit is reached results in failed updates with reason code 00C2026D, and any objects still in the 6-byte format become read-only. RBA or LRSN values greater than x'F00000000000' indicate that your system is at risk of reaching the 6-byte logging limit. For more information about the RBA and LRSN logging limits, see What to do before RBA or LRSN limits are reached.

For instructions, see Convert BSDS records to the extended 10-byte format: DSNTIJCB.

Catalog table columns

The Db2 catalog and directory contain RBA and LRSN information in several tables.

Start of change Catalog and directory columns that contain RBA or LRSN values use 10-byte format. End of change The catalog columns might be physically stored as either 6 bytes or 10 bytes. However, the values are converted to the 10-byte format as necessary when they are used in Db2.

Some 6-byte values still exist until a REORG of the affected catalog and directory tables is complete. The 6-byte values are padded with zeros when they are retrieved.

Shared communication area (SCA)

The SCA is used to track and communicate data pertinent to a data sharing group. This data always includes some LRSN and RBA values and there might be many such values, depending on the exception states of database objects.

Utilities

In Db2 12, RBA and LRSN values are displayed in 10-byte format. End of change

This 10-byte display is unrelated to migration of the catalog or directory, conversion of individual objects to extended format, or BSDS conversion. For recovery purposes, this 10-byte format is the preferred input format for Db2. When 10-byte RBA or LRSN values are specified as input to Db2, the values are converted to 6-byte format internally, as needed.

Work files

Data pages and space map pages for the work file database use the 10-byte format as soon as they are first accessed in Db2 11 or later (in any migration mode), regardless of whether the Db2 subsystem is migrated from DB2® 10 or is a new installation. However, for migrated subsystems, the Db2 catalog is not updated to reflect the format of the work files. For more information about work files, see Work file database.

When object and BSDS formats do not match

You can convert database objects to the 10-byte format when you are ready. End of change

In Db2 subsystems that are not data sharing members, always convert all Db2 catalog, directory, and user objects to use the extended 10-byte RBA format before you convert the BSDS, especially if Db2 is close to reaching the logging limit for the 6-byte RBA. Failure to convert page sets to the 10-byte RBA format before Db2 reaches the 6-byte logging limit results in failed updates with reason code 00C2026D. No updates are allowed for any object that is still in the 6-byte format.

If an object is in basic format and the log uses the 10-byte format, the LRSN that is stored in PGLOGRBA is truncated to fit. If a database object is in the extended format, and the log remains in the 6-byte format, LRSN values that are stored in the object are padded with zeros to the 10-byte format. Outside of data sharing environments, similar rules apply to RBA values.

When an object is in extended format and some members of the data sharing group have BSDS and logs in different formats, the order of updates is maintained. However, LRSN values from some members must be padded with zeros.

For a simple example, consider a data sharing group with two members:

M10 is a member that has logs in the 10-byte format.
M6 is a member that has logs in the 6-byte format.

Assume that the same data sharing group has two tables:

TExt is a table with extended format.
TBasic is a table with basic format.

The following illustration shows how a sequence of updates might look for the example data sharing group. These time values are for illustrative purposes. They are not representative of typical LRSN values because they correspond to updates that were completed in December, 1908.

      Time                Update       Content of PGLOGRBA or PGBigRBA
001000000001000002  M10 updates TBasic   100000000001 A 
001000000001000003  M10 updates TExt   00100000000001000003 B 
001000000001000004  M6  updates TExt   00100000000002000000 C 
001000000001000005  M6  updates TBasic   100000000002 D 
001000000002000001  M10 updates TBasic   100000000003 E 
001000000002000003  M10 updates TExt   00100000000002000003 F

Each of the example updates can be from different transactions, and the last two must be from separate transactions.

The logic ensures that the PGLOGRBA or PGBigRBA does not decrease, even though the two subsystems are logging updates with different formats.

For the first update A , the LRSN is truncated before it is placed in PGLOGRBA.
The value for the second update B stores the 10-byte format with full precision.
For the third update C , member M6 must generate an LRSN value that is greater than the 6 bytes that correspond to the old LRSN value. (If the LRSN is beyond the 6-byte range, updates are not allowed).
For the fourth update D , member M6 again generates a value that is greater than the existing PGLOGRBA or PGBigRBAvalue.
For the fifth update E , M10 must generate a larger value. A value greater than 00100000002FFFFFF is used because the TBasic table uses a 6-byte format LRSN.
For the last update F , the only requirement is that the LRSN must be greater than the existing value, so the time of the log record is used.

The log entry for the fifth update E occurs later in the log for M10 (a higher RBA value) because it was delayed in generating the LRSN value. This situation requires that the last two updates are from different transactions. Otherwise, the sixth update must wait for the fifth update to complete to ensure that the sixth transaction has a later LRSN and a later sequence in the log.