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:
- MCR for this database is initiated, or
- 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:
- CREATE TABLESPACE, ALTER TABLESPACE, and DROP TABLESPACE operations do not require
all members to be up to be completed successfully.
- If the database infrastructure is not activated on a member, a
table space DDL request will not perform implicit activation.
DB2 Version 10.1 for Linux, UNIX, and Windows