University Information Technology Services Database Administration Team

DB2 Standards - Operations, Procedures, and Recovery

Introduction and Overview Operations Procedures
• • • •

Start DB2 Stop DB2 Cancel DB2 Terminate DB2 Utilities

Backup and Recovery Procedures A. System Procedures
• • • • • • •

Copy Catalog and Directory Copy BSDS (Boot Strap Dataset) and Logs Remove Entries from SYSCOPY / SYSLGRNG Create a System Point of Consistency (POC) Restore to a System Point of Consistency (POC) Recover DB2 Catalog and Directory Catalog / Directory out of Space

B. User Data Procedures
• •

Create User Data Point of Consistency (POC) Restore User Data to Point of Consistency (POC)

Disaster Procedures

A. Introduction and Overview 1. Introduction This part of Database Administration Standards and Procedures deals with the operation of DB2, and the recovery procedures necessary to restore both system and user data. The

first part of this section, Introduction and Overview, describes how the Operations and Recovery Standards chapter is organized. The second part of this section, Overview of DB2 Operations and Recovery, gives a brief introduction to the subject of operations and recovery in the DB2 environment. Sections B through D document the various procedures -- Operations/Restart, Backup/Recovery, and Disaster -- necessary to effectively run DB2. For each procedure documented, you will find step-by-step instructions, and some procedures include a flowchart. Sample JCL for DB2 utilities can be found in the PDS DBT1.DB2.UTILLIB. All of the Operations and Restart procedures in section B are labeled "Onn", where nn stands for two digits; in section C system recovery procedures are labeled "Snn", user data recovery procedures, "Unn". Where appropriate, each procedure will contain STANDARD, GUIDELINE, and INFORMATION sections to inform the reader of what is required, what is good practice, and what is useful to know. A list of the procedures documented in each section can be found in the introduction to that section. Complete information on DB2 operations and recovery can be found in IBM Database 2 Version 2 Administration Guide, Section 6 Operations and Recovery (SC26-4374). 2. Overview of DB2 Operations and Recovery DB2, like most online systems, uses logging (applying all changes in data to a log dataset) to facilitate recovery of data. The basic steps in the recovery method for online systems are:
• • • •

Make backup copies of user datasets. Restore the dataset using the backup copy. Read the log dataset and apply all changes made to the user dataset since the backup copy was taken. This is known as forward recovery. Backward recovery is the technique by which changes made to data are removed. The log stores not only changes to the data, but also an image of the data before it was changed. Thus, backward recovery applies "undo" images to data.

Within DB2 specifically, recovery is implemented through the following system resources:
• • • • •

DB2 log datasets DB2 bootstrap data set (BSDS) DB2 Utilities Backup copies of user data Backup copies of system resources

-- DB2 libraries -- DB2 Catalog and Directory

if a value of 3 is changed to 5.First we will present an overview of DB2 recovery. Undo and Redo Records When a change is made to a database. the undo/redo record is used to remove the change. If changes to the database must be rolled back. Redo information is required if work is committed and later must be recovered. The programmer controls this recovery through the use of SQL . If work must be recovered. DB2 scans the log forward and applies the redo/undo log records. Rolling back work If failure occurs within a unit of recovery. DB2 Recovery Units of Recovery A unit of recovery is the work. Once both steps are complete. Undo information is used to back out work that has not been committed. At the same time. and then discuss the system components DB2 utilizes in the recovery process. For example. Normal termination of a program. DB2 logs an undo/redo record that describes the change. the SQL COMMIT statement. DB2 removes any changes to data. in which case the DB2 log completely recovers the data back to a point of consistency. the two accounts are inconsistent not until the amount subtracted from account A is added to account B are they consistent again. The work is undone. the program has created a point of consistency. a bank transaction might transfer funds from account A to account B. After the subtraction. called compensation information. returning the data to its state at the start of the unit of recovery. that affects the state of DB2 data from one point of consistency to another. and CICS program requests all cause a point of consistency to be established. redo compensation information changes that value back to 3. The SQL statement ROLLBACK will also cause this same sequence of events (the "undo" sequence) to occur. A point of consistency. done by DB2 for an application. redo records restore the data. Database Recovery The above processes describe recovery initiated by incorrect results of either interactive or programmatic SQL. without keeping track of whether the unit of recovery was committed or rolled back. (also knows as sync point or commit point) is a point in time when all recoverable data an application program accesses is consistent with other data accessed by that same program. If the work is to be rolled back. that reverses the change. a new "redo/undo" record is created that contains information. For example. The program first subtracts an amount from account A and adds that amount to account B. and the redo portions of compensation records.

e. When an active log is filled. or table. if necessary. During this archival procedure DB2 creates an entry in the Bootstrap Dataset (BSDS) that describes the archive log dataset. for a moment. In the first instance. should give the reader a basic understanding of how DB2 implements recovery. finally. apply the log to update the restored table with changes made after the backup was created. DB2 initiates an archival process (called "offloading") which copies the active log to an archive log. that a SQL COMMIT statement successfully ended a unit of recovery. a time when the data in the table was correct. The point to remember is that if an entire database. must be recovered. inserted bad data into a table.COMMIT and ROLLBACK statements. II (SC26-4374). The DB2 Catalog table SYSCOPY contains records that describe image copy (i. Flow of Recovery in DB2 Changes made to DB2 tables (system and application) are recorded in the active log datasets. DB2 must have a backup copy of each table space that is to be restored. We will now discuss these components of the recovery process in greater detail. and data in the table is lost. This flow runs as follows: DB2 first reads the Catalog table SYSCOPY to find the most recent image copy for a table space. and. it applies changes recorded by the log to the table space being recovered. or to the current time (i.e. In either of these instances. the table would be restored to a previous point of consistency. though simplified.. and updates captured by the log would not be applied to the table. Or assume that the disk pack which physically contains a DB2 table incurs an I/O error. functioning incorrectly. using both the backup and the log. backup copy) datasets for each table space (image copies are created by the DB2 COPY utility). After this COMMIT has been issued it is discovered that an application program. initiating the recovery process. the only recourse is to restore the table from a backup copy. But assume. In the second instance the table would be restored to the current time. The DB2 Directory table SYSLGRNG contains records that tell what log records apply to each table space for each table space. DB2 tables and databases are restored by running the RECOVER utility against a table space. and uses that copy dataset as the base from which to begin the recovery. reading first the BSDS to determine which log datasets (both active and archive) contain applicable units of recovery.. next reading the Directory table SYSLGRNG. Vol. Thus. a database can be restored to a previous point in time (restore to a backup copy). DB2 Log Datasets . the last log RBA for that database). including its dataset name and the range of log records it contains. This overview. the starting and ending RBA of a log record is recorded.e.. DB2 determines which units of recovery apply to a particular table space. Those wishing more detailed knowledge of this process may wish to consult IBM Database 2 Version 2 Administration Guide. writing the updated data back to the database. i.

A record"s log RBA uniquely identifies its position within the log. Changes made to DB2 data (both system and user) are captured by "Unit of Recovery" log records. and thus accessible. and allows for retrieval of individual log records. DB2 is capable of employing dual-logging. when first created. How logging is implemented Log records."Unit of Recovery". its dataset name is placed in the BSDS. DB2 Utilities DB2 utilities are standard MVS batch jobs that perform functions on DB2 objects. both system and application. Active log datasets are written (offloaded) to an archive log. and are used to recover data. by its log RBA. for a discussion of this topic. See Section VII. . a record describing the new archive log is added to the BSDS. The names of all current active log datasets are placed in the BSDS when DB2 is first installed. as well as complete information on DB2 recovery. Each byte in the log is addressable by its offset from the beginning of the log this is known as the log RBA. Each of these resources is briefly described. Backup Copies of System Resources To be able to recover the DB2 subsystem. When an archive log is dynamically allocated during the offload process. During recovery DB2 uses both the active and archive logs to restore a table space. and a copy of the BSDS is placed on the same volume as the archive log (this provides a backup should the active BSDS be destroyed). DB2 Libraries: The DB2 execution and installation libraries are backed up in the event they need to be restored. DB2 Utilities. are formatted and placed into log buffers. or when an SQL COMMIT is issued. DB2 Bootstrap Dataset (BSDS) The BSDS is a VSAM KSDS that contains information about all of the DB2 log datasets and the records they include. there must be backup copies of the system resources used by DB2. log records in the log buffer are written to the active log. and "Database Page Set" -. and to recover from incorrect results of program execution. DB2 writes three kinds of records to the log -. Vol.and each record on the log is identifiable. II (SC26-4374).The DB2 log contains the information necessary to recover the DB2 subsystem and user databases. when an active log becomes full. a sequential dataset. The other two types of log records. are documented in IBM Database 2 Version 2 Administration Guide. which means two copies of each active log are always being written. "Checkpoint". which is a VSAM LDS. When these buffers become full. Every time an active log is offloaded to an archive log.

This information is then used by DB2 for recovering that table space. DB2 inserts. have been given CA-OPERA aliases (e. Some of the commands given in this section require the subsystem recognition character when working at the MVS console.DB2 Catalog and Directory: Two of the most important components of DB2 are the Catalog and Directory. updates. This makes it less likely that the production and test subsystems will be confused.Start DB2 O02 . This section gives the CA-OPERA alias for a DB2 command whenever they can be substituted. and .Stop DB2 O03 . a row describing the image copy dataset is inserted into the Catalog table SYSCOPY. such as START and STOP. rather than "-STOP DB2"). It speeds up recovery by limiting the log information that must be scanned to apply changes to a table space being recovered. The Catalog contains tables that describe every object defined to the DB2. when the COPY utility is run to back up a table space. The table SYSLGRNG. and if so.g. Some of the basic DB2 commands. The type of data in each table will determine how often the table space should be backed up.Cancel DB2 O04 . I (SC26-4374). These procedures will be performed by staff of Technical Services and Operations. Backup Copies of User Data As stated above. how often? How critical is the data to the mission of the organization? If the data is for inquiry only. user table spaces must be backed up on a regular basis using the COPY utility.. image copies are made of table spaces.Terminate DB2 Utilities . For more information on DB2 system resources. The Directory contains four tables that are used to start and run DB2.. please consult IBM Database 2 Version 2 Administration Guide. For example. Operations Procedures The procedures in this section document how to run DB2. contains open/close log RBAs for each table space. or deletes rows from tables within the Catalog that both describe an object and tell how it is related to other objects. Vol. the command to stop the production DB2 subsystem can be entered as "P DB2PROD".g. • • • • O01 . start DB2. cancel DB2.for production. is the data updated?. not tables. stop DB2. For example. VSAM or sequential file)? Do quiesce points need to be taken between creation of image copies? These questions need to be addressed before any user table is put into production. The Catalog and Directory should be considered as one unit for purposes of backup and recovery. In order to implement a successful recovery strategy for user data. Whenever you CREATE. ALTER. can the table be simply loaded again from the original source of the data (e. There is a different subsystem recognition for the test and production systems: + for test. or DROP any object. for example. B. but when issuing commands against the test DB2 system use the plus sign (+) as the DB2 subsystem character. and so on. These procedures use the production system as an example.

The default for stopping DB2 is MODE(QUIESCE). At the Master Console type P DB2PROD (for test. DB2 should be left up between IPLs.Procedure O01 -. Procedure O01 1. Tape mounts will be requested intermittently for logging purposes.Start DB2 STANDARD This procedure will be executed only by staff of Operations and Technical Services.Stop DB2 STANDARD This procedure will be executed only by staff of Operations and Technical Services. If you do not receive this message. INFORMATION This command must be entered from the MVS console. and DBP1IRLM). This command can be entered only from an MVS console with the START command capability. Check for message DSN9022I. which means that all currently active programs are allowed to complete. INFORMATION The DB2 system consists of three started tasks: DBT1MSTR. which signals that DB2 has started successfully. Procedure O02 1. then 3. At the Master Console type: S DB2PROD (for test. DBP1DBM1. Notify Technical Services Procedure O02 -. DBT1DBM1. type S DB2TEST) The response to the start DB2 command will be the message DSNY001I SUBSYSTEM STARTING 2. type P DB2TEST) . these started tasks are DBP1MSTR. and DBT1IRLM (for production.

If you reply "Y" to DSNJ008E. and you should use Procedure O03 . P DB2PROD). But you may want to reply "Y" to DSNJ008E if you previously received the following message DSNJ110E LAST COPYn ACTIVE LOG DATA SET IS nn PERCENT FULL which tells you that the last active log dataset is seventy-five percent or more full. Message DSN9022I tells you that the DB2 stop command was successful. If message DSN9022I is not displayed. If message DSNJ008E is outstanding.g. INFORMATION Canceling DB2 will probably cause in-doubt situations. check for outstanding requests on the MVS console. DB2 will wait for offload completion before terminating. DB2 cannot terminate until it has been answered. If DB2 does not terminate after a "STOP DB2" command (e. and the installation parameter DSNZPARM specifies WTOR=YES. Reply "N" to DSNJ008E to allow DB2 termination. If you arrive here. Message DSN3100I tells you that DB2 has been successfully stopped and is ready for the next start command.The response to the stop command is the message DSNY002I SUBSYSTEM STOPPING 2. 3. 5. 4.. Use the commands -DISPLAY THREAD(*) -DISPLAY UTILITY(*) . 6.Cancel DB2. It was issued because at least one active log data set was ready for archiving. Procedure O03 1. Procedure O03 -. it may be because there are still threads active.Cancel DB2 STANDARD This procedure will be executed only by staff of Operations and Technical Services. DB2 could not quiesce normally.

INFORMATION The DB2 "-TERM UTILITY" command terminates execution of a utility job step and releases all resources associated with that step. if you have been unable to cancel DB2. type: . cancel DB2). DB2 should respond with the message: DSNY002I SUBSYSTEM STOPPING Active DB2I users receive the following message: THE DB2 OPERATOR IS STOPPING THE SUBSYSTEM.e. and Technical Services.SUBSYSTEM ssnm READY FOR -START COMMAND 2. from the DSN command processor. Procedure O04 To see which DB2 utilities are currently executing. you will receive the following message: DSN3100I DSN3EC00 . enter this command: -STOP DB2 MODE (FORCE) from the MVS console or DB2 commands panel. or from a CICS terminal. (Note: Technical Services can authorize the operator to stop the IRLMPROC. This command can be entered from an MVS console. Operations.Terminate Utilities STANDARD This procedure will be executed only by staff of DBA. which allows all active programs to complete before DB2 stops.from the MVS console or from the DB2 commands panel (#7 in DB2I) to determine whether there are still active threads. Once DB2 has been successfully canceled. Remember that the default when stopping DB2 is "MODE(QUIESCE)". If you do not receive message DSN3100I. 3. This decision will be left up to Technical Services. that is.) Procedure O04 -. contact Technical Services. the DB2I commands panel. PLEASE END YOUR DSN SESSION. To stop DB2 immediately (i.. Check for message DSN3100I. which will immediately bring DB2 down.

Backup and Recovery Procedures The procedures in this section document those procedures necessary to insure the integrity of DB2.-DISPLAY UTILITY(*) For each utility that is stopped or running. User data procedures will be regular production jobstreams.Copy Catalog and Directory S02 . The procedures will be carried out by staff of DBA. Technical Services. Example: -TERM UTILITY (DB2050TS) Example: -TERM UTILITY (DB2050*) (*) denotes all utility job steps. A description of these jobstreams. DB2 Utilities. Example: -TERM UTILITY (*) C.Restore to a System Point of Consistency (POC) . The backup and recovery procedures documented in this section are divided between system data and user data. Note. however. or UID parameter. and will follow DBA naming standards. UTILID = CG2040CG PROCESSING UTILITY STATEMENT 2 UTILITY = RUNSTATS PHASE = RUNSTATS COUNT = 0 STATUS = ACTIVE Notice the UTILID specification. 1. System data procedures will be designed and implemented by DBA and Technical Services. For example. enter the following command: -TERM UTILITY(utility-id) Where (utility-id) is the utility identifier.Copy BSDS and Logs S03 . that user data recovery procedures will be designed by both DBA and developers. used when creating the utility job step. as well as their respective naming standards. System Data Procedures • • • • • S01 .Remove Entries from SYSCOPY/SYSLGRNG S04 .Create a System Point of Consistency (POC) S05 . information will be displayed. are given in Section VII. To terminate a particular utility. This parameter will terminate every utility job step known to DB2. and Production Services.

but production jobstreams end with the suffix 'DB'.Print Log Map/BSDS (utility DSNJU004) DB2530DB -. For both test and production the jobstreams begin with 'DB'.Remove Old Entries from SYSCOPY/SYSLGRNG DB2535DB -.DSNDB06.Change Log Inventory (DSNJU003) DB2570DB -.dddddddd.Back up BSDS and Logs (runs weekly) DB2525DB -. For example.Recover DB2 Catalog and Directory S07 .tttttttt .STOSPACE Utility DB2555DB -.Back up Catalog/Directory (runs nightly) DB2520DB -. whereas test jobstreams end with suffix 'DT'. • • • • • • • • • • • • • • DB2510DB -.G0205V00 • • The naming standard for this production jobstream will be DB2510DB The Catalog and Directory will be backed up nightly. or are submitted by a person with appropriate authority -.SYSCOPY.Initialize SYSUTIL Procedure S01 .a staff member of DBA or Technical Services.Delete and Define Catalog/Directory Datasets DB2595DB -.OFS .Delete and Define BSDS and Logs Datasets DB2590DB -. DBT1 for Prod.Catalog/Directory Out of Space The above procedures utilize the jobstreams described below.Recover BSDS and Logs to POC DB2580DB -.Recover Catalog/Directory DB2545DB -.GxxxxVxx.• • S06 . DBP1) dddddddd = eight-character database name tttttttt = eight-character table space name Annn (optional) = partition number if copy is by partition OFS (optional) = designates copy stored offsite GxxxxVxx = generation dataset group number Example DBP1. where yyyyyyy = high-level qualifier (for Test.Copy Catalog and Directory STANDARD • The naming standard for system image copy datasets will be as follows: yyyyyyy. the jobstream to back up the DB2 Catalog and Directory is DB2510DB for production. .Annn .Recover Catalog/Directory to a POC DB2550DB -. These jobstreams are for DB2 system datasets only. and DB2510DT for test.List DB2 ICF Alias DB2540DB -. and as such are run under CA-7.Recover BSDS and Logs DB2575DB -.

and resubmit the job. determine the cause of the problem. 5. If the return code from step 4 of this procedure is not "00". Check to make sure the return code from this job step is "00". Determine the cause of the problem. new data sets will have to be defined for them. Procedure S02 1. Execute jobstream to back up Catalog and Directory 2. determine the cause of the problem. determine whether there are any stopped or truncated active logs.Copy BSDS and Logs STANDARD • • This procedure must be run while DB2 is down. If there are stopped or truncated active logs. Copy the bootstrap datasets using IDCAMS REPRO.Removing Entries From SYSCOPY/SYSLGRNG GUIDELINE . and the Directory. If the return code from step 4 of this procedure is not "00".GUIDELINE • The Catalog and Directory should be copied at the same time to insure consistency between them. Was return code "00"? If not 3. The naming standard for this production jobstream will be DB2520DB INFORMATION • The BSDS. 2. and resubmit the job. Run the DSNJU004 utility to print the contents of the BSDS. Procedure S02 -. 6. together with active logs. resolve the problem. 4. resolve the problem. which can be done using the utility DSNJU003 (Change Log Inventory). 7. Procedure S01 1. 3. The new active log datasets you define will also have to be recorded in the BSDS. Copy all active log datasets using IDCAMS EXPORT. the Catalog. Procedure S03 -. and resubmit the job. From looking at the report produced in step 1. This backup jobstream should be run at a point of very low system activity. resolve the problem. Make sure the return code from this job step is "00". are the most important sources of information DB2 needs to operate.

If datasets are going to be removed by POC. 3.. Recovery information should be kept for as many levels (i. Point of consistency backups for user data. Use IDCAMS or TSO to physically delete and uncatalog the datasets. information about archive log datasets no longer used can be removed from the BSDS. If the dates are not known. Note that defining a retention period for a dataset on tape will automatically cause the dataset to be deleted at the end of the retention period. Datasets that have been removed from the appropriate DB2 table should be physically deleted. 3. 2. 2. and when to remove them. then simply use the date on which the POC was created. . Volume dumps of all DB2 volumes for disaster recovery. Point of consistency backups for the entire DB2 subsystem. and thus does not know if a particular backup tape has been scratched. Execute the MODIFY utility to delete entries from SYSCOPY and SYSLGRNG.e. Procedure S03 1. Based on these recommendations. There should also be copies of the BSDS and active logs for that date. If the datasets for the image copies recorded in SYSCOPY are to be deleted. or other external management systems. is governed by the recovery strategy. Therefore. Recommended backup intervals are: • • • Daily. or monthly (depending on the application) for user table spaces and points of consistency. 4. Four types of backups should be kept: 1. INFORMATION DB2 does not interact with TMS.e. weekly.. Weekly for DB2 subsystem point of consistency backups. generations) of data as are required by the recovery strategy. 4. Remember that MODIFY only deletes records older than the date you specify. and vice-versa. Weekly for volume dumps. Determine the date(s) for which entries from SYSCOPY and SYSLGRNG should be removed.The decision on what entries to remove from SYSCOPY and SYSLGRNG. dates when point of consistency backups were taken (for both system and user data) can be determined. At the same time that this is done. or a disk dataset deleted. Image copies of table spaces for recovery to the current point in time. their dataset names can be obtained from SYSCOPY. the system tables SYSCOPY and SYSLGRNG) in sync with whatever external storage management system is used for backing up datasets. the Catalog table SYSCOPY can be queried to obtain them. and outdated entries containing information on these backups can be removed from SYSCOPY and SYSLGRNG. it is important to keep DB2 (i.

. Note that DB2 must be down to run this utility. In carrying out this procedure. SYSADM authority is required to execute this procedure. TMS). not date. 7. If there is a recovery to a POC. Procedure S04 -. Before removing information from the BSDS. Restrict access to the DB2 subsystem to those USERIDs defined as SYSADM or SYSOPR by entering the following command : .Create a System Point of Consistency (POC) STANDARD • • A system POC should be created once a week. INFORMATION • • • • • By creating a point of consistency (POC) for the DB2 subsystem. 6. System POC creation dates will be maintained for the purpose of recovering to a POC. delete the bootstrap dataset and active log dataset backups created when you executed that procedure. This procedure may not be carried out while DB2 is running. jobstream DB2555DB. It is up to the installation to synchronize these resources with DB2. any changes made to data after the POC was created will be lost. 8. When the BSDS fills up. there are several points to remember: There is no consistency with resources outside DB2 (e. Run utility DSNJU003 (Change Log Inventory).) Avoid removing information from the BSDS that might still be needed for a recovery. Use procedure O02 to stop DB2. 2. and by backing up the BSDS and active logs. Remember that entries in the BSDS are added in wrap-around mode. These names were obtained in step 9. run utility DSNUJ004 and examine its output to obtain the dataset names of those archive log datasets that are older than the date chosen in step 1 (The date from the BSDS will be in YY. A POC is established by taking image copies of all table spaces (both system and user data).g. If you are discarding a POC created by procedure S04. Decide whether to remove information from the BSDS. the oldest entry is used for the next record. you are able to recover the entire system to a point in time where all the data (both system and user) is consistent.5. Physically delete and uncatalog the archive log datasets whose names were removed from the BSDS. DSNJU003 requires that you specify a dataset name.DDD format. to remove the names of archive log datasets from the BSDS. Procedure S04 1.

type F DB2TEST) 3. Use procedure 'S02' to copy the BSDS and active logs. 7. and later. enter -DISPLAY THREAD(*) The message DSNV402I . 6. Step 7 cannot be executed until DB2 has been stopped. enter the following command at the MVS Console or at panel 7 ("Commands") of DB2I -DISPLAY DATABASE(*) SPACENAM(*) LIMIT(*) RESTRICT You should receive this message for all table spaces DSNT365I . it may be more efficient to take an incremental image copy. enter -DISPLAY UTILITY(*) You should receive this message DSNU112I .ACTIVE THREAD should list only your thread 4. 5. after this entire procedure has been completed.NO AUTHORIZED UTILITY FOUND FOR UTILITY = * To find any active threads. Create image copies for all user table spaces. Make sure the system is in a consistent state before creating the POC. run MERGECOPY to combine the copies. For large tables. Check the status of: • • • Databases and table spaces Utilities Threads To check the status of databases and table spaces.F DB2PROD (for test. Use procedure 'S01' to create full image copies for all system table spaces (Catalog and Directory). . Use procedure 'O02' to stop DB2.******** NO DATABASES FOUND To determine whether there are utilities in the system.

Create a System Point of Consistency'. Edit this jobtream to put in the appropriate backup dataset names from which recovery will take place. Use procedure 'S01' to start DB2. Using procedure 'U04' as an example. Catalog. There will be no inconsistencies left in DB2 (Directory. remember that you will be restoring not to the current point in time. DB2 is now available. This will avoid inconsistencies should DB2 be restored to the POC. 12.8. These steps include: • • • Deleting copies of the BSDS. Therefore. Jobstream DB2545DB has been set up to recover the Catalog/Directory to a POC. Delete information for an older POC. Procedure S05 -. Points to remember when executing this procedure are: • • • Data that was created or modified after the date the POC was created will be lost. step 7 to determine which table and index spaces were created after this POC. instead of when the system must be recovered quickly. and user table spaces. Directory. INFORMATION Recovering to a system point of consistency (POC) brings the DB2 subsystem back to consistent point for all DB2.) 11. This point in time is created by procedure 'S04 . prepare a RECOVER utility job for all user table spaces and indexes. 9. . it is best to prepare these recover jobs now when you have the time to do so. when you use procedure 'S05' to restore the DB2 system to a POC. and user data) after this procedure has been executed. (Note: this may be accomplished by the standard volume backups executed by Production Services. Note: though step 9 could be considered optional. Deleting copies of the active logs. 10. you will be restoring to the backup copies created in steps 4 and 5 of this procedure. Execute jobstream DB2535DB to get a listing of the ICF catalog.Restore to a System Point of Consistency STANDARD • The DBA will determine whether it is necessary to run this procedure. Deleting copies of table spaces if they are not required for recovery procedures other than POC. This listing will be used in procedure 'S05'. In preparing the recover job for the Catalog. Make copies of DB2 libraries. All DDL (Data Definition Language) executed after the creation of the POC will have to be rerun. but rather to a POC. All BINDs run after the creation of the POC will have to be rerun.

Restore the BSDS from the backup created in procedure "S04". and will be used in step 9 of this procedure to delete these archive log datasets. This listing will also tell you if there have been changes in the active log since the POC. and thus should be reversed. If DB2 is running. restore it from the latest archive log. . step 7. step 7. Check the return code on the REPRO step to make sure it is "00". 2.Bxxxxxxx 8. and by restoring all system and user table spaces. and one for the BSDS. If the BSDS was defined with the IDCAMS parameter REUSE. 7.Axxxxxxx xxxx. the BSDS will have to be deleted and defined using IDCAMS. Compare this listing with the one created in procedure "S04". step 7. If the BSDS is not available. Such changes would have been recorded in the current BSDS. the backup can be copied directly into the BSDS. This will give you information about archive log datasets created after the POC you are restoring to. Check the return code on this job step to make sure it is "00". SYSADM authority is required to perform this procedure. Image copies and archive log datasets written to DASD will also show up on the listing Remember that the off-loading process creates two datasets. Procedure S05 1. use procedure "O02" to shut down DB2.• • A recovery to a prior POC is performed by restoring backup copies of the BSDS and active logs. 4. Using IDCAMS DELETE. For example. The naming convention for these datasets is: xxxx.ARCHLOG1. If not. using jobstream DB2575DB. one for the archive log. 6. the active log datasets could have been extended since the POC was taken. Print the BSDS using DB2 utility DSNJU004. Use jobstream DB2575DB to restore the active logs using the backups created in procedure "S04". step 8. but not in the one that will be restored. Run jobstream DB2535DB to obtain a listing of the ICF catalog. Determine whether DB2 is running.ARCHLOG1. and compare the listing with the one created in procedure "S04". 5. 3. to determine the names of all table and index spaces created after the POC you are restoring to. delete all table and index spaces created after the POC.

Recover all user table spaces and indexes. If step 4 revealed archive log datasets created after the POC. The first choice for recovery should be to the current time. There won't be time to prepare it when it is needed. The last choice would be to restore to a point in time. If step 7 revealed image copies created after the POC. there has either been damage to the Catalog or Directory. delete them using TSO.recover them both to the same point in time. step 9. Section 6 Operations and Recovery for a list of the objects in the Directory to be recovered. This step is optional and should be executed only if changes have been made to the DB2 libraries. The naming standard for this production jobstream will be DB2540DB GUIDELINE The utility job to recover the Catalog and Directory should be prepared and ready to run before it is required. the second choice would be to recover to a point of consistency (procedure S05 describes how to recover the DB2 subsystem to a POC). or DB2 is being recovered to a point of consistency. INFORMATION • • • • When recovering the Catalog and Directory. The Directory table spaces. In procedure "S04". remember that these two tables are the most important in the DB2 system. Procedure S06 -. delete them using TSO. tables.Recover DB2 Catalog and Directory STANDARD • • The DBA will determine whether it is necessary to run this procedure. step 9 this jobstream was edited to reflect the correct backup datasets to be used. for purposes of recovery. Refer to IBM Database 2 Version II Administration Guide Volume II. and indexes are not recorded in the Catalog. using procedure "U04" as an example. 10. It is assumed that if you are running this procedure. which is the most difficult and risky of the three approaches. SYSADM authority is required to execute this procedure. If that is not possible.9. consider the Catalog and Directory as one unit -. Always. 12. And always recover all Catalog and Directory table spaces and indexes. 11. The utility job to execute this restore was created in procedure "S04". Procedure S06 . Execute jobstream DB2545DB to recover the DB2 Catalog and Directory to the appropriate point in time. Restore program libraries.

If a recovery to the current time was unsuccessful. Execute jobstream DB2540DB to recover table space SYSUTIL. This is the first step in this jobstream. The order of recovery of these objects is essential. 5.1. Start DB2 in maintenance mode with the following command F DB2PROD (for test. Execute the remaining steps in jobstream DB2540DB to recover all table spaces and indexes for the Catalog and Directory. DB2 needs • • • • BSDS Active log dataset Load library (prefix. The procedure documented here ('S06 . If SYSUTIL was not successfully recovered. refer to procedure 'S05' for information on the entire POC recovery process. Recover the appropriate object using the RECOVER utility.DSNLOAD) Early code library (prefix. the remaining steps (which recover the rest of the Catalog/Directory) should not execute. Determine. If a resource (a Catalog or Directory table or index space) is unavailable. . 9. This may cause the status in SYSUTIL to not match that of the DB2 subsystem.Recover DB2 Catalog and Directory') is used by procedure S05 to recover the Catalog and Directory during a complete POC recovery. type F DB2TEST) This limits DB2 access to SYSADM and SYSOPR.DSNLINK) 3. initialize it by executing jobstream DB2595DB. Therefore. 6. Determine whether the recovery was successful by querying the Catalog with SQL statements. delete and define all DB2 Catalog and Directory clusters. If this step fails. Note that it is possible to bring DB2 up even if the Catalog and Directory have been lost. At startup. 7. 2. 8. it means you probably forgot to recover it. Steps 11 and 12 of this procedure will deal with these possible inconsistencies. execute the steps of this jobstream in sequence. Determine whether SYSUTIL was successfully recovered. use procedure 'S05' to recover to a point of consistency. If you are going to recover to a POC. through VTOC listings. whether the Catalog and Directory are available on DASD. If any Catalog or Directory table is not available. 4.

whether required because of planned maintenance or because a dataset out of space caused a DB2 failure. The proper procedure for doing this. (b) delete and redefine the appropriate dataset(s). Procedure S07 -. you may have to: • • • • rerun utilities keep datasets that were being used by utilities to be able to recover the data delete datasets that are no longer needed remove restrictions 12. (d) recover the Catalog and Directory. If SYSUTIL was initialized. (c) bring DB2 up in maintenance mode. If there were utilities active.UTUT) may be removed by entering the following command. Restrictions will be shown when the following command is issued against the table space being used by the utility -DIS DATABASE(database-name) SPACENAM(tablespace-name) LOCKS Restrictions (UTRO. as outlined in the steps below.10. GUIDELINE Use this procedure to resize a Catalog or Directory dataset. 11. This will establish normal operation mode. INFORMATION Catalog and Directory table spaces and index spaces are VSAM linear datasets. 14. and therefore are subject to VSAM space limitations. Use procedure 'O01' to start DB2. it will be necessary to reallocate space for these datasets. or in the case of emergency. check SYSLOG for message DSNR007I to determine whether there were any active utilities at the time of failure.UTRW. From time to time. is: (a) take DB2 down. This command also removes information from SYSUTIL. -START DATABASE(database-name) SPACENAM(tablespace-name) ACCESS(FORCE) 13.Catalog/Directory Out of Space STANDARD Only DBA staff will execute this procedure. and . Use procedure 'O02' to stop DB2.

determine the problem. Execute jobstream DB2540DB to recover the Catalog and Directory. If the recovery was successful.Create User Data Point of Consistency (POC) U02 . Use Procedure O01 to start DB2 in normal mode. 3. correct it. These procedures invoke DB2 utilities to LOAD. Use Procedure O02 to stop DB2. For information on these utilities. Execute jobstream DB2580DB to delete and redefine the appropriate Catalog or Directory dataset(s). see "Section VII DB2 Utilities". COPY. and rerun the recovery jobstream (DB2540DB). where: aa = two-character database prefix assigned by DBA . 8. as well as perform other tasks.Create User Data Point of Consistency (POC) STANDARD • The naming standard for a production create user POC jobstream will be aa2200tt. CHECK. 7. Use Procedure O02 to stop DB2. Procedure S07 1. Make sure the return code from this jobstream is '00'. U01 . and RECOVER data. 2. Query the Catalog to insure that the recovery executed in step 5 was successful. type F DB2TEST) 4. Restrict access to the DB2 subsystem to those USERIDs defined as SYSADM or SYSOPR by entering the following command F DB2PROD (for test. 2. Determine which Catalog or Directory dataset needs to be resized.Restore User Data to Point of Consistency (POC) Procedure U01 -. User Data Procedures The basic user data procedures are those described in the section on DB2 utilities. 6. 5. Note: the ouput from jobstream DB2510DB (Backup Catalog/Directory) contains a LISTCAT of all Catalog and Directory datasets.(e) restart DB2 in normal mode.

. enter the following commands -START DATABASE(database-name) . only tables that are updated and that belong to a table space set need have a POC created for them.) ACCESS(UT) 3 Execute the COPY jobstream that will create a full image copy of each table space in the table space set 4 If problems were encountered during the COPY jobstream.. Procedure "U02" is used to restore user data to a POC. Procedure U01 1 Enter the following DB2 Command for all table spaces in the table space set -STOP DATABASE(database-name) SPACENAM(tablespace1.. 5 Once the COPY jobstream has completed successfully. A POC jobstream should always create a full image copy. Tables that are not referentially related to other tables can have their integrity insured by a simple COPY or QUIESCE. This jobstream should follow the execution of the CHECK utility against all tables in the table space set.) 2 Then start the table spaces in the table space set for utility access -START DATABASE(database-name) SPACENAM(tablespace1.. correct it. = two-character table space identifier assigned by DBA • • A point of consistency will be established for only those tables that (a) are updated and (b) are referentially related to other tables. and resubmit the job.tablespace2. INFORMATION • Tables that are not updated cannot have inconsistencies introduced into them through standard SQL INSERT. GUIDELINE • • A data POC jobstream should be set up in production for all table space sets that permit insertions.. An alternative method to the one given below is to use the QUIESCE utility to quiesce all table spaces in a table space set.tablespace2. and deletes. Therefore. UPDATE.. and DELETE statements. determine the problem. and do not face the problem of data anomalies across tables.

Procedure U02 1 Enter the following DB2 Command for all table spaces in the table space set -STOP DATABASE(database-name) SPACENAM(tablespace1. 4 If problems were encountered during the restore jobstream.) ACCESS(RW) Procedure U02 -.) 2 Then start the table spaces in the table space set for utility access -START DATABASE(database-name) SPACENAM(tablespace1. correct it. updates. enter the following commands -START DATABASE(database-name) . determine the problem.) ACCESS(UT) 3 Execute the RECOVER jobstream that will each table space in the table space set to the most recent full image copy created by procedure U07....tablespace2.tablespace2. updates. This jobstream should be used only when it is necessary to recover a table space set to a previous point in time. INFORMATION Tables that are recovered to a POC will lose all insertions..Restore User Data to Point of Consistency (POC) STANDARD ~The naming standard for a production restore to user POC jobstream will be aa2210tt Where aa = two-character database prefix assigned by DBA tt = two-character table space identifier assigned by DBA GUIDELINE A jobstream to restore user data to a POC should be set up in production for all table space sets that permit insertions. 5 Once the restore to POC jobstream has completed successfully. Procedure 'U01' is used to create a POC for user data. An alternative method to the one given below POC is to recover all table spaces in a table space set to a RBA created by the QUIESCE utility.. and resubmit the job...SPACENAM(tablespace1.tablespace2. and deletes executed after the creation of that POC. and deletes.. Always recover the indexes for all tables in the table space set after the tables have been recovered..

edu The Trustees of Indiana University Copyright 1999 . Last revised 05/08/2003 20:57:24 http://www..SPACENAM(tablespace1.tablespace2.html Comments: Disaster Procedures STANDARD Computing Systems will be responsible for designing and implementing disaster procedures for DB2..) ACCESS(RW) D.

Sign up to vote on this title
UsefulNot useful