Scenarios: Adding and removing storage with automatic storage table spaces

The three scenarios in this section illustrate the impact of adding and removing storage paths on automatic storage table spaces.

Once storage paths have been added to or removed from storage groups, you can use a rebalance operation to create one or more containers on the new storage paths or remove containers from the dropped paths. The following should be considered when rebalancing table spaces:

  • If for whatever reason the database manager decides that no containers need to be added or dropped, or if containers could not be added due to out of space conditions, then you will receive a warning.
  • The REBALANCE clause must be specified on its own.
  • You cannot rebalance temporary automatic storage table spaces; only regular and large automatic storage table spaces can be rebalanced.
  • The invocation of a rebalance is a logged operation that is replayed during a rollforward (although the storage layout might be different)
  • In partitioned database environments, a rebalance is initiated on every database partition in which the table space resides.
  • When storage paths are added or dropped, you are not forced to rebalance. In fact, subsequent storage path operations can be performed over time before ever doing a rebalance operation. If a storage path is dropped and is in the Not In Use state, then it is dropped immediately as part of the ALTER STOGROUP operation. If the storage path is in the In Use state and dropped but table spaces not rebalanced, the storage path (now in the Drop Pending state), is not used to store additional containers or data.