There are many options available with DB2 Server for VM to manage the backup and recovery process for a database. Control Center has been designed to be flexible enough to support any archiving methodology which is suitable for a particular environment or even a specific database. You must decide what type of archiving and recovery will be used for each database, as well as define these methodologies to the product for proper automation of both processes. This chapter provides you with all necessary information required to automate your archive and recovery processes using Control Center.
There are several types of archiving available with DB2 Server for VM. You must first decide on the methodology that best meets the needs and requirements of your environment. The DB2 Server for VM System Administration manual contains information that will help you decide on the best archiving methodology environment.
Before you begin the archive and recovery automation process, consider or perform the following:
Prior to starting an actual Control Center automated DB2 Server for VM database archive event, the product will need to know certain information about the archive about to take place: what archive media will be used, if a tape management system like VMTAPE or DYNAM/T is being used, and so on. Most, if not all, of this information should have been created during your Control Center and DB2 Server for VM database installations and is located in these files:
This file contains information that describes to the product the interfaces to tape management systems like VMTAPE and DYNAM/T. This file is created during the service machine's installation and is located on its 191 A-disk. Refer to the DB2 Server for VM Control Center Program Directory and Chapter 8, Managing the Environment for specific information regarding this file.
This module is created during the service machine's installation process and will be used by the product to request database tape mounts. Refer to the DB2 Server for VM Control Center Program Directory for specific information regarding this file.
|If Data Restore backups are used, then the SQMSTAPE EXEC is used to |execute some mount requests depending on values in the database PARMS file. See the Post Installation section of the DB2 Server for VM Control Center Program Directory for more information about this file.
The database PARMS file contains information specific to your database machine. The PARMS file contains information that will instruct the product as to archive medium type to be used, I/O blocking size for the specified media type, and the current series of tapes or disks to be used for the next log and archive to be done. For specific information regarding this file refer to About the Database Parameters Tool.
| Changing the Database PARMS File |
|---|
|
The CHKINTVL, DISPBIAS, DUMPTYPE, and LTIMEOUT parameters can be modified dynamically from the operator console without stopping and restarting the database. It is important, however, to remember that any changes made to the remaining database PARMS file will not take effect until the corresponding database machine is terminated and then restarted. This is because information regarding a database archive is defined at database startup time. Therefore, changes made to the PARMS file while the database machine is running the database will not be used in the event of an 'online' (database up) or SQLEND (database down) archive activity. |
The database TAPES file must be created during the process of the database setup with the product. It is critical to note that this file is used at database startup time to correctly establish required CMS FILEDEF and LABELDEF information that will be used in the event of a database archive. It is equally critical to recognize that this file is used by the product during archives to either tape or disk.
The database TAPES file maintains information about two types of archives: log archive and full archive. The full archive output media identifies media (tape or disk) to be used during the database full (not log) archive events. Log archive output media identifies media (tape or disk) to be used during the database log (logmode L only) archive events. For specific information regarding this file, refer to Chapter 8, Managing the Environment and also Chapter 11, Tape Management Tool.
| Changing Archive Output Media Types |
|---|
|
Changes to full archive output media types (disk to tape or tape to disk) will not take effect until the next product database startup. However, changes to the log archive output media, such as the addition or deletion of media, take immediate effect and will not require the database to be stopped then restarted. For both full and log archives, the media type (tape or disk) cannot be changed while the database machine is running, and will require that the database be stopped and restarted. Changes to media types while the database is running could cause database archive failures. |
There are three logmodes (Y,A,L) available for multiple user mode (MUM) operation of a database manager. The product fully supports each of these logmodes and their associated archiving methodology to either tape or disk. Furthermore, you can specify that your log archive media be tape and that your full database archive media be disk, or vice versa. The only restriction is that all log archives are of the same media type (tape or disk), and all full archives are of the same media type.
The product supports the ability to perform database archives to disk. This includes full database archives and log archives. To implement, database TAPES file and the database PARMS file must be defined as described in Chapter 16, Database Startup and Termination Tools. The PARMS file will have disk for Archive_media and/or Logarch_media rather than tape. The blksize parameters should reflect the minidisk block size.
Figure 98 is an example of the PARMS file parameters for archiving to disk.
Figure 98. Example Disk Archiving Database Parameters
:Archive_media.disk :Archive_blksize.4097 :Archive_series.100 :Logarch_media.disk :Logarch_blksize.4097 :Logarch_series.300 |
| Note: | You should not specify a virtual address of less than 200. Addresses between 180 and 190 are reserved for tape usage and are detached during product operation. |
Figure 99 is an example of the PARMS file parameters used when full database archives are done to tape and log archives are done to disk (logmode L).
Figure 99. Example Disk Log Archive Database Parameters
:Archive_media.tape :Archive_blksize.28672 :Archive_series.100 :Logarch_media.disk :Logarch_blksize.4097 :Logarch_series.300 |
All entries within the TAPES file must match the format which is appropriate for the entries within the PARMS file. Disk archiving entries are identical to those for tape archiving with the exception of the volid. The volid for disk archiving should be expressed as a filename, filemode, and cuu address. The Tape Management tool should be used to update the database TAPES file.
Figure 100. Example Disk Archive Tapes File
100 ARCHIVE 00000 00:00:00 UNUSED ARCHFN1 ARCHFT1 H 500 100 LOG 00000 00:00:00 UNUSED LOGFN1 LOGFT1 I 501 |
The example in Figure 100 indicates that a full database archive for series 100 will use CMS file ARCHFN1 ARCHFT1, located on minidisk H, which is accessed by the database machine with virtual address 500. A log archive for series 100 will use CMS file LOGFN1 LOGFT1, located on minidisk filemode I, which is accessed by the database machine with virtual address 501.
A single archive to disk cannot span multiple minidisks. Therefore, a full database archive must fit on a single minidisk, and a log archive must fit on a single minidisk. There is no multivolume support available for disk similar to that available for tape.
Another requirement of disk archiving under the product is that each output minidisk must be linked and accessed in read/write mode by the database machine prior to starting the database. The link statements can be added to the database virtual machine VM directory and the access statements can be added to the PROFILE EXEC on the database machine. It is your responsibility to assure that the minidisks are linked to the proper filemodes and virtual addresses as defined in the database TAPES file.
In order to support the rotation from one tape series to the next, all full archives |(ARIARCH) for DB2 Server for VM databases version 6.1 or |less must be executed with the SQLEND ARCHIVE command. This is so the product can issue CMS FILEDEF and LABELDEF commands that will direct the next archive series to the next SQLEND ARCHIVE command. Log archives can be executed while the database remains up and running. The database will prompt the product for a new output FILEDEF when a log archive is performed. This will allow the LARCHIVE function to be done during multiple user access of the database.
|For DB2 Server for VM databases version 7.1.0 or |greater, Control Center automatically updates the tape or disk file |information for the ARCHIVE (ARIARCH) FILEDEF or LABELDEF after each logmode |'A' or 'L' online full database archive. This |allows successive archives to be taken without overwriting the previous |archive's output.
|For DB2 Server for VM databases earlier than version |7.1.0, the user must either use SQLEND ARCHIVE or shut down and |restart the database after online archives so that archive FILEDEF and |LABELDEF can be updated with the next archives series tapes.
You can choose to perform full database archives to tape and do log archives to disk, both to tape, both to disk, or full database archive to disk and log archives to tape. The single minidisk restriction will only apply to the archive types that are done to disk. Therefore, if you choose to perform full database archives to disk, the entire database must be smaller than the available minidisk (essentially limited to one volume). Likewise, if you choose to perform log archives to disk, the entire log file must be smaller than the available minidisk (again limited to one volume).
A separate minidisk should be provided for each archive and log archive file defined in the TAPES file. This would be restricted by the number of filemodes that can be linked by the database machine at a given time. If this is too restrictive, you can define different archive output files on a single minidisk, as long as the minidisk is large enough to handle the multiple files.
The product maintains the database TAPES file. If you are performing log archives to disk, the database will not allow the same log archive output file name to be used twice. Therefore, the database will generate a new filename for the log archive with filename equal to the database name, and a filetype of the form mmddyyxx, where mmddyy is the month, day, and year and xx is a number between 01 and 99. Control Center will then replace the current filename and filetype in the TAPES file with this new one. This will assure that the uniqueness will be maintained.
This implies that you will still be required to create log entries in the database TAPES file for as many archive log files tapes as you will need between full archives. The FILEMODE and CUU entries will still be used by Control Center to direct the archive output, but the filename and filetype entries will be updated automatically when the log archive is executed. The initial filenames and filetypes supplied within the TAPES file are therefore only required as placeholders. The product will change them to the suggested names provided by the database when the log archive occurs. Examples of the TAPES file before and after a log archive under this scenario are given in Figure 101 and Figure 102.
Control Center will use the unique filename provided by the database for each disk log archive. Therefore, as files are created on the log archive output disk each time a log archive occurs, eventually the log disk will become full unless old log archives are erased.
The product provides for automatic cleanup of outdated log archive files on disk. The cleanup process is implemented within the tape series rotation function that occurs when a full database archive is performed. Before a new tape series is started, the old disk log archive files are erased for reuse.
At the completion of a full database archive, the product will automatically switch to another group of tapes within the TAPES file for the next archive, to prevent the next archive from writing over the previous archive. Within the group of tapes that was used for the just completed archive, the log archive files will no longer be valid for recovery purposes. It will therefore use the filenames of each log archive file in that group of tapes to perform erases on the target disk.
Figure 101. TAPES File BEFORE Log Archive
100 ARCHIVE 97001 11:02:03 FILLED ARCHFN1 ARCHFT1 H 500 100 LOG 00000 00:00:00 UNUSED LOGFN1 LOGFT1 I 501 100 LOG 00000 00:00:00 UNUSED LOGFN2 LOGFT2 I 501 200 ARCHIVE 00000 00:00:00 UNUSED ARCHFN2 ARCHFT2 H 500 200 LOG 00000 00:00:00 UNUSED LOGFN3 LOGFT3 I 501 200 LOG 00000 00:00:00 UNUSED LOGFN4 LOGFT4 I 501 |
Figure 102. TAPES File AFTER Log Archive
100 ARCHIVE 97001 11:02:03 FILLED ARCHFN1 ARCHFT1 H 500 100 LOG 97002 05:20:37 FILLED SQLDBA 01029201 I 501 100 LOG 00000 00:00:00 UNUSED LOGFN2 LOGFT2 I 501 200 ARCHIVE 00000 00:00:00 UNUSED ARCHFN2 ARCHFT2 H 500 200 LOG 00000 00:00:00 UNUSED LOGFN3 LOGFT3 I 501 200 LOG 00000 00:00:00 UNUSED LOGFN4 LOGFT4 I 501 |
|For DB2 Server for VM databases version |7.1.0 or greater, Control Center automatically updates the tape |or disk file information for the ARCHIVE (ARIARCH) FILEDEF or LABELDEF after |each logmode 'A' or 'L' online full database |archive. This allows successive archives to be taken without |overwriting the previous archive's output. For more information |about online FILEDEF and LABELDEF support, refer to FILEDEF and LABELDEF Support for Online Archives.
|For DB2 Server for VM databases earlier than version 7.1.0, |the user must either use SQLEND ARCHIVE or shut down and restart the database |after online archives so that archive FILEDEF and LABELDEF can be updated with |the next archives series tapes.
This chapter covers topics concerning the archive and recovery of a database and its log using DB2 Server for VM-provided utilities. The product does, however, provide the capability to interface with other non-DB2 Server for VM archive tools. You can, for example, have at your installation Data Dump Restore (DDR) jobs that provide you with minidisk backups of your database's minidisks. The product will allow you to easily interface with any such user archive processes and will even record information pertaining to the user archive, such as start and stop times. For more information regarding Control Center and user archiving, refer to Appendix F, User Archiving.
Control Center will automate and manage the execution of User Archives using Data Restore. See Chapter 19, Data Restore BACKUP for a complete description of the backup process.
The panel shown in Figure 103 is the interface for the Database Archiving tool. Provided are various archiving options, including the ability to schedule an archive or initiate one immediately. This panel is reached by selecting Option A on the Control Center Main Menu.
Figure 103. Database Archiving Options Panel
+--------------------------------------------------------------------------------+ | mm/dd/yyyy CONTROL CENTER hh:mm:ss | | *----------------------------- Initiate Archive ------------------------------*| | | Option ===> CTRLID: MSTRSRV1 || | | Database ===> SQLDBA NODE: VMSYSTM1 || | | || | | ************************ ARCHIVE COMMANDS ************************ || | | SA SQLEND ARCHIVE parms Full archive, data base down || | | SL SQLEND LARCHIVE parms Log archive, data base down || | | SU SQLEND UARCHIVE parms User archive, data base down || | | A ARCHIVE parms Full archive, data base up || | | L LARCHIVE Log archive, data base up || | | || | | ****************** Data Restore BACKUP COMMANDS ****************** || | | BU BACKUP parms Data Restore Backup || | | BI BACKUP INCREMENTAL parms Data Restore Incremental Backup || | | || | | Valid SQLEND Parms: DVERIFY, TRCPURGE || | | Valid Incremental Backup Parms: AUTOfull NOAUTOfull || | | || | | Enter OPTION and PARMS, press ENTER to Process || | | || | *---------------------------------------------------------------SQMAR10-------*| | 1 Help 3 End (Cancel) | | | +--------------------------------------------------------------------------------+
There are several types of archiving available with the database. The types available and the archiving process under the product are described next.
The Archiving option of the panel interface will provide all functions which relate to database archiving. The first two functions offered are archive Initiation and Scheduling. Both functions provide a choice of what archive command you want to be performed.
When an archive is initiated under the product, no further action will be required by you, unless the option chosen is SQLEND UARCHIVE (user-defined archive). If the SQLEND option is selected, the database will be brought down to perform the archive. The UARCHIVE processing and functions that you must perform are discussed in Appendix F, User Archiving.
| Operational Note: | The following situation applies only if the SQLEND QUICK parameter has been set to 'Y' in the database parameters file (see Utility Parameters.) If users are connected to the database when the SQLEND command is issued, Control Center will detect this and issue the SQLEND QUICK command to bring the database down immediately. To prevent this impact to users, you should issue the SHOW USERS command prior to initiating an archive. |
Only persons identified as having |operator or greater authority (specified using the Database Parameters tool) for a given database can initiate |or cancel database archives. Those persons identified as administrators, for other databases or persons with user or operator authority cannot initiate database recoveries.
If you selected the Scheduling option, then after selecting the type to be performed, the Job Scheduling tool is invoked.
Archive commands available with the product include ARCHIVE, LARCHIVE, SQLEND ARCHIVE, SQLEND LARCHIVE, and SQLEND UARCHIVE. Each SQLEND choice can also include the DVERIFY option (which verifies the integrity of the database directory when the database is brought down), and the TRCPURGE option (which purges contents of a trace buffer at shutdown).
If the LARCHIVE command is issued without SQLEND, the product will initiate the archive while the database remains operational. Consider the LARCHIVE command rather than the SQLEND LARCHIVE command. This will initiate the log archive process while the database remains up and will reduce the database unavailability. Since a multivolume tape LABELDEF is not issued for log tapes, the product will properly mount and use each successive log tape for log archives between full database archives. Note: Control Center was designed to work with a single tape per log archive.
The impact to interactive database users during a log archive with the LARCHIVE command is minimized by the product. When you request the LARCHIVE, it will first issue the tape MOUNT request prior to issuing the LARCHIVE command to the database. When the tape is mounted, the product issues the LARCHIVE command and the log archive begins. When the LARCHIVE command is issued, the database will prohibit any new Logical Units of Work (LUWs) from beginning until the archive begins. If the LARCHIVE command is issued before the tape is mounted, there can be a lengthy delay to database users until the tape is mounted. The product eliminates the tape mount delay for explicit log archives.
Implicit archives will be initiated automatically by the database when the Archpct of the log file is reached. Logmode A will cause an implicit full archive, and logmode L will cause an implicit log archive. Since this is initiated by the database, the product will not be able to request the tape mount prior to the database archive command. This |may result in a significant delay to interactive users while waiting for the tape mount to occur. You should therefore initiate an explicit log archive command if the SHOW LOG command indicates that the log file is near the Archpct value.
There are several ways that you can prevent an implicit archive from occurring during the busiest interactive usage of a database. One way would be to schedule a log archive (or full archive for logmode A) at intervals that will normally prevent the Archpct from being reached. Another way would be to schedule a database monitor routine that will periodically check the log percent (using SHOW LOG) and will explicitly initiate the archive if the log is near the Archpct value.
Although it can be executed with Control Center, the ARCHIVE command should not be used without SQLEND (while the database remains operational) |for databases less than version 7.1.0. Due to the tape LABELDEF commands being issued only when the database starts up, an ARCHIVE without bringing the database down will not reset the tapes for the next archive. If two consecutive archives are done without bringing the database down, then the second archive will use the same tapes as the first archive, eliminating back-level protection.
|For DB2 Server for VM databases version 7.1.0 or |greater, Control Center automatically updates the tape or disk file |information for the ARCHIVE (ARIARCH) FILEDEF or LABELDEF after each logmode |'A' or 'L' online full database archive. This |allows successive archives to be taken without overwriting the previous |archive's output.
|For DB2 Server for VM databases earlier than version |7.1.0, the user must either use SQLEND ARCHIVE or shut down and |restart the database after online archives so that archive FILEDEF and |LABELDEF can be updated with the next archives series tapes.
For User Archives that do not use Data Restore, the UARCHIVE command must be issued with the SQLEND keyword. There can be many user-defined methods of archiving a database outside of DB2 Server for VM, that is, use of VMBACKUP, DDR, VMBARS, SYBACK. These options are all done outside of Control Center control. Only Data Restore backups are explicitly supported by Control Center however, the product does aid in starting the process, and in bringing up the database upon completion of the user archive (whether successful or not). For complete details regarding user archiving, refer to Appendix F, User Archiving.
The Cancel option can be used to cancel an active archive |by users with operator or a higher level of authority. Due to the difficulty in determining what step the archive is in, cancellation cannot be performed gracefully without impact to the database. The Cancel command will therefore force a failure of the active archive by issuing a detach command for the tape drive or disk device being used for the database archive process. This will cause a WRITE error on that hardware device and cause the database to crash. For DB2 Server for VM initiated archives, it will then be your responsibility to update the TAPES file and the database status prior to starting the database back up.
For |non-Data Restore user archives, a user archive cancel process will invoke a customer/user-created cancel routine. The cancel routine process will end with a user archive failed message sent to the database, which will then cause the product to bring up the database and respond to the database, indicating that the user archive failed. For more information on this routine and user archiving, refer to Appendix F, User Archiving.
The View Job Schedule option displays all scheduled jobs that relate to the specified database. From this display, you will also be able to view, modify, or delete any listed jobs. Refer to Job Schedule List Tool for additional information.
The History option displays the archive history log for the specified database. This log contains the date, time, and tape usage information for all archive and recovery activity. The file is the key component used by the product to automate the database recovery process.
The ARCHHIST file is continually updated by appending any activities that affect database recoverability. These activities include archives, recoveries, logmode changes, and COLDLOGs. The file is edited to remove entries which are no longer applicable (when a new series gets overwritten). Figure 104 provides an example of the ARCHHIST file for database SQLDBA.
Figure 104. Example ARCHHIST File Showing Incremental Backup, Full Backup, and DB2 Archives
The Log option displays the latest archive log for the specified database. This log contains the console output that was produced during the last archive. This can be used for failure analysis when an archive is unsuccessful.
Figure 105 provides an example of the ARCHLOG file for an archive under Control Center. All highlighted entries in the example are responses made automatically by the product. All other entries are messages received from the database machine during the archive process.
Figure 105. Example ARCHLOG File Showing DB2 Archive
00:31:46 SQLDBA SQLEND ARCHIVE issued from MSTRSRV1 AT VMSYSTM1 00:31:46 ARI0028I The database manager is terminating. 00:31:46 ARI0065I Operator command processing is complete. 00:31:46 ARI2008I Archive is about to be started. 00:31:46 ARI0254I The database manager is initiating a log archive. 00:31:46 When it is completed, the database manager will 00:31:46 process the database archive request. 00:31:50 ARI0293I Archive is starting. 00:31:51 ARI0239I External labeling of this archive is: 00:31:51 Type: log archive 00:31:53 Timestamp: 01-10-97 00:31:46 00:31:53 ARI0252I Medium: disk SQLDBA 01109701 F 00:31:56 ARI0246D The above information describes the log archive 00:31:56 about to be done. Enter either: 00:31:56 CONTINUE to proceed using the output medium 00:31:56 indicated, or 00:31:56 CHANGE to change this medium. 00:31:56 CHANGE 00:31:57 ARI0263D To direct the log archive to tape, enter tape followed 00:31:57 by the tape address (CUU) to be used. 00:31:57 To direct the log archive to disk, enter disk followed 00:31:57 by the disk file name, file type, and file mode. 00:31:57 If you chose disk, the default file is: 00:31:57 SQLDBA 01109201 F 00:31:57 disk = = G 00:31:58 ARI0239I External labeling of this archive is: 00:31:58 Type: log archive 00:32:00 Timestamp: 01-10-97 00:31:46 00:32:00 ARI0252I Medium: disk SQLDBA 01109701 G 00:32:02 ARI0246D The above information describes the log archive 00:32:03 about to be done. Enter either: 00:32:03 CONTINUE to proceed using the output medium 00:32:03 indicated, or 00:32:03 CHANGE to change this medium. 00:32:03 CONTINUE 00:32:08 ARI0292I Archive is completed. 00:32:12 ARI0293I Archive is starting. 00:32:12 ARI0239I External labeling of this archive is: 00:32:12 Type: database archive 00:32:13 Tape mount issued for: VM1203 181 00:32:13 Timestamp: 01-10-97 00:32:08 00:32:13 ARI0299A Ready archive output volume. Enter the CUU. 00:36:34 tape 3F21 ATTACHED TO SQLDBA 0181 00:36:36 181 01:20:22 DMSTLM428I TAP1(181) EOV1 label written on VM1203 01:20:23 tape 0181 DETACHED 01:21:57 tape 3F21 ATTACHED TO SQLDBA 0181 01:26:48 ARI0292I Archive is completed. 01:26:54 ARI0032I The Database manager has terminated. 01:26:54 ARI0043I Database manager return code is '0'. |
The View Tapes options displays the database TAPES file for the specified database. Refer to Overview.
The Tape Maintenance option provides you with a method of updating the database TAPES file. Refer to Overview.
The Scratch Tape Acquisition option acquires a scratch tape and automatically adds it to the database TAPES. It is applicable only when using VMTAPE or DYNAMT. If you have DYNAMT installed and have not specified DYNOPEN as the DYNAMT method for handling tapes, or DYNMOUNT is the chosen method for tape command processing, then DYNAMT will support scratch tape acquisition. Otherwise, DYNOPEN will not support scratch tape acquisition.
The panel shown in Figure 106 is the interface for the Database Recovery tool. Provided are various recovery options, including the ability to schedule a recovery or initiate one immediately. This panel is reached by selecting Option R (Database Recovery) on the Control Center Main Menu panel.
If you are using Data Restore as your vehicle for recovery, refer to the appropriate chapters in this manual for more detailed information.
Figure 106. Database Recovery Option Panel
+--------------------------------------------------------------------------------+ | mm/dd/yyyy CONTROL CENTER hh:mm:ss | |*--------------------------------- Recovery --------------------------------* | || Option ===> CTRLID: MSTRSRV1 | | || Database ===> SQLDBA NODE: VMSYSTM1 | | || | | || I INITIATE RECOVERY Immediate recovery initiation | | || S SCHEDULE RECOVERY Schedule a recovery | | || C CANCEL RECOVERY Immediate cancel of active recovery | | || R INITIATE FAILURE RESTART Restart the log archive recovery process | | || DR RESTART DATA RESTORE Restart the Data Restore part of recovery | | || VJ VIEW JOB SCHEDULE View database job schedule | | || H HISTORY Display history of archives | | || L LOG View log of previous recovery | | || VT VIEW TAPES View tape catalog | | || TM TAPE MAINTENANCE Make changes to tape catalog | | || ST SCRATCH TAPE ACQUISITION Acquire a new SCRATCH tape and | | || add volid to TAPES file | | || | | || Enter OPTION, select DATABASE, press ENTER to process | | || | | || | | |*---------------------------------------------------------------SQMRECOV----* | | PF: 1 Help 3 End | | | +--------------------------------------------------------------------------------+
The database recovery feature supports the automatic restore of a database that has been running with either logmode A, L, or Y and archiving using the database archive facility to tapes or disk, and additionally archiving using 'user archive'. Thus, the product supports automatic recoveries of databases with a STARTUP parm of R or U.
The recovery process obtains information about database archive activity from the ARCHHIST file and not from the database history records. If you have not been using the product to manage a database's archives, COLDLOGs, logmode switches, and recoveries, then recovery information available to it will be incomplete. In other words, the recovery process only knows as much as the product has been told.
| Usage Consideration: | Before you invoke any kind of database recovery, be certain you are completely familiar with the database recovery topics and considerations outlined in the DB2 Server for VM System Administration manual. |
The automatic recovery features were created to eliminate the need for manual support during a database restore. The process of running a manual database restore requires stopping the database, pre-recovery file and label definitions, startup parameter modifications, tape mounts, tape confirmations, starting the database, responding to console messages, interpreting console messages, reacting to recovery errors, keeping a recovery log, post-recovery database environment changes, and so on. The automated recovery feature will perform all these activities from start to completion of a database recovery.
Only those persons identified as administrators for a given database or Control Center administrators can initiate database recoveries. Persons authorized as administrators to other databases and persons with Control Center user or operator-level authority cannot initiate recoveries.
The recovery process of the product uses information created during database archiving. If there is no archive history data for a database, automatic recovery is still possible but starting the recovery will require that you perform some manual setup work and is therefore not suggested. A recovery control file is created by the product as a result of reviewing a database's ARCHHIST file data. The control file is sent to you for review. You will then be able to review exactly how it will control the recovery and decide to proceed or cancel the initiation process.
After completion of the recovery, the database machine will be stopped, its startup parameter changed to W, and then restarted.
The next database archive series to be used in the event of a database archive or log archive should be reviewed after the recovery. The recovery process does not reset the archive tape rotation series.
The database logmode will be set to the logmode used for the recovery. You must use the logmode switching feature of the product to change this logmode if it is not the one required.
For information regarding the product and database recoveries involving user archives, refer to Appendix F, User Archiving.
If you are using Data Restore to RESTORE your database or objects within the database, see Chapter 20, Data Restore RESTORE for more detailed information.
Although command mode execution is possible for database recovery, the preferred method is to use the panel interface to initiate the recovery process. Several panels will prompt you for critical recovery information that will tell the product how to answer the many questions that will be asked by the database during the actual restore.
The following sequence of panels will provide an overview of the recovery initiation process using Control Center.
The panel shown in Figure 107 allows you to select the logmode that you wish to use for the recovery (either L or A), and allows you to specify ALL if you want to see all available restore sets (all previous archives). Leave blank (the default) to display only the most recent archive. If your database has been running with logmode L, then you should specify L here. If your database runs with logmode A or Y, then specify A for this parameter.
Figure 107. Control Center Recovery Selection Panel
+--------------------------------------------------------------------------------+ | mm/dd/yyyy CONTROL CENTER hh:mm:ss | | *----------------------------- Recovery Selection --------------------------* | | | Command ==> CTRLID: MSTRSRV1 | | | | Database ===> SQLDBA NODE: VMSYSTM1 | | | | | | | | Logmode ===> L Logmode for the recovery | | | | Restore Set ===> ___ Archive Restore Set to display | | | | ( Blank for LATEST or ALL for all available ) | | | | To recover a data base, you must select the logmode for the | | | | recovery and select the archive restore set to use. The archive | | | | restore set is a group of tapes that were used for a previous data | | | | base archive. You may choose ALL to display all available restore | | | | sets, or you may let the restore set BLANK to retrieve the LATEST | | | | restore set. | | | | | | | | The selected restore set will be displayed and you will be asked to | | | | enter the restore set number to begin the recovery. | | | | | | | | Enter Logmode and Restore Set, press ENTER to process, or | | | | press PF3 to QUIT | | | | | | | *---------------------------------------------------------------SQMAR60-----* | | PF: 1 Help 3 End (Quit) | | | +--------------------------------------------------------------------------------+
Automatic database recoveries can be specified to use either logmode A or L. The database STARTUP parameters will be set to R when the database is to be restored from an archive that was created by database archiving facilities. It is set to U when the database is to be restored from an archive that was created by user archive facilities. The database uses information in its history area to associate log archives with database archives. When a DB2 Server for VM-based recovery is started, the database will look at identification information on the database archive tape or disk that is mounted for the recovery. The database then reviews its history information about this archive to determine all log archives associated with this database archive, if any. Like the database, the product reviews its own history records and determines what tapes or disks or user restore sets are to be used during the recovery process.
You can specify a recovery logmode that is different from the logmode used when the database archive was created. Note, however, that after the recovery process completes the database will be running under the recovery logmode specified. To return to the original logmode, you must initiate a Control Center logmode switch process.
The files identified by the product that drive a database recovery are referred to as a 'restore set'. Restore sets determined by the product will vary depending upon the logmode that you choose to recover with as well as the type of medium used (tape or disk) and the type of archive (user archive or database archive). In most cases you will choose a recovery logmode that matches the logmode associated with the database archive taken. Why you might recover a database using a different logmode than what is normally used is a topic that will not be discussed in this manual. Consult the DB2 Server for VM System Administration manual for more information about database recovery logmodes.
Recovering a database using logmode L tells the product to create a restore set containing all database archive files (or user archive set) and all associated log archive tapes. It will scan its history information for this database to determine what log archives are associated with the specified database archive. If the product had been used to perform database activities which cause log tape continuity to be broken, then the product will create a restore set considering such events. Consult the DB2 Server for VM System Administration manual for a list of activities which cause log continuity to be broken. If you do not use the product to process these types of activities, then your restore set created might contain too many log tapes. It will, in this case, restore as many tapes as possible before the database ends the recovery process successfully. Be sure to review the recovery log that the product sends to you upon completion of the recovery process to be sure that the recovery was processed as expected.
You can recover using logmode L from a back-level database archive. A back-level database archive is not the most current database archive known to DB2 Server for VM. In such a case, it may be possible to recover to the back-level database archive and use log archive tapes to recover forward to the most current database, provided that log continuity had been maintained from the back-level archive. In all cases, the database will permit the recovery process to apply all log archives that history records have associated with a specific database archive.
An END RESTORE volume can be specified to the recovery process. The volume specified can only be a log archive volume that you do not want to restore. The product will recover all log archives up to but not including the END RESTORE volume that you specify. Any log archive volumes that would have been recovered after this volume are also not recovered. In other words, the recovery ends after restore of any log archives up to but not including the specified volume. Great care should be taken to specify the correct volume that you wish to end the database recovery at, because after you have recovered it may not be possible to recover the end restore log and any subsequent log archives. Consult the DB2 Server for VM System Administration manual for information on specifying END RESTORE volumes.
If you do not want the currently active log to be restored during the database recovery, then specify ACTIVE for the END RESTORE volid. The product will recover all log archives prior to the currently active and yet-to-be-archived log.
| Operational Note: | Even though the active log will not be recovered, it will still be log archived. |
Recovering a database using logmode A tells the product to create a restore set containing only database archive files. You will also specify what is to be done with the active yet-to-be-archived log. The active log can be emptied (COLDLOGed) before the recovery process begins, or left intact to be restored as a part of the recovery.
You can recover using logmode A from a back-level database archive. Specify that a COLDLOG be performed; otherwise, changes contained within the currently active log will be restored to the database. This could cause many data consistency problems.
A database can be recovered using logmode A using a database created using logmode L. The database will detect that there are log archives available and will ask if the recovery logmode should be switched to L so that they can be applied. The product will tell the recovery process not to switch to logmode L and not to apply the log archives. If you want the log archives applied, then logmode L should be specified to the product for the recovery logmode. Figure 108 displays the logmode L panel. This panel will differ slightly if logmode A is chosen.
Figure 108. Control Center Restore Set Selection Panel
+--------------------------------------------------------------------------------+ | mm/dd/yyyy Control Center hh:mm:ss | | *-------------------------- Restore Set Selection --------------------------* | | | Command ==> CTRLID: MSTRSRV1 | | | | Database ===> SQLDBA NODE: VMSYSTM1 | | | | | | | | Logmode ===> L Logmode for the recovery | | | | Restore Set ===> 1 Archive Restore Set number to Use | | | | (Select from the list below) | | | | Partial Restore ===> N (Y,N) Perform PARTIAL Restore | | | | Use Data Restore ===> Y (Y,N) Restore from a Data Restore | | | | Backup or Translated archive. | | | | ------------------ Valid Restore Sets ------------------- | | | | 1 (07/03/98), 2 (07-02-98), 3 (06/25/98), 4 (06/25/98) | | | | | | | | | | | | NOTE: If you do NOT want to perform a COMPLETE restore, but instead | | | | only want to apply selected LOGS, then enter Y for Partial | | | | Restore and you will be prompted for additional information. | | | | | | | | Enter Restore Set and press ENTER to process, or press PF3 to QUIT | | | | | | | *---------------------------------------------------------------SQMAR70-----* | | PF: 1 Help 3 End (Quit) | | | +--------------------------------------------------------------------------------+
If Data Restore is enabled and you have been using Data Restore BACKUPs and TRANSLATEs, refer to section Chapter 20, Data Restore RESTORE. If you are not using Data Restore, the value in the Use Data Restore field in the menu shown in Figure 108 should be N.
If the restore set chosen includes an archive that has been translated by Data Restore, then you have the option of choosing 'Y' to recover using the translate or 'N' to recover from the archive.
If a partial log recover has been selected, you will be taken to the 'Partial Log Recovery' menu after completing the 'Data Restore Recovery Options' menu.
If the restore set chosen does not include a Data Restore BACKUP (either normal, incremental or full) or a translated archive, then this value will automatically be set to 'N'.
Figure 109 shows the Data Restore Recovery Options menu.
Figure 109. Data Restore Recovery Options Menu
+--------------------------------------------------------------------------------+ | mm/dd/yyyy Control Center hh:mm:ss | | *----------------------- Data Restore Recovery Options ---------------------* | | | Command ==> CTRLID: MSTRSRV1 | | | | Database ===> SQLDBA NODE: VMSYSTM1 | | | | | | | | Restore Set: 1 From: DUALINCBACKUP | | | | | | | | | | | | Backup Source ===> 1 (1,2) Restore using primary (1) or | | | | secondary (2) backup source. | | | | | | | | Reference Source ===> 1 (1,2) Use primary (1) or secondary (2) | | | | reference backup source to complete restore | | | | of incremental backup. | | | | | | | | | | | | | | | | | | | | | | | | Enter options and press ENTER to process, or press PF3 to RETURN | | | | | | | *---------------------------------------------------------------SQMAR72-----* | | PF: 1 Help 3 Return | | | +--------------------------------------------------------------------------------+
After making your entries, press the ENTER key; a report will be displayed containing historical archiving information which pertains to your selections. View this information for accuracy and decide on the restore set that you wish to use. After pressing PF3 to exit the report display, a panel will be displayed that will ask you to specify a restore set number. This panel reflects a selected logmode of L and will differ slightly if logmode A is chosen.
Finally, if you initially selected Option S from the main recovery panel, you will be presented with a screen that will allow you to specify when your recovery is to be started.
A request can be made by authorized persons to stop a currently active database recovery. The product will then update recovery status information indicating that the recovery is to be interrupted. It will wait until there is an opportunity to respond to the database recovery prompt messages in order to gracefully terminate the recovery processing. This is done so that, if possible, the recovery can be restarted from the point of termination, to avoid having to restart the database's recovery from the beginning. In the case of a recovery from a user archive, the product invokes the routine specified in the Cancel-routine field of the database PARMS file. This routine executes the command to the database to initiate the cancel of the user recovery if so coded by the user. The database remains down. If there is no cancel-routine specified, the product issues a warning message to the administrator in a note file to start the database after recovery from a user archive has completed. The database remains down.
The cancel recovery option is invoked by using the recovery menu system. If a recovery has been scheduled and has not started yet, then simply display the recovery schedule and specify that it is to be deleted.
If the log archive portion of a recovery fails, it may be possible to resolve the problem that caused the error and restart the recovery process from the point of error, avoiding restarting from the beginning. If the product detects an error during the recovery or the recovery is stopped by an administrator, then the database STARTUP parameter is set to W. After resolution of the problem, the recovery can be restarted using the the product recovery restart option. Please note, however, that if the recovery process had not started the log archive restore portion of the recovery process, then the recovery must be restarted from the beginning. The start of the log archive restore is indicated by the recovery information message ARI0260I. If the message ARI0260I was displayed by database, then the recovery can be restarted from the point of failure. If it had not been displayed, then the recovery must be restarted from the beginning.
If you are recovering from a Data Restore Backup and the recovery of the directory and data disks fails, it may be possible to resolve the problem that caused the error and restart the restore process on the Data Restore machine. If a Data Restore restore fails the database will be left down and the STARTUP mode parameter will be "U".
The View Job Schedule option displays all scheduled jobs that relate to the specified database. From this display, you will also be able to view, modify, or delete any listed jobs. Refer to Job Schedule List Tool for additional information.
The database's ARCHHIST file will be updated as if a database archive had occurred. If any log tapes were recovered, then the ARCHHIST file will be updated to indicate that log archives were done. This is done because recovery history information is recorded by the database in its history log, changing future restore set information. The recovered database archive and any recovered log archives will be distinguished from regular archive activity in the ARCHHIST file by a status of RECOVERED to the right of the archive record.
During recovery of an archived database, status messages about key events during the recovery process will be sent out to all the database's administrators. The Control Center database status (refer to Chapter 15, Database Status Tool) will be continually updated and will indicate exactly what the recovery process is doing. You can also browse the database's RECOVLOG kept by the product, which is a log of all database console messages updated during the recovery process. During the database recovery portion of a user-archived database, there is no reflection of the activity going on, since this is being done outside of the product. When log recovery starts, the status activity described above resumes.
A copy of this log is sent to all the database's administrators for review.
Figure 110 provides an example of the RECOVLOG file for a database recovery.
Figure 110. Example Database RECOVLOG File
02:44:31 SQLDBA Recovery Starting!
02:44:32 ARI0025I Database SQLDBA is STARTING
02:45:30 ....... START SQLSTART EXEC: 02:45:28 EST
02:45:30 ARI0663I FILEDEFS IN EFFECT ARE:
02:45:31 Z disk DMSNAM LOADLIB *
02:45:31 ARIARCH TAP1 SL 00001 VOLID VM3101
02:45:31 ARILARC TAP3 SL 00001
02:45:31 ARITRAC disk TRACE DATA A1
02:45:31 ARISQLLD disk ARISQLLD LOADLIB Q1
02:45:32 Bdisk disk 200
02:45:32 LOGDSK1 disk 201
02:45:32 LOGDSK2 disk 2F1
02:45:32 DDSK1 disk 202
02:45:33 DDSK2 disk 203
02:45:33 DDSK3 disk 204
02:45:45 ARIUSRDD disk USERLIB LOADLIB *
02:45:46 ARI0025I THE PROGRAM ARISQLDS IS LOADED AT 88D000
02:45:46 ARI0025I THE PROGRAM ARIXRDS IS LOADED AT 7B7000
02:45:47 ARI0025I THE PROGRAM ARIXSXR IS LOADED AT 982000
02:45:47 ARI0025I THE PROGRAM ARICMOD IS LOADED AT 980000
02:45:47 ARI0015I ACCOUNT PARAMETER VALUE IS D
02:45:48 ARI0015I DUMPTYPE PARAMETER VALUE IS P
02:45:48 ARI0015I LOGMODE PARAMETER VALUE IS L
02:45:48 ARI0015I STARTUP PARAMETER VALUE IS R
02:45:49 ARI0015I SYSMODE PARAMETER VALUE IS M
02:45:49 ARI0015I EXTEND PARAMETER VALUE IS N
02:45:50 ARI0015I CHARNAME PARAMETER VALUE IS ENGLISH
02:45:50 ARI0015I DBNAME PARAMETER VALUE IS SQLDBA
02:45:50 ARI0015I PARMID PARAMETER VALUE IS SQLDBA
02:45:51 ARI0015I TRACDBSS PARAMETER VALUE IS 00000000000
02:45:51 ARI0015I TRACRDS PARAMETER VALUE IS 000000
02:45:52 ARI0016I ARCHPCT PARAMETER VALUE IS 80
02:45:52 ARI0016I CHKINTVL PARAMETER VALUE IS 30
02:45:53 ARI0016I NCSCANS PARAMETER VALUE IS 30
02:45:53 ARI0016I NCUSERS PARAMETER VALUE IS 15
02:45:53 ARI0016I NDIRBUF PARAMETER VALUE IS 125
02:45:54 ARI0016I NLRBS PARAMETER VALUE IS 11290
02:45:54 ARI0016I NLRBU PARAMETER VALUE IS 1500
02:45:55 ARI0016I NPAGBUF PARAMETER VALUE IS 200
02:45:55 ARI0016I SLOGCUSH PARAMETER VALUE IS 90
02:45:56 ARI0016I SOSLEVEL PARAMETER VALUE IS 10
02:45:56 ARI0016I DISPBIAS PARAMETER VALUE IS 7
02:45:56 ARI0204D RESTORE FROM ARCHIVE INVOKED
02:45:57 RESTORE
02:45:57 ARI0204D ... CURRENT DATA BASE WILL BE DESTROYED
02:45:57 ARI0204D REPLY RESTORE TO CONTINUE, OR CANCEL TO CANCEL
02:45:58 ARI0295A READY ARCHIVE INPUT VOLUME. REPLY CUU OR CANCEL
02:45:58 Tape mount issued for: VM3101 181
02:48:07 tape 5323 ATTACHED TO SQLDBA 0181
02:48:09 0181
02:48:12 ARI0289I RESTORING DIRECTORY disk
03:07:57 ARI0290I RESTORING DATA disk
03:21:09 DMSTLM427I TAP1(181) EOV1 label read
03:21:10 tape 0181 DETACHED
03:22:19 tape 5323 ATTACHED TO SQLDBA 0181
06:31:38 ARI0291I SYSTEM RESTORE FROM DIRECTORY disk AND DATA disk
06:31:39 SQLDBA DIRECTORY & DATA Disks RECOVERED!
06:31:40 ARI0291I OF DATA BASE ARCHIVE COMPLETED
06:31:58 ARI0255I THE DATABASE MANAGER IS INITIATING A LOG ARCHIVE.
WHEN IT COMPLETES,
06:31:58 ARI0255I THE RESTORE PROCESS WILL CONTINUE.
06:32:01 ARI0293I ARCHIVE STARTING
06:32:02 SQLDBA Log Archive started.
06:32:03 ARI0239I EXTERNAL LABELING OF THIS ARCHIVE IS:
06:32:03 ARI0239I TYPE: LOG ARCHIVE
06:32:04 ARI0239I TIMESTAMP: 02-16-97 06:31:58
06:32:05 ARI0299A READY ARCHIVE OUTPUT VOLUME. REPLY CUU
06:33:19 tape 1320 ATTACHED TO SQLDBA 0183
06:33:29 ARI0292I ARCHIVE COMPLETED
06:33:31 LOG ARCHIVE completed, series 300 volid VM3201
06:33:32 ARI0260I THE RESTORE SET FOR THIS DATA BASE ARCHIVE FOLLOWS:
06:33:32 ARI0238I DATA BASE ARCHIVE 21:50:57
06:33:32 ARI0261I LOG ARCHIVE 15:30:08
06:33:32 ARI0261I LOG ARCHIVE 19:33:39
06:33:33 ARI0239I EXTERNAL LABELING OF THIS ARCHIVE IS:
06:33:33 ARI0239I TYPE: LOG ARCHIVE
06:33:33 ARI0239I TIMESTAMP: 02-10-97 15:30:08
06:33:34 ARI0250D THE ABOVE INFORMATION DESCRIBES THE NEXT LOG ARCHIVE
06:34:01 ARI0250D TO BE USED IN THE RESTORE PROCESS.
06:34:01 ARI0250D REPLY 'CONTINUE' TO RESTORE THIS LOG ARCHIVE, OR
06:34:01 ARI0250D 'STOP SYSTEM' TO INTERRUPT THIS RESTORE PROCESS, OR
06:34:02 ARI0250D 'END RESTORE' TO END THIS RESTORE PROCESS.
06:34:00 CONTINUE
06:34:02 tape 0183 DETACHED
06:34:03 ARI0295A READY ARCHIVE INPUT VOLUME. REPLY CUU OR CANCEL
06:35:05 tape 1321 ATTACHED TO SQLDBA 0183
06:35:07 0183
06:35:10 ARI0240I RESTORING LOG disk
06:41:19 ARI0283I LOG ANALYSIS COMPLETE
06:41:19 ARI0282I LUW UNDO COMPLETE
07:12:04 ARI0281I LUW REDO COMPLETE
07:12:08 ARI0239I EXTERNAL LABELING OF THIS ARCHIVE IS:
07:12:08 ARI0239I TYPE: LOG ARCHIVE
07:12:08 ARI0239I TIMESTAMP: 02-11-97 19:33:39
07:12:08 ARI0250D THE ABOVE INFORMATION DESCRIBES THE NEXT LOG ARCHIVE
07:12:13 ARI0250D TO BE USED IN THE RESTORE PROCESS.
07:12:13 ARI0250D REPLY 'CONTINUE' TO RESTORE THIS LOG ARCHIVE, OR
07:12:14 ARI0250D 'STOP SYSTEM' TO INTERRUPT THIS RESTORE PROCESS, OR
07:12:14 ARI0250D 'END RESTORE' TO END THIS RESTORE PROCESS.
07:12:13 END RESTORE
07:12:21 ARI0060I DATABASE MANAGER INITIALIZATION COMPLETE.
07:12:22 ARI0045I READY FOR OPERATOR COMMUNICATIONS
07:12:23 tape 0183 DETACHED
07:12:24 ARI028I The database manager is terminating
07:12:24 ARI0065I Operator Command processing is complete
07:12:26 ARI0032I THE DATABASE MANAGER HAS TERMINATED.
07:12:26 ARI0043I DATABASE MANAGER RETURN CODE IS '0'.
07:12:26 SQLDBA RECOVERY SUCCESSFUL! Database is being brought back up.
07:12:28 SQMA043I=> Database being started with logmode = L
The View Tapes options displays the database TAPES file for the specified database. Refer to Chapter 11, Tape Management Tool.
The Tape Maintenance option provides you with a method of updating the database TAPES file. Refer to Chapter 11, Tape Management Tool.
The following section covers some additional recovery topics and how the product can be used to help facilitate these processes.
If you decide to run your recovery manually, then consider manually updating the ARCHHIST file for the database, indicating in order of recovery each of the archive recovery events. The history records should look just like any other full database archive records, followed by any log archives that were restored. By doing this you will keep the product synchronized with the database's history information.
If you reconfigure your database log minidisks, you should update the database's ARCHHIST file manually to indicate that a COLDLOG has been performed. This will indicate that log continuity has been broken and will help the product in accurately determining database restore set information. Simply go to the bottom of the database's archive history file and add one line containing the string COLDLOG. This will indicate to the product that log continuity has been broken.
Filtered log processing can be run under product control, but requires some up-front setup work before the database recovery or restart can be invoked. This feature was not automated because filtered log processing is not encouraged.
| Usage Consideration: | If you want to specify filtering during a database recovery and you want to specify a different EXTEND input file before each log archive restore, then you must run the recovery manually. Specifying different EXTEND input files requires that you stop the database before recovering the log tape and perform a CMS FILEDEF to identify a new EXTEND input file. You would then restart the database with a STARTUP=W to resume the recovery. |
The following is a list of steps to be followed when filtering during a database restart:
The following is a list of steps to be followed when filtering during a database recovery: