If the directory is corrupted or the database is down and cannot be restarted due to a disk error, there are two ways to recover:
| Note: | If the input file is an incremental backup file, the incremental backup file will be processed first, then the FULL backup file will be required. |
In VM format it and restart with the parameter STARTUP=R.
In VSE,
In all cases, when restarting use the same LOGMODE as before. If this was LOGMODE=A, the log is synchronized. If this was LOGMODE=L, you are prompted for subsequent log files to be restored, and the log is synchronized.
Should you detect a user or program error, disable the dbspace containing the table to prevent more updates to the damaged table or to prevent users from getting incorrect data. This DISABLE DBSPACE command takes the specified dbspace offline so no access is allowed. Once you have determined how to fix this user error, you can use the ENABLE DBSPACE command to bring the dbspace back online and fix the problem.
The same procedure applies if there are persistent DB2 abnormal terminations in DBSS. In this case the database manager would terminate and display the message ARI040E which would identify a module whose first four characters are ARIY. To avoid more corruption, or until the problem is corrected, disable all the dbspaces involved.
Another way to recover from abnormal DBSS terminations would be to restore a DB2 archive, Data Restore archive or user archive and apply the log tapes with Filtered Log Recovery. This allows you to exclude some LUWs that affected the corrupted dbspace and might have led to the error.
The command sequence for disabling a dbspace and for forward log recovery is described in the DB2 Server for VSE & VM Diagnosis Guide and Reference manual.
You can replace the disk and restore the database as follows:
| Note: | If the input file is an incremental backup file, the incremental backup file will be processed first, then the FULL backup file will be required. |
In VM format it and restart with the parameter STARTUP=R.
In VSE,
In all cases, when restarting use the same LOGMODE as before. If this was LOGMODE=A, the log is synchronized. If this was LOGMODE=L, you are prompted for subsequent log files to be restored, and the log is synchronized.
For more information about restoring a storage pool and log recovery, refer to Log Recovery.
You can also try the following procedure, but it might not always work and can take more time than the storage pool level recovery or even the database restore:
There might be an occasion where the complete operation has to be moved to another system. In such a case, you would not only need a backup of the database, but also of all other disks that are related to the operating system and the database. In most cases you would restore an image copy of all DASDs.
Recommendation: Before making copies of all DASDs, shut down the database manager so that all data is written to disk.
If you need to move only the database to another system, you will need some files or jobs to restart your database. These files and jobs are related to the database but are neither saved by the DB2 ARCHIVE nor by the Data Restore BACKUP process. These are the database definitions and the log history file.
Database Definitions
| Note: | Restore fails if the extents are too small, and will not make use of the additional space if an extent is too large. |
| Note: | Especially important is to know the size of the internal dbspaces and in which pool they are, which is at the end of this file or of any job adding a dbspace, because that size cannot be queried through a SHOW POOL command. |
As an alternative you can restore a backup of the VSAM catalog containing the database extents; but this must reflect the actual status.
| Note: | Restore fails if the extents are too small, and will not make use of the additional space if an extent is too large. |
This PROC contains the database name and all DLBL statements identifying the dbextents. To keep track of these definitions when adding or deleting extents, punch this PROC after each change. You can also maintain your installation job; in our case this is ARIS35DB because SQL/DS V3.5 was installed first, and then migrated to DB2 V5.1.
This macro keeps information that was used for the generation of the database. During the installation, this macro might have been updated, or it had been copied into an installation job. It is not required for restore, but it is good practice to keep it updated to reflect the current status of extents, pools and dbspaces.
| Note: | Especially important is to know the size of the internal dbspaces and which pool they are in, which is at the end of this file or of any job adding a dbspace, because that size cannot be queried through a SHOW POOL command. |
Log History File
This file keeps the history information, which is also available in the last page of the current log, and which can be displayed with the DB2 operator command SHOW LOGHIST.
In VM the log history file is located on the work disk, default 191, of the database manager. This A-disk file is automatically used during a subsequent restore, if the log history area is unusable due to a log failure.
When a COLDLOG RECONFIGURE is performed, this file is copied to ARIHSDS PRECLDLG to ensure recoverability.
In VSE the log history information is only available in the current log. To back up this information a VSAM backup should be made offline of the log file LOGDSK1. After disaster recovery this backup should be restored and COLDLOG REFORMAT should be performed to clear all other log information.
If you restore the database to another system, or when you have replaced all disks, you cannot apply the log archive tapes without a recent copy of the log disk or of the externalized history file.
For LOGMODE=L, this is a question of to which point in time (which log archive tape) you plan to fall back in case of a disaster. If you want to be able to recover also the latest log archive, then whenever an archive or log archive is taken, you might want to immediately afterwards make a copy of the ARIHSDS ARCHIVE file.
For LOGMODE=A, on a different system you can only restore archives taken offline. Because at the begin archive checkpoint LUWs can have been active, an online archive would need forward recovery using the current log to get into a consistent state. Therefore, the log history file is less important for LOGMODE=A.