DB2 10.5 for Linux, UNIX, and Windows

Troubleshooting a database in an inconsistent state

When attempting to perform database operations, you might receive an error message stating that the database is in an inconsistent state.

Symptoms

When attempting to perform database operations, you might receive an error message stating that the database is in an inconsistent state.

Causes

The possible causes of this are:
  • The database is offline as a result of an abnormal termination of the previous session (for example, a power failure).
  • If the error was encountered when issuing the db2ckupgrade command:
    • The database is online and SQL has been issued which modified data in the database.
    • The database is online and HADR has been enabled.
  • In DB2® pureScale® environments only, possible causes also include:
    • The database on this DB2 member is offline as a result of an abnormal termination of the previous session.
    • The database is offline across the entire DB2 pureScale instance as a result of an abnormal termination of the previous session.
    • If drop operations are done in the instance, recoverable databases are already put into backup pending state. Drop operations are not allowed until backup of database is done.
    • An attempt was made to modify the cluster topology (for example, adding or deleting a member) while the database was in one of the following states: backup pending, restore pending, rollforward pending.

Resolving the problem

  • If the database is offline as a result of an abnormal termination of the previous session, respond with the following actions
    1. Restart the database using the RESTART DATABASE command. In a partitioned database server environment, the command must be issued on all database partitions.
  • If this error was encountered when issuing the db2ckupgrade command, respond with the following actions:
    1. Perform a clean shutdown of the database.
    2. After shutdown, if HADR has been enabled on the database, issue the STOP HADR command on the database.
    3. Reissue the db2ckupgrade command.
  • In a DB2 pureScale environment only:
    1. If the database on this DB2 member is offline as a result of an abnormal termination of the previous session, respond with the following actions:
      1. By default, member crash recovery is automatically initiated in a DB2 pureScale environment, so no user action is required. If member crash recovery is not automatically enabled, perform member crash recovery on this DB2 member by issuing the RESTART DATABASE command.
      2. Some database operations can still complete on other, consistent members even if one member is inconsistent. To access the database during member crash recovery, connect to an active DB2 member. To access this specific member, wait for member crash recovery to complete.
    2. If the database is offline across the entire DB2 pureScale instance as a result of an abnormal termination of the previous session, warn users that the database will not be available until recovery completes. The next step depends on whether group crash recovery is automatically enabled. If it is enabled (the default), then no user action is required. If automatic group crash recovery is not enabled, respond with the following actions:
      1. Perform group crash recovery by issuing the RESTART DATABASE command.
      2. After the recovery completes, perform member crash recovery on any other members that have indoubt transactions.
    3. Back up databases that are in backup pending state, and resubmit drop operation.
    4. If the database is in a state that is not compatible with a topology change, then address the issue and then attempt the topology change request again.