Recovering data with the load copy location file

The DB2LOADREC registry variable is used to identify the file with the load copy location information. This file is used during rollforward recovery to locate the load copy.

DB2LOADREC has information about:
  • Media type
  • Number of media devices to be used
  • Location of the load copy generated during a table load operation
  • File name of the load copy, if applicable

If the location file does not exist, or no matching entry is found in the file, the information from the log record is used.

The information in the file might be overwritten before rollforward recovery takes place.

Note:
  1. In a multi-partition database, the DB2LOADREC registry variable must be set for all the database partition servers using the db2set command.
  2. In a multi-partition database, the load copy file must exist at each database partition server, and the file name (including the path) must be the same.
  3. If an entry in the file identified by the DB2LOADREC registry variable is not valid, the old load copy location file is used to provide information to replace the invalid entry.
The following information is provided in the location file. The first five parameters must have valid values, and are used to identify the load copy. The entire structure is repeated for each load copy recorded. For example: 
TIMestamp      19950725182542         * Time stamp generated at load time
DBPartition    0                      * DB Partition number (OPTIONAL)
SCHema         PAYROLL                * Schema of table loaded
TABlename      EMPLOYEES              * Table name
DATabasename   DBT                    * Database name
DB2instance    toronto                * DB2INSTANCE
BUFfernumber   NULL                   * Number of buffers to be used for 
                                        recovery
SESsionnumber  NULL                   * Number of sessions to be used for 
                                        recovery
TYPeofmedia    L                      * Type of media - L for local device
                                                        A for TSM
                                                        O for other vendors
LOCationnumber 3                      * Number of locations
   ENTry       /u/toronto/dbt.payroll.employes.001
   ENT         /u/toronto/dbt.payroll.employes.002
   ENT         /dev/rmt0
TIM            19950725192054
DBP            18
SCH            PAYROLL
TAB            DEPT
DAT            DBT
DB2            toronto
BUF            NULL
SES            NULL
TYP            A
TIM            19940325192054
SCH            PAYROLL
TAB            DEPT
DAT            DBT
DB2            toronto
BUF            NULL
SES            NULL
TYP            O
SHRlib         /@sys/lib/backup_vendor.a
Note:
  1. The first three characters in each keyword are significant. All keywords are required in the specified order. Blank lines are not accepted.
  2. The time stamp is in the form yyyymmddhhmmss.
  3. All fields are mandatory, except for BUF and SES (which can be NULL), and DBP (which can be missing from the list). If SES is NULL, the value specified by the dft_loadrec_ses configuration parameter is used. If BUF is NULL, the default value is SES+2.
  4. If even one of the entries in the location file is invalid, the previous load copy location file is used to provide those values.
  5. The media type can be local device (L for tape, disk or diskettes), TSM (A), or other vendor (O). If the type is L, the number of locations, followed by the location entries, is required. If the type is A, no further input is required. If the type is O, the shared library name is required.
  6. The SHRlib parameter points to a library that has a function to store the load copy data.
  7. If you invoke a load operation, specifying the COPY NO or the NONRECOVERABLE option, and do not take a backup copy of the database or affected table spaces after the operation completes, you cannot restore the database or table spaces to a point in time that follows the load operation. That is, you cannot use rollforward recovery to re-create the database or table spaces to the state they were in following the load operation. You can only restore the database or table spaces to a point in time that precedes the load operation.

If you want to use a particular load copy, you can use the recovery history file for the database to determine the time stamp for that specific load operation. In a multi-partition database, the recovery history file is local to each database partition.