Data Movement Utilities Guide and Reference

Using 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 roll-forward recovery to locate the load copy. It contains 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 may be overwritten before roll-forward recovery takes place.

In a partitioned database environment, the load copy location file must exist at each database partition server, and the file name (including the path) must be the same.

Following is an example of 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.

 
   TIMestamp      19950725182542         * Time stamp generated at load time
   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 Tivoli Storage Manager (TSM, formerly ADSM)
                                                           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
   SCH            PAYROLL
   TAB            DEPT
   DAT            DBT
   DB2            TORONTO
   SES            NULL
   BUF            NULL
   TYP            A
   TIM            19940325192054
   SCH            PAYROLL
   TAB            DEPT
   DAT            DBT
   DB2            TORONTO
   SES            NULL
   BUF            NULL
   TYP            O
   SHRlib         /@sys/lib/backup_vendor.a

Notes:

1. The first three characters of each keyword are significant. All keywords must be in the specified order. No blank lines are accepted.

2. The time stamp is in the format yyyymmddhhmmss.

3. All fields are mandatory, except for BUF and SES, which can be NULL.

4. The media type can be: local device (L for tape, disk or diskettes), Tivoli Storage Manager (A, formerly ADSM), or other vendor (O). If it is L, the number of locations, followed by the location entries, are required. If the type is A, no further input is required. If the type is O, the shared library name is required. For detailed information about using Tivoli Storage Manager (TSM) and other vendor products as backup media, see the "Tivoli Storage Manager" section of the database recovery chapter in the Administration Guide.

5. The SHRlib parameter points to a library whose function is to store the LOAD COPY data.

If you run LOAD COPY NO, and do not take a backup copy of the database or affected table spaces after running the load operation, you cannot restore the database or the table spaces to a point in time that is more recent than the load operation. That is, you cannot use roll-forward recovery to rebuild the database or the table spaces to their state after the load operation. You can only restore the database or the table spaces to a point in time that precedes the load operation.

If you want to use a particular load copy, the load time stamps are recorded in the recovery history file for the database. In a partitioned database environment, the recovery history file is local to each database partition.