Database deactivation behavior in first-user connection scenarios

A database is activated when a user first connects to it. In a single-partition environment, the database is loaded into memory and remains in this state until the last user disconnects. The same behavior applies to multi-partition environments, where any first-user connection activates the database on both local and catalog partitions for that database.

When the last user disconnects, the database shuts down on both local and any remote partitions where this user is the last active user connection for the database. This activation and deactivation of the database based on first connection and last disconnection is known as implicit activation. Activation is initiated by the first user connection, and the activation remains in effect until the user executes a CONNECT RESET (or until the user terminates or drops the connection), which results in the database being implicitly deactivated.

The process of loading a database into memory is very involved. It encompasses initialization of all database components, including buffer pools, and is the type of processing that should be minimized, particularly in performance-sensitive environments. This behavior is of particular importance in multi-partition environments, where queries that are issued from one database partition reach other partitions that contain part of the target data set. Those database partitions are activated or deactivated, depending on the connect and disconnect behavior of the user applications. When a user issues a query that reaches a database partition for the first time, the query assumes the cost of first activating that partition. When that user disconnects, the database is deactivated unless other connections were previously established against that remote partition. If the next incoming query needs to access that remote partition, the database on that partition will first have to be activated. This cost is accrued for each activation and deactivation of the database (or database partition, where applicable).

There are two exceptions to this behavior:
  • The user explicitly activates the database by running the ACTIVATE DATABASE command. After this command completes successfully, the database remains in memory, even if the last user disconnects. This applies to both single-partition and multi-partition environments. To deactivate such a database, issue the DEACTIVATE DATABASE command. Both commands are global in scope, meaning that they activate or deactivate the database on all database partitions, if applicable.
  • The user has customized implicit database activation by setting the activate_db database configuration parameter to IMPLICIT or AUTO. The AUTO setting is only available for single-partition environments. The IMPLICIT setting is only available for single-partition or Db2® pureScale® environments. The database remains in memory, even if the last user disconnects. To deactivate such a database, run the DEACTIVATE DATABASE command.
Given the processing-intensive nature of loading a database into memory, consider explicitly activating databases rather than relying on implicit activation through the database connection. You can activate the database explicitly through the following methods:
  • By running the ACTIVATE DATABASE command.
  • By setting the activate_db database configuration parameter to AUTO, to enable automatic database activation.
Note: The activate_db database configuration parameter is available in Db2 12.1.5 and later.