There are two kinds of archives using the DB2 product; a database archive and a log archive.
A database archive (DB2 archive) is a tape copy of the database directory and the dbextents. The database manager takes a checkpoint (the begin-archive checkpoint) and writes a copy of the database directory and the active data pages to tape, as they were at the checkpoint. A database archive does not include a copy of the log.
Archives can be taken either online (ARCHIVE) or in the process of being shut down, called "offline" (SQLEND ARCHIVE).
In SQL/DS V3R5, enhancements were made to improve the performance of the archive process:
A detailed description and a test result overview can be found in the SQL/DS Version 3 Release 5 Usage Guide.
A log archive is a tape or disk copy of the log, recording just the changes applied to the data since the last archive or log archive.
Log archives can be made between DB2 archives or user archives to improve the availability of the database. In most situations, if you are using log archive, the period between database archives is increased.
| Warning: | If you use LOGMODE=L on a database with lots of updates, when you restore the database the log recovery will have to re-execute all changes. This process can be very time consuming and use a lot of resources from the database or the system, especially the processor (CPU). |
Only DB2 facilities can be used to archive the log. The database manager must be running with the startup parameter LOGMODE=L. Log archives are taken when the database manager is either running or still running but in the process of being shut down.
The output for the log archive is defined by the FILEDEF (in VM) or TLBL/DLBL (in VSE) statement with ddname ARILARC. To be able to restore a database to its current level the log archives must be continuous.
For filtered log recovery, which excludes some operations from the UNDO/REDO process, refer to the DB2 Server for VSE & VM Diagnosis Guide and Reference manual.
For a detailed description of log archives refer to the DB2 Server for VM System Administration and DB2 Server for VSE System Administration manuals.
To perform the recovery procedure, the database manager has to be started with the STARTUP=R parameter. The directory and all dbextents are reloaded from the DB2 archive tape. Log archive files and log recovery can be applied after the restore of the data.
In VSE, STARTUP=F is equivalent to STARTUP=R in VM; in VSE, STARTUP=R first formats all dbextents, which can take longer than the restore process itself.
If LOGMODE=A and the archive being restored is not the last one taken, you must do a COLDLOG to avoid inconsistency or an abnormal end. But even so, if the archive restored was an online archive, the inconsistency due to active LUWs during the online archive cannot be resolved.
If LOGMODE=A and the latest archive is restored, the current log can be used for the UNDO/REDO process. This process makes a online archive, taken with LOGMODE=A, become consistent.
If LOGMODE=L, do not perform COLDLOG because this would prevent you from applying the log archives and the current log.
For detailed information how to restore a database from a DB2 archive refer to the DB2 Server for VSE System Administration or DB2 Server for VM System Administration manuals.
You can filter your log for the UNDO/REDO process. This means you can exclude some specific DB2 command(s) from the recovery process, and after that specific command the log application is resumed.
During RELOAD you are prompted for the log archives. You are prompted if you want to skip a log archive tape or file. The LISTLOG and APPLYLOG will execute only on the DB2 commands loaded into the work files during RELOAD.
The Data Restore BACKUP command creates a Data Restore archive of the entire database. The Data Restore BACKUP command is performed as a DB2 user archive, thus the database has to be offline. As the DB2 ARCHIVE, it includes the directory and dbextents and does not include the log.
The output can be used as input for either:
Data Restore BACKUP writes additional information to the beginning of the archive file which is used for a later Data Restore RELOAD of tables. This is equivalent to the work files SYS0001, HEADER and DIRWORK of TRANSLATE, as described on page ***.
If recovery to a certain 'point in time' is needed, the DB2 database must be running with LOGMODE=L or LOGMODE=A. This means that successive logs can be applied up to a certain point in time.
Data Restore BACKUP can be directed to tape, disk or both.
Files
The Data Restore BACKUP requires some input and output files:
If only one output is needed the FILEDEF (in VM) and DLBL/TLBL (in VSE) for ddname ARCHIV and the OPTIONS DEVICE= TAPE/DASD defines this output to tape or disk.
If dual backup is needed then the FILEDEF (in VM) or DLBL/TLBL (in VSE) for ddname ARCHIV2 and the OPTIONS DEVICE2=DASD or TAPE define the second output, which can be again either to tape or disk. Refer to Figure 161 for a sample JCL, or Figure 162 and Figure 163 for a sample exec and SYSIN for the BACKUP.
In VM the user, running the backup, must have access to the database production disk, default 195, because the "dbname SQLFDEF" file is used to link and access the database minidisks.
In VSE, the backup job must also execute the DLBL statements for directory and dbextents.
For backup to disk, the following restrictions apply:
Both FULL and INCREMENTAL backups are considered by the database manager as a user archive.
The BACKUP FULL archive includes the directory and dbextents, but not the log. This backup is equivalent to the one produced by the BACKUP function as explained in the previous paragraph, but can be a reference for a further INCREMENTAL backup.
The BACKUP INCREMENTAL archive includes the directory and only dbextent pages modified since the BACKUP FULL has been processed.
To process INCREMENTAL backup, a FULL BACKUP must be executed first to generate a complete copy.
The time necessary to process a BACKUP INCREMENTAL function is very low compared with any archive or user archive procedure.
While processing the INCREMENTAL BACKUP, there is no need to access any FULL archive.
In both cases, the output can be used as input for either:
Data Restore BACKUP writes additional information to the beginning of the archive file which is used for a later Data Restore RELOAD of tables. This is equivalent to the work files SYS0001, HEADER and DIRWORK of TRANSLATE, as described on page ***.
If recovery to a certain 'point in time' is needed, the DB2 database must be running with LOGMODE=L or LOGMODE=A. This means that successive logs can be applied up to a certain point in time.
Data Restore BACKUP can be directed to tape, disk or both.
Files
The Data Restore BACKUP requires some input and output files:
If only one output is needed the FILEDEF (in VM) and DLBL/TLBL (in VSE) for ddname ARCHIV and the OPTIONS DEVICE= TAPE/DASD defines this output to tape or disk.
If dual backup is needed then the FILEDEF (in VM) or DLBL/TLBL (in VSE) for ddname ARCHIV2 and the OPTIONS DEVICE2=DASD or TAPE define the second output, which can be again either to tape or disk. Refer to Figure 161 for a sample JCL, or Figure 162 and Figure 163 for a sample exec and SYSIN for the BACKUP.
In VM the user, running the backup, must have access to the database production disk, default 195, because the "dbname SQLFDEF" file is used to link and access the database minidisks.
In VSE, the backup job must also execute the DLBL statements for directory and dbextents.
For backup to disk, the following restrictions apply:
The Data Restore RESTORE command can be used to recover a single storage pool, a set of storage pools or an entire database after a system or disk failure, or to create a copy of the entire database on the same or another system. To run Data Restore RESTORE, the database manager must be offline.
For information about log recovery after RESTORE of a storage pool, refer to Log Recovery.
The input can be any of the following:
In VSE, the Data Restore feature formats the BDISK while restoring the database.
In VM, if the Data Restore feature attempts to read or write the database BDISK, a dbextent or log disk, the minidisk will be linked as the same CUU as the original database minidisk. The Data Restore feature must have authority to link to all database minidisks in write (W) mode. If a minidisk needs to be accessed, it will be accessed as filemode B, C, D, or E. These filemodes should be available before invoking RESTORE.
Files
The Data Restore RESTORE requires some input and output files:
If the archive file processed has been generated by the BACKUP INCREMENTAL function, a FULL archive will be accessed to complete processing. You will be prompted to mount the right FULL archive).
Note: If the FULLARC file is used, the DEVICE2 parameter on the OPTIONS statement, should specify TAPE or DASD.
Example
Figure 5 shows a sample of the JCL to use Data Restore RESTORE.
Figure 5. JCL File for Data Restore RESTORE
* $$ JOB JNM=DRFRESTR,CLASS=0,DISP=D * $$ LST CLASS=A,DISP=D,PRI=3,DEST=(*,VSESQADM) * $$ PUN CLASS=A,DISP=D,PRI=3,DEST=(*,VSESQADM) // JOB DRFRESTR RESTORE DATABASE WITH DRF from tape // LIBDEF *,SEARCH=(PRD2.DB2vrm,PRD2.RCVvrm) // EXEC PROC=SQLVSE02 // EXEC PROC=XTS9DLBL // TLBL ARCHIV // ASSGN SYS006,181 // MTC REW,SYS006 /* PAUSE for monitor // EXEC XTS91001,SIZE=AUTO CONTROL DBNAME=SQLVSE02 RESTORE /* /& * $$ EOJ |
Figure 6 shows a sample of the EXEC to use Data Restore RESTORE.
Figure 6. EXEC File for Data Restore RESTORE from Data Restore BACKUP (RESTORE EXEC)
/* */ /* FILEDEF FOR INPUT FROM TAPE */ 'FILEDEF ARCHIV TAP1 SL (RECFM VB BLOCK 32760' 'FILEDEF SYSIN DISK RESTORE SYSIN A' 'FILEDEF SYSPRINT DISK RESTORE SYSPRINT A' 'XTS91001' Exit rc |
Figure 7 shows a sample of the EXEC to use Data Restore RESTORE.
Figure 7. SYSIN File for Data Restore RESTORE from Data Restore BACKUP (RESTORE SYSIN)
OPTIONS DEVICE=TAPE CONFIRM=NO CONTROL BASE=ELDB2A RESTORE |
Data Restore BACKUP uses a different format than DB2 ARCHIVE. Therefore, a Data Restore archive cannot be used for a DB2 restore.
However, you can change a DB2 archive to a Data Restore archive format using the Data Restore TRANSLATE command; the only difference is that after TRANSLATE the work files need to be kept separately for a future Data Restore RELOAD with forward recovery, whereas this information is already at the beginning of a Data Restore archive file after BACKUP.
Table 1 gives you an overview of the compatibilities among the
methods that can be used to archive and recover your DB2 database.
Table 1. Compatibilities - Archive and Recovery
|
| ... can be Input to: | |||||
| Output from ... | DB2 RESTORE | Data Restore TRANSLATE | Data Restore DESCRIBE | Data Restore RELOAD | Data Restore RESTORE | Equivalent user restore |
| DB2 archive | X | X | - | X | - | - |
| Translated DB2 archive | - | - | X | X | X | - |
| Data Restore UNLOAD | - | - | X | X | - | - |
| Data Restore BACKUP | - | - | X | X | X | - |
| Any user archive | - | - | - | - | - | X |
The DESCRIBE function of the Data Restore feature lists the contents of a Data Restore BACKUP or UNLOAD file to determine which tables can be reloaded.
For the difference between filtered log recovery and APPLYLOG with forward log recovery to a certain point in time, see Log Recovery.
The following table gives you an overview of the methods and their possibilities to archive your DB2 database.
Table 2. Possibilities to Archive
|
|
| Database Manager | Data Restore |
|---|---|---|---|
| Function | User archive | ARCHIVE | BACKUP |
| Status database | |||
| online | - | X | - |
| offline | X | X | X |
Table 3 gives you an overview of the methods and their possibilities to restore your DB2 database. For "Data Restore RELOAD from TRANSLATE" (translated DB2 archive) see column "RELOAD from BACKUP".
| Assumption: | The database is running with LOGMODE=L or LOGMODE=A. |
Table 3. Possibilities to Recover
|
|
| Database Manager | Data Restore feature | |||
|---|---|---|---|---|---|---|
| Function | restore from User archive | restore from ARCHIVE | RESTORE | RELOAD from BACKUP | RELOAD from ARCHIVE | RELOAD from UNLOAD |
| Unit | ||||||
| table | - | - | - | X | X | X |
| storage pool | - | - | X | - | - | - |
| database | X | X | X | - | - | - |
| Status database | ||||||
| online | - | - | - | X | X | X |
| offline | X | X | X | - | - | - |
| Restore | ||||||
| last archive | X | X | X | X | X | - |
| any archive | X | X | X | X | X | - |
| Recover log | ||||||
| apply all | X | X | X | X | X | - |
| to log file border | X | X | X | - | - | - |
| to a point in time | - | - | - | X | X | - |
| filtered log | X | X | X | - | - | - |