DB2 Restart

DB2 can be stopped normally, or it may experience an abnormal termination for a variety of reasons. In order to bring the DB2 subsystem back up, the restart process must be performed.

DB2 can be stopped normally by using operator command STOP DB2. If DB2 stops for other reasons, it is considered an abnormal termination. A STOP DB2 command has two modes: FORCE and QUIESCE. The FORCE option will roll back all active threads and not allow any new connections or work. QUIESCE will allow new threads to be allocated for an application that is currently running and will allow existing threads to complete but will not allow new connections. Following is an example of stopping DB2 with the QUIESCE mode:

 -STOP DB2 MODE (QUIESCE) 

DB2 uses its recovery log and the bootstrap data set (BSDS) to determine what to recover when restarting. The BSDS identifies the active and archive log data sets, the location of the most recent DB2 checkpoint on the log, and the high-level qualifier of the Integrated Catalog Facility catalog name. Many controls in DB2 help minimize the time necessary to restart DB2. We discuss some of those here.

• The -SET LOG SUSPEND/RESUME command can be used to temporarily freeze all DB2 activity. This command provides for a fast copy of an entire DB2 subsystem. A fast copy can be accomplished via ESS "Shark" FlashCopy or RVA Snapshot. These copies can be used for remote-site recovery or point-in-time recovery. When a -SET LOG SUSPEND command is executed, a single DB2 subsystem checkpoint is taken, log buffers are flushed, a log-write latch is obtained, the BSDS is updated with the highest written RBA, and a message will be issued to the console that DB2 update activity has been suspended. A -SET LOG RESUME command will release the log-write latch, delete the suspended message, and issue a log-resumed message.

• The checkpoint interval is important for DB2 recovery processing. The longer the time between checkpoint intervals, the more your DB2 applications are exposed to a longer restart time in case of a system failure. The checkpoint interval, set with the CHKFREQ parameter in the DSNZPARMs, can be changed dynamically with the -SET LOG command. This parameter is based on the number of log records (LOGLOAD) written between checkpoints or a given number of minutes (CHKFREQ). The following example sets the checkpoint time to 20 minutes:

   - SET LOG CHKTIME (20) 

  
  

  In order to immediately force a system checkpoint you can issue the following statement.

   - SET LOG LOGLOAD(0) 

  
  

• An option in DB2 issues a warning message when a unit of work has written more log records than a defined threshold without a commit. This will let you identify those applications that would require a long backout and/or recovery in case of system or application failure. This option is set through the URCHKTH DSNZPARM. In order to minimize the amount of time it takes to recover from a system failure, we need to ensure that our applications are taking frequent commits.

Viewing Threads Affected by a Failure

If DB2 experiences an abnormal termination while transactions are running, you may need to determine which transactions were affected. This is important because these threads may be holding resources; they may have been making database changes when DB2 came down. The status of these units of recovery during the termination will be based on the point in time of the failure. The four states are in-doubt, in-commit, in-abort, and postponed-abort. To view the status of a thread, use the DISPLAY THREAD command. The following example shows the use of the command to find in-doubt threads after a termination that were not resolved during start-up:

 -DISPLAY THREAD(*) TYPE(INDOUBT)