Recovery of altered spaces

BMC AMI Recover supports online schema evolution, including recovering spaces that have had:

  • Partitions added, rotated, or dropped

  • Their limit keys changed

  • Some materialized pending changes

Added partitions

If you add a partition with an ALTER statement or if a partition is automatically added with a partition-by-growth (PBG) universal space, you can perform the following recoveries with BMC AMI Recover:

  • You can recover the partition to the current time.

  • You can recover the partition to a point in time after the partition was added.

  • You can recover spaces to a point in time before the partition existed (prior to the ALTER ADD PARTITION), and BMC AMI Recover creates the partition with no data.

If a point-in-time recovery causes a partition-by-growth table space to shrink and leave the space empty, the underlying data set will contain a header and space map. The number of partitions will not be decreased in the catalog.

Important

For universal table spaces, if you use the LASTQUIESCE option and the quiesce is prior to the ALTER ADD PART, the recovery will fail. You must specify a hard-coded RBA. If the partition was added for a partition-by-growth space, you can use the LASTQUIESCE option.

When you are performing a drop recovery or a migration of a range-partitioned table space, the number of source partitions must match the target.

  • For a DROPRECOVERY, IMPORT, or INCOPY request of PBG universal spaces where the number of source data sets differs from the number of target data sets, BMC AMI Recover determines the number of source data sets and acts accordingly.

  • For a MIGRATE or INDEP OUTSPACE request, if the number of source data sets is greater than the number of target data sets, the request fails. If the number of target is greater than the number of source data sets, the unused target data sets is reset with a header page and space map.

Rotated partitions

If you rotate (ALTER ADD ROTATE) a partition, you can perform the following recoveries with BMC AMI Recover:

  • You can recover the partition to the current time.

  • You can recover the partition to a point in time after the rotate.

You cannot recover table or index space partitions to a point in time before the partition was rotated.

Inserted partitions

If you use ALTER ADD PARTITION to insert a new partition in the middle of the table in a range-partitioned table space, you can perform the following recoveries with BMC AMI Recover:

  • You can recover the partition to the current time.

  • You can recover the partition to a point in time (PIT) after the partition insertion.

You cannot recover a table space or specific partition to a PIT before the new partition insertion.

Dropped partitions

If trailing partitions are removed from a PBG table space by a REORG on a subsystem where DSNZPARM parameter REORG_DROP_PBG_PARTS is enabled, you can perform the following recoveries with BMC AMI Recover:

  • You can recover the remaining partitions to the current time.

  • You can recover the remaining partitions to a point in time after the trailing partitions were removed.

You cannot recover table or index space partitions to a point in time before the partitions were removed.

Changed limit keys

If you change the limit keys on a partitioned space, the affected partitions are placed in REORP status and you cannot use the affected partitions until you run a REORG on those partitions.

Db2 added the REBALANCE feature to the REORG utility that changes limit keys and does a REORG of the specified partitions in one step, which avoids having the spaces put in REORP status.

However, starting with Db2 Version 11, the change of limit keys for range-partitioned table is treated as pending change. In this case, the affected partitions are placed in AREOR status and are recorded in the SYSIBM.SYSPENDINGDDL DB2 catalog table.

If you recover to a point in time that precedes the change, you need to reorganize the spaces, and they are placed in REORP status.

Materialized pending changes

BMC AMI Recover allows you to recover to a point in time (PIT) before a reorganization that materialized some types of online pending changes.

You can use this feature only with a range-partitioned or partition-by-growth universal table space (PBR UTS or PBG UTS), an XML space, or a LOB space. You can perform a PIT recovery over the following pending changes:

  • PBR UTS

    • DSSIZE

    • PGSIZE

    • SEGSIZE

    • MEMBER CLUSTER

  • PBG UTS

    • DSSIZE

    • PGSIZE

    • SEGSIZE

    • MEMBER CLUSTER

  • XML auxiliary space

    • DSSIZE

    • SEGSIZE

  • LOB auxiliary space

    • DSSIZE

    • PGSIZE

The PIT recovery sets the table space in REORP status and inserts a row into the SYSIBM.SYSPENDINGDDL DB2 catalog table. You must reorganize the entire table space to complete the PIT recovery and remove the row from the SYSIBM.SYSPENDINGDDL DB2 catalog table.

Following are restrictions that apply when you recover to a PIT that precedes materializing the pending definition changes:

  • You must recover the entire table space. You cannot recover specific partitions.

  • You cannot recover indexes.

  • There must not be any current pending changes.

  • The table space attributes cannot be in a CLONE relationship.

  • You cannot perform recovery to a subsequent and different PIT until after the reorganization that completes the recovery.

Important

After executing a reorganization to materialize a DROP COLUMN pending change, you cannot perform a PIT recovery to a point before the materializing reorganization.

Related topic

Was this page helpful? Yes No Submitting... Thank you

Comments