Question & Answer
When are 10-byte RBA and LRSN values externalized in Db2 11 for z/OS?
Beginning in Version 11, Db2 uses 10-byte RBA and LRSN values in all migration modes. The extended RBA and LRSN values might be externalized before objects are converted, in certain contexts
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 expanded 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 left side of the value, as shown in the following table.
|6-byte RBA value:||10-byte RBA value:|
Conversion LRSN values
A 10-byte LRSN value is converted to a 10-byte value by adding one zero byte to the left side and 3 bytes added to the right side of the value, as shown in the following table.
|6-byte LRSN value:||10-byte LRSN value:|
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 value are externalized
In Version 11, the extended RBA and LRSN values might be externalized before objects are converted in certain contexts:
In Version 11, all messages use 10-byte RBA and LRSN values in all modes, so that all messages have consistent formats. 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.
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. In addition, after migration to NFM the installation can decide which format is used to create new database objects. 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.
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.
In conversion mode, the log content and format are identical to the Version 10 format. 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.
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.
The installation can convert the BSDSs at any time after migration to NFM. Because the conversion requires the owning Db2 member to be stopped, BSDSs in a data sharing group can be converted one member at a time. Db2 supports a data sharing group with different format BSDSs indefinitely. However, after a BSDS is converted, it cannot be restored to 6-byte format because it might contain information that cannot be truncated to the 6-byte format.
Catalog table columns
The Db2 catalog and directory contain RBA and LRSN information in several tables.
The definition of the catalog and directory columns that contain RBA or LRSN values is changed from 6-byte format to 10-byte format during the migration from CM to NFM. 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 within Db2. The actual values in the catalog depend on conversion step because the ENFM process is not a locked atomic operation.
The following situations are possible:
- In CM, the catalog and directory store 6-byte values.
- In ENFM, the format of the stored values depends on whether a specific table definition changed.
- In NFM and ENFM*, 10-byte values are stored.
- In CM*, the format depends on whether a specific table definition changed, if ENFM processing was not complete. If ENFM processing was complete at any point before the transition to CM*, 10-byte values are stored.
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.
The SCA is reformatted by a rebuild that is triggered during NFM migration. This step is not optional. In addition, an SCA rebuild might happen during group restart if the old-format SCA is found and the data sharing group is not in conversion mode.
After migration to NFM, the contents of some of the log records change to support the logging of SCA information after the SCA format change regardless of the actual log format.
In all migration modes, RBA and LRSN values are displayed in 10-byte format. 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.
Data pages and space map pages for the work file database use the 10-byte format as soon as they are first accessed in Version 11, regardless of whether the subsystem is migrated from Version 10 or is a new installation. However, for migrated subsystems, the Db2 catalog is not updated to reflect the format of the work files.
When object and BSDS formats do not match
Database objects can be converted to extended format after NFM migration as the installation sees fit. In data sharing, you do not need to convert all BSDSs in a data sharing group before the conversion of database objects begins. When an object is converted to the extended format, the change means that a 10-byte LRSN or RBA value is stored on the page, instead of a 6-byte value. That change does not mean that the converted object must have nonzero bytes in the expanded area.
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 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.
Expanded RBA and LRSN log records (What's new?)
Utility RBA and LRSN handling (What's new?)
What to do before RBA or LRSN limits are reached (Db2 Administration)
IBM Redbooks: Db2 11 for z/OS Technical Overview (see "The Extended RBA and LRSN")
Extended LRSN and RBA format support in IBM Db2 for z/OS (white paper)
16 June 2018