Space state after the execution of utility statements

The user spaces, tables and indexes affected by the execution of the utility remain locked in the following cases even after execution of the utility statement has been completed:

• After LOAD OFFLINE, when the indexes have not yet been recovered.
  Index state: “defective”
  User space state: OK

• Once user data has been loaded into a base table in the user space with LOAD OFFLINE, the integrity constraints have not yet been checked. The primary key constraint is always checked when LOAD is executed.
  Base table state: “check pending”
  User space state: “check pending”

• After IMPORT TABLE in the following situations:

  • If user data is being imported and logging is activated for the user space.
    User space state: “copy pending”

  • If indexes have not yet been constructed.
    Index state: “defective”
    User space state: OK

• After ALTER DATA FOR TABLE, a SESAM backup of the user space has to be created before processing of the user space continues if logging is enabled for this user space.
  User space state: “copy pending”

• After ALTER PARTITIONING FOR TABLE, a SESAM backup of the user spaces has to be created before processing of the user space continues if logging is enabled for these user spaces.
  User space state: “copy pending”

• During the execution of the CHECK CONSTRAINTS statement, SESAM/SQL detected an integrity constraint violation in connection with at least one base table in the user space.
  Base table state: “check pending”
  User space state: “check pending”

• After RECOVER TO, the user data violates integrity constraints.
  User space state: “check pending”

• After LOAD OFFLINE and MIGRATE, a SESAM backup of the user space has to be created before processing continues if logging is enabled for the user space in question.
  User space state: “copy pending”

• After MIGRATE, LOAD OFFLINE or IMPORT TABLE, if loading is cancelled because of an error.
  User space state: “load running”

• After RECOVER USING, if, for a partitioned table, changes must be applied on this space with CREATE INDEX or DROP INDEX, but not all the user spaces who accomodate partitions of this partitioned table are contained in the RECOVER statement.
  State of the user spaces on which indexes are located which where newly created using RECOVER: “copy pending”

• In the following situations after a RECOVER TO:

  • Logging is enabled for the user space and the data needed to be adapted to the definitions in the catalog space.
    User space state: “copy pending”

  • The indexes had to be recovered.
    State of the user space in which those indexes are located which were rebuilt with RECOVER TO: “copy pending”

• The current state of the user space could not be recovered during repair (e.g., because the DA LOG files are missing or corrupt).
  User space state: “recover pending”

• An error occurred while the user space was being processed (e.g., a utility statement terminated with an error) or SESAM/SQL detected a data error in the user space.
  User space state: “space defect”

In section “Working on locked user spaces” you will find a description of how the database administrator can edit locked user spaces.

For information on which utility statements can be executed in connection with a specific user space state and on the state to which the user space switches as a result of the given statement, see the “SQL Reference Manual Part 2: Utilities”.