Non-registered copy or INLOG specification


The INCOPY clause recovers by using non-registered image copies.

The syntax diagram for the Non-Registered Copy or INLOG Use specification is in RECOVER TABLESPACE, RECOVER INDEX, and RECOVER INDEXSPACE syntax.

INCOPY FULL

Specify the INCOPY clause to recover by using non-registered image copies. You must specify a full image copy. You might specify any number of incremental copies.

Warning

Important

When you specify INCOPY, BMC AMI Recover analyzes relevant events in SYSCOPY and BMCXCOPY, unless you specify TOCOPY LASTCOPY (see TOCOPY-specification). Then, no access to SYSCOPY or BMCXCOPY occurs.

We recommend INCOPY as the technique for specifying a copy of an index created with DSN1COPY for use in index recovery. Specification of the LOGPOINT and SHRLEVEL values is optional. If the index is encrypted, the ENCRYPTED option ( INCOPY specification) is required.

If this recovery is not an INDEPENDENT OUTSPACE recovery or an OUTCOPY ONLY recovery, BMC AMI Recover will register a point-in-time recovery with a PIT_RBA of zeros. Further, unless registered output copies are being created, COPY PENDING is set on any table space so recovered.

(BMC.DB2.SPE2510) Recovering a partition-by-growth (PBG) table space using RECOVER INCOPY when the table space was versioned requires a REPAIR CATALOG. Additionally, REPAIR CATALOG doesn't tolerate excess partitions in the PBG table space. Therefore, make sure that the target PBG table space doesn't have more partitions than the source.

Warning

Important

Note the following information about the use of INCOPY:

  • INCOPY doesn't support the use of a cabinet copy created by the BMC AMI Copy for Db2  product. If you have only a cabinet copy and need to do a drop recovery, you can use the BMC AMI Copy COPY IMAGECOPY command to unstack a cabinet copy and register the copies in SYSCOPY. You can then use the individual copies with the INCOPY option.
  • BMC AMI Recover supports Online Consistent Copy and consistent FlashCopy with log apply when you don't specify INCOPY.
  • BMC AMI Recover supports Online Consistent Copy and consistent FlashCopy with INCOPY TOCOPY specified.
  • BMC AMI Recover doesn't support Online Consistent Copy or consistent FlashCopy when you specify both INCOPY and log apply (RBA or LOGPOINT specified in the INCOPY specification).

The following table describes the options of Non-registered copy or INLOG specification:

Option

Description

INLINE

INLINE specifies that the copy specified in the INCOPY specification is an inline copy created by COPYDDN or RECOVERYDDN from a DB2 REORG or LOAD utility. To use an inline copy, you must specify this parameter. This option is valid for full image copies only. The INLINE option is not valid with indexes.

SNAPSHOT

SNAPSHOT specifies that the copy specified in the INCOPY specification is an Instant Snapshot copy that is not registered in BMCXCOPY. This option is valid for full image copies only. (For more information, see Using-Instant-Snapshots.)

FLASHCOPY

FLASHCOPY specifies that the copy specified in the INCOPY specification is an IBM FlashCopy. This option is valid for full image copies only.

SLBCOPY 

SLBCOPY specifies that the copy specified in the INCOPY specification is a system-level backup (SLB).

INCR

INCR specifies that the copy is an incremental copy. The INCR copies are processed in the order in which you specified them. Specification of the RBA/LOGPOINT and SHRLEVEL values (see INCOPY-specification) are optional.

NOCOPYPEND

If you specify the NOCOPYPEND option, BMC AMI Recover resets COPY-pending status and issues message BMC96232 to inform you that COPY-pending status has been reset even though the space is not recoverable.

For a point-in-time recovery, if you do not specify the NOCOPYPEND option, BMC AMI Recover sets COPY-pending status when all of the following conditions exist:

  • You did not specify INDEP OUTSPACE.
  • You did not specify OUTCOPY ONLY.
  • There is no registered OUTCOPY.

You might want to use the NOCOPYPEND option if you are migrating data from one Db2 subsystem to another in a query or testing system where you do not need to be able to run a recovery on the target space. To migrate the data, you make an image copy on the source system, transport the copy to the target system if necessary, and use RECOVER INCOPY on the target system.

Because the input copy is not registered on the target system, the target space is not recoverable after the RECOVER INCOPY. You cannot run a RECOVER to current on the target system because no usable copies are registered in SYSCOPY or BMCXCOPY.

INLOG RBA X'logPoint' or INLOG LOGPOINT X'logPoint'

INLOG RBA or INLOG LOGPOINT is used when you want to perform recovery by using only log after a LOAD LOG YES or a REORG LOG YES where the event is no longer registered in SYSCOPY. To do so, you must be aware of a point in the log corresponding to the specific event. You must specify a log point that exactly corresponds to such a point; otherwise, the recovery will not be able to apply the log and a severe internal error will result with completion code 12.

INLOG RBA or INLOG LOGPOINT specifies the log point in the log where the application of the log records should begin for the object being recovered.

'logPoint' is a string of up to twelve hexadecimal digits.

When you use INLOG RBA or INLOG LOGPOINT, you cannot use the TOCOPY option. You also might not specify LOGONLY or LOGAPPLY ONLY. Also, you cannot specify INCOPY when you use INLOG RBA or INLOG LOGPOINT, and any output copies made with the OUTCOPY ONLY facility cannot be registered unless DROPRECOVERY is also specified.

You can use the INLOG RBA and INLOG LOGPOINT keywords interchangeably, regardless of the version of Db2 used.

Warning

Important

INLOG RBA and INLOG LOGPOINT are not valid for index recovery because index records are not logged completely for a LOG YES utility.

 

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

BMC AMI Recover for Db2 13.1