Table space considerations for the Db2 pureScale Feature

A Db2 pureScale environment requires specific types of table spaces.

Table space type support

A Db2 pureScale environment supports only the use of automatic storage type table spaces. Prior to migration from an environment other than a Db2 pureScale environment to a Db2 pureScale environment, there must be no system managed space (SMS) tables spaces, regular database managed space (DMS) table spaces, or automatic storage hybrid table spaces. If CREATE TABLESPACE command is issued on a non-automatic storage type in a Db2 pureScale environment, an error is returned (SQL1419N).

Temporary table space support

In a Db2 pureScale configuration, the storage paths for temporary table spaces are defined within the clustered file system. These temporary table spaces are managed locally by each member. The container path is shared by all members, and table space files in that directory are made unique for each member. A member identification number is associated with each file path name.

Transient table space states

In a Db2 pureScale environment, crash recovery after a member failure can take place in parallel during other members' normal runtime activity. These transient states must remain set to block other incompatible operations from starting until member crash recovery (MCR) of that failed member has occurred. There are two types of transient table space states. The first type can be cleared anytime after the member's failure but before recovery starts. As a result of this, if SQLB_BACKUP_IN_PROGRESS, SQLB_DISABLE_PENDING or SQLB_MOVE_IN_PROGRESS are set by the failed member they will remain set until, either:
  1. MCR for this database is initiated, or
  2. Another member needs to load that table space into its in-memory cache.
The other type of transient table space state needs to remain set until the end of MCR to protect the operations that were running at the time of the failure (for example, a table reorg and certain load commands).

As a result of this, if SQLB_REORG_IN_PROGRESS, or SQLB_LOAD_IN_PROGRESS are set by the failed member they remain set until MCR is completed successfully.

Issuing table space DDL requests

In a partitioned database environment, if the host or Db2 instance of a database partition is down, a table space DDL SQL transaction will fail and the statement will be rolled back. In the case where the host or Db2 instance is up but the database infrastructure is not activated there, the DDL request will implicitly activate the database to process the request. These general behaviors differ in a Db2 pureScale environment as follows:
  1. CREATE TABLESPACE, ALTER TABLESPACE, and DROP TABLESPACE operations do not require all members to be up to be completed successfully.
  2. If the database infrastructure is not activated on a member, a table space DDL request will not perform implicit activation.