OBIDXLAT—Define OBIDs for Recreated Tables

The OBIDXLAT keyword defines the OBIDs of the table in the original tablespace and OBIDs of the table being recreated. If you do not specify OBIDXLAT, recovery occurs without the OBID translation.
cafrdb219
The OBIDXLAT keyword defines the OBIDs of the table in the original tablespace and OBIDs of the table being recreated. If you do not specify OBIDXLAT, recovery occurs without the OBID translation.
Syntax
OBIDXLAT {
old-obid
,
new-obid
}
  • old-obid
    Defines the old OBID value of the recreated table. If the tablespace contains only one table (HPGTBLC='0001'X), do not specify an old OBID. The automatic OBIDXLAT feature retrieves the OBID automatically.
  • new-obid
    Defines the new OBID value for the table being recreated. If the tablespace contains only one table (HPGTBLC='0001'X), do not specify a new OBID. The automatic OBIDXLAT feature retrieves the OBID automatically.
Define the old and new OBIDs for each table as an integer (the table OBID that is stored in the DB2 catalog) or as a hexadecimal number preceded by X and enclosed in single quotes.
:
  • To recover multiple tables in a tablespace, include an OBIDXLAT phrase for each table.
  • For nonpartitioned indexes, set MAXTASKS or PARALLEL to the number of indexes to recover.
  • If the tablespace has always contained only one table (HPGTBLC='0001'X), you can specify OBIDXLAT without an OBID parameters and the translation is performed automatically.
  • You can apply log records from different subsystems (the old OBID and new OBID can be on separate subsystems) if shared DASD is present and the SETUP parmlib member of the recovering system has a defined bootstrap data set. To apply log records, use STARTRBA or STARTLOGPOINT. The default is that no log records are applied.
  • An automatic image copy of the destination tablespace is created dynamically unless you specify NO-NEW-COPY. To allocate the image copy data set manually, use the QUICKCOPY keyword.
Restrictions
  • OBIDXLAT does not support concurrent copies.
  • OBIDXLAT processing cannot be used with the DB2 directory and catalog tablespaces (DSNDB01 and DSNDB06) to populate user-defined objects such as shadow or ACM tables.
  • The destination object must have the same DDL structure for the table and tablespace as the object when the source image copy was taken.
    Tablespace header pages may not reflect changes to the DDL that result in a new version record, such as altering a table, that were made before taking an image copy. If such an image copy is used as the source image copy, the recovery can fail. After you altered a table or tablespace, we recommend running REORG before you take an image copy. This processing ensures that header pages reflect all DDL changes.
  • Consistency checks for log ranges from different subsystems cannot be performed. Verify that the specified range does not include any not logged activity; for example, REORG with LOG=NO.
  • OBIDXLAT is
    not
    valid with LIST, RECOVER DATABASE, OBJ-LIST, and RECOVER INDEX.
  • OBIDXLAT with SORTLOG NO or SORTLOG CONCURRENT is
    not
    valid with LOG APPLY.
  • If you define OBIDXLAT
    with only one OBID
    , it is assumed that the tablespace contains only one table. In this case, there can be only one occurrence of the OBIDXLAT statement for the recovery job.