Additional RECOVER INDEX and RECOVER INDEXSPACE limitations

Additional limitations apply when you use RECOVER INDEX or RECOVER INDEXSPACE to recover indexes.

Consider the following items in addition to those listed in RECOVER-TABLESPACE-RECOVER-INDEX-and-RECOVER-INDEXSPACE-command-dependencies-and-prohibitions.

Important

An index space does not have to be defined with the COPY YES attribute to be recoverable.

Related topics

RECOVER-TABLESPACE-RECOVER-INDEX-and-RECOVER-INDEXSPACE-commands

TORBA-or-TOLOGPOINT-specification

  • If you have used the PACLOG for DB2 utility to exclude the index log records, index recovery from logs is not possible.
  • If you specify RECOVER INDEX (ALL) or RECOVER INDEXSPACE (ALL), RECOVER INDEX and RECOVER INDEXSPACE do not support the FROMRBA/FROMLOGPOINT options and only support the OUTCOPY option when the copies are dynamically allocated. (For syntax about dynamic allocation, see OUTPUT-command.) You can use separate index specifications with RECOVER INDEX and RECOVER INDEXSPACE to use those options.
  • If you have used an ALTER statement to change the PIECESIZE for an index, index recovery from the log is not possible.
  • If a table space is recovered to a prior point in time, the default TORBA or TOLOGPOINT value for recovery of any indexes on that table space is the log point specified for the table space. If you specify different log points for the table space and its index, either with TORBA, TOLOGPOINT, or TOCOPY, BMC AMI Recover ends with an error.
  • If you recover a table space by using the TOCOPY and the INCOPY keywords, and you also recover a related index by using the TOCOPY and the INCOPY keywords, BMC AMI Recover cannot verify that the two copies are in sync.
  • BMC AMI Recover does not prevent a point-in-time recovery of an index that does not include a point-in-time recovery of the table space or other indexes on the table space.
  • Indexes must always have a copy or other backup if RECOVER INDEX or RECOVER INDEXSPACE is used without BACKOUT. If an index is created on a table that contains data, Db2 does not log the index updates. Similarly, index rebuilds or updates that result from LOG YES utilities are not logged. If the index is created on a table, an image copy or other backup must be made before the index is recoverable.

  • In addition to the LOG NO SYSCOPY events that make a table space unrecoverable, any LOAD LOG YES event or REORG LOG YES event between the image copy and the TORBA or TOLOGPOINT value makes an index unrecoverable. REBUILD INDEX and REORG INDEX command statements can also render an index unrecoverable, and BMC AMI Recover cannot detect these events for COPY NO indexes if non-BMC utilities are used.

    BMC AMI Recover REBUILD INDEX events are registered in the BMCXCOPY table for all COPY NO indexes. BMC REORG PLUS registers REORG INDEX events for COPY NO indexes in the BMCXCOPY table.

    You cannot use RECOVER INDEX or RECOVER INDEXSPACE commands for forward index recovery through a point-in-time recovery event created by a BACKOUT job.

  • If you specify the INCOPY option with OBIDXLAT, and you do not specify INDEP OUTSPACE or OUTCOPY, a warning message stating that a copy is required is issued and the original status of the index and its table space is not restored.

    Important

    BMC AMI Recover requires consistent use of the INDEP OUTSPACE option across all commands; if you use INDEP OUTSPACE with one command, you must use it with all other commands that support it. If you use INDEP OUTSPACE but subsequently omit it from another command that supports it, BMC AMI Recover issues an error message.

  • When you use RECOVER INDEXSPACE with OBIDXLAT for indexes, you must also specify the table ID that is associated with the index as an additional OBID(x,y) clause, where x is the ID of the source table and y is the ID of the target table. If you do not specify this extra OBID clause, the job issues the following message:

    BMC40764I TABLE OBID X'xxxx' FOUND AT OFFSET X'3A' IN INDEX HEADER
    WILL NOT BE TRANSLATED

    You might, however, omit both OBID(x,y) clauses. If you omit both clauses, appropriate default values are supplied. For more information, see OBIDXLAT-specification.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*