Methods of restarting

DB2® can restart in several different ways. Some options are based on how DB2 terminated or what your environment is.

Types of termination
DB2 terminates normally in response to the STOP DB2 command . If DB2 stops for any other reason, the termination is considered abnormal.
Normal restart and recovery
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.
Automatic restart
If you run DB2 in a sysplex, you can have the automatic restart function of z/OS® automatically restart DB2 or IRLM after a failure.
Restart in a data sharing environment
In a data sharing environment, restart processing coordinates data recovery across more than one DB2 subsystem.
Restart implications for table spaces that are not logged
Even if all tables that are modified by a transaction reside in table spaces that are not logged, a unit of recovery is established before any of those updates are performed. Undo processing continues to read the log in the backward direction, looking for undo log records that need to be applied. Undo processing stops when it detects the beginning of this unit of recovery as recorded on the log.
Conditional restart
A conditional restart is a DB2 restart that is directed by a user-defined conditional restart control record (CRCR).

Parent topic: Restarting DB2 after termination