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.
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)