RESTART DATABASE command

Scope

This command affects only the database partition where the command is run. In DB2® pureScale® environments, this command resumes I/O write operations for all suspended members.

In DB2 pureScale environments, this command might trigger, when needed, a group crash recovery, which performs the crash recovery for all members of the group, or a member crash recovery.

Authorization

None.

Required connection

This command establishes a database connection.

Command syntax

>>-RESTART--+-DATABASE-+--database-alias------------------------>
            '-DB-------'                   

>--+-------------------------------------+---------------------->
   '-USER--username--+-----------------+-'   
                     '-USING--password-'     

>--+-----------------------------------------------------+------>
   |                              .-,---------------.    |   
   |                              V                 |    |   
   '-DROP PENDING TABLESPACES--(----tablespace-name-+--)-'   

>--+--------------+--------------------------------------------><
   '-WRITE RESUME-'   

Command parameters

DATABASE database-alias

Identifies the database to restart.

USER username

Identifies the user name under which the database is to be restarted.

USING password

The password used to authenticate username. If the password is omitted, the user is prompted to enter it.

DROP PENDING TABLESPACES tablespace-name

Specifies that the database restart operation is to be successfully completed even if table space container problems are encountered.

If a problem occurs with a container for a specified table space during the restart process, the corresponding table space will not be available (it will be in drop-pending state) after the restart operation. If a table space is in the drop-pending state, the only possible action is to drop the table space.

If a problem occurs with a container during a member crash recovery, the member crash recovery operation will fail. To correct this situation, shut down all members using a db2stop -force command and manually initiate a group crash recovery by reissuing the RESTART DATABASE command. Following the group crash recovery, the table space corresponding to the problematic container will not be available (for more information, see the "Recovering with damaged table spaces" topic).

In the case of circular logging, a troubled table space will cause a restart failure. A list of troubled table space names can found in the administration notification log if a restart database operation fails because of container problems. If there is only one system temporary table space in the database, and it is in drop pending state, a new system temporary table space must be created immediately following a successful database restart operation.

WRITE RESUME

Forces a restart for databases that crashed while I/O write operations were suspended. Before performing crash recovery, this parameter will resume I/O write operations. In DB2 pureScale environments, this parameter resumes I/O write operations for all suspended members.

You can also use the WRITE RESUME parameter if the connection that you used to suspend I/O write operations is currently hung and all subsequent connection attempts are also hanging. When you use the parameter in this case, the RESTART DATABASE command resumes I/O write operations for the database without performing crash recovery. The RESTART DATABASE command with the WRITE RESUME parameter performs crash recovery only when you use it after a database crash.

Usage notes

Issue this command if an attempt to connect to a database returns an error message indicating that the database must be restarted. This error message is generated only if the previous session with this database terminated abnormally, for example, because of a power failure.

Partitioned database environments

On a partitioned database system, to resolve the indoubt transactions, you should issue the RESTART DATABASE command on all database partitions, as shown in the following example:

db2_all "db2 restart database database-alias"

If you restart the database on only a single database partition within a partitioned database environment, a message indicating that you must restart the database might be returned on a subsequent database query. This message is returned because you did not restart the database on a database partition on which the query depends. Restarting the database on all database partitions solves the problem.

DB2 pureScale environments

In a DB2 pureScale environment, the RESTART DATABASE command is the only way to manually invoke crash recovery. The database manager automatically determines whether a group crash recovery or a member crash recovery is required. After group crash recovery completes, if any indoubt transactions exist on any of the members that did not perform group crash recovery, a member crash recovery on those members must be performed to enable resolution of those indoubt transactions.

If the write operations for the database were in the process of being suspended at the time of the crash, perform crash recovery by using the RESTART DATABASE command. If a SET WRITE SUSPEND operation is running on another member, you might have to wait for the SET WRITE SUSPEND operation to complete before performing crash recovery. After it is complete, submit the RESTART DATABASE command with the WRITE RESUME parameter to restart the database and resume write operations for all the suspended members.

If the write operations were successfully suspended on the database at the time of the crash, there are two ways that you can perform crash recovery:

• You can use the RESTART DATABASE command with the WRITE RESUME parameter.
• You can issue a SET WRITE command with the RESUME parameter from an active member and then issue the RESTART DATABASE command from the crashed member.