Restarts a database that has been abnormally terminated and left in an inconsistent state. At the successful completion of RESTART DATABASE, the application remains connected to the database if the user has CONNECT privilege.
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.
None.
This command establishes a database connection.
>>-RESTART--+-DATABASE-+--database-alias------------------------> '-DB-------' >--+-------------------------------------+----------------------> '-USER--username--+-----------------+-' '-USING--password-' >--+-----------------------------------------------------+------> | .-,---------------. | | V | | '-DROP PENDING TABLESPACES--(----tablespace-name-+--)-' >--+--------------+-------------------------------------------->< '-WRITE RESUME-'
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.
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.
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.
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.
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.