You must reconstruct a database or parts of it (one or more realms) if, for example, these files fail, are destroyed or are no longer accessible in the original database. Reconstruction involves two steps:
resetting the database to a backup status
updating the backup status with ALOG files
The time taken to reconstruct a database depends on how current your backup status is and how much modified data you need to apply.
Resetting to a backup status
The basis for reconstructing the database or parts of it is the database backup. The backup may have been made by
saving with HSMS or ARCHIVE
online saving with HSMS or ARCHIVE
copying the database
creating a shadow database
updating a backup status
To reset a database, i.e. generate the original, you must read in the backup once again (HSMS or ARCHIVE) and, if necessary, make it consistent (online saving); alternatively, you may have to copy it back or simply rename it (shadow database).
If you reset the entire database to a consistent status, you can resume database operation immediately as of this backup status. All changes that were made since then, however, will have been canceled. From this time onwards, the ALOG files are overwritten. If you still require the ALOG files, you must copy them beforehand.
If you reset only one realm or several realms, you must update them with ALOG files before you can resume database operation.
Updating the backup status
The BMEND utility routine makes it possible to update the entire database or individual or selected realms using one or more ALOG files. You can use BMEND for the original database, the shadow database and deactivated realms. You apply the ALOG files using the BMEND statement UPDATE-DATABASE.
The BMEND statement SHOW-LOG-INFORMATION tells you which ALOG files you must use to update the individual realms until you have reached a consistent status for the entire database, i.e. you must make these ALOG files available in order to bring the database up to date.
This statement also tells you whether there is a logging gap in the ALOG file sequence or whether an ALOG file has been terminated in an inconsistent state. In such cases, updating is possible only up to this point or after the database has been saved again.
Applying completed ALOG files
Updating means transferring the modified data from the ALOG file to the database (original or shadow database). A completed ALOG file, i.e. one that has been exchanged for another, is applied in its entirety. You specify the ALOG to which you want to update the database using the DEADLINE parameter of the BMEND statement UPDATE-DATABASE. BMEND automatically ascertains which file is to be used first to update a realm or the database. You must make this and all the other ALOG files up to the file specified in DEADLINE available.
It is also possible to control the application of completed ALOG files via a job variable (LINK-NAME = JVBMEND) within a procedure. The BMEND statement SHOW-LOG-INFORMATION supplies the job variable with information on the status of the DBDIR and of the log pool, e.g. with the name of the first ALOG file which is to be applied. Once an ALOG file has been applied successfully, the job variable is supplied with the next ALOG file, provided that you have not yet reached the predefined DEADLINE. Further information is provided in the "Recovery, Information and Reorganization" manual under BMEND.
Applying the current ALOG file
It is insufficient in some error situations simply to update to the last consistent status of a database (i.e. to the last completed ALOG file). If, for example, you want to reconstruct a failed realm from an aborted database session, you must also include the changes made to the current ALOG file which, in this case, is inconsistent. You can apply the current ALOG file by specifying DEADLINE=BREAK-POINT in the BMEND statement UPDATE-DATABASE.
If the last applied ALOG file is inconsistent, you must next perform a warm start.
Application of the current ALOG file is permitted only on the original database.
Updating a shadow database
The shadow database is updated using the completed ALOG files of the original database. As soon as the ALOG file has been changed for the original database, you can apply the completed ALOG file to the shadow database. This enables you to keep the data of the shadow database very current so that, in the event of an error, the reconstruction time is limited almost to the time taken to apply the current ALOG file.
You can update the shadow database while operation continues on the original database.
You can apply only completed ALOG files.
Updating a deactivated realm
If a hardware error occurs on a database realm, this realm is detached from database operation. A consistency point is set in the database and the ALOG file is switched. When reconstructing a realm, you can read in a backup status of the realm while operation continues on the original database and update it with the relevant ALOG files. You can then reattach the reconstructed, consistent realm to database operation.
ALOG file failure during a warm start
If the exceptional case arises that your ALOG file fails during a warm start due to a hardware error, it is no longer possible to roll back the open transactions on the ALOG file. If this occurs, you can use the BMEND statement KILL-LOG to force deactivation of AFIM logging. This enables you to perform a second warm start without AFIM logging, using the RLOG file.
This does, however, cause a gap in logging. To provide a basis for future reconstruction of the database, you should make another full backup of the database once you have performed the warm start (database consistency point) and activated AFIM logging (BMEND statement START-LOG.)