Evaluating the impact of a software reclone

While most non-replicated objects on the copy node remain intact during the software reclone, there are a set of objects with dependencies on replicated objects which may be affected.

There are three categories of affected objects on the copy node.

  1. Objects that will be deleted.
    • All the replicated objects of type *FILE, *SQLUDT, *JRN, *DTAARA, *DTAQ, *JOBQ, *USRIDX, *USRSPC, *SQLXSR in SYSBAS are deleted from the copy node as part of the software reclone. This is done to allow software reclone to save and restore the object from the source node.
    • If there are replicated objects that only exist on the copy node, they are deleted. This can occur if a change was made to the RCL on the source node while the replication state was TRACKING which identifies a new object to be replicated that only exists on the copy node. It could also occur if a replicated object on the source node was deleted or renamed while the replication state is TRACKING, or if the object was newly created on the copy node and on the Object Tracking List which had not yet been processed. Such an object as well as any dependent objects, either replicated or non-replicated, will be deleted as part of the software reclone. If a replicated library is identified as part of this process, all replicated and non-replicated objects within the library will also be deleted. These objects are identified and listed in step 1 of the software reclone when using the Db2® Mirror GUI, or by using the QSYS2.EVALUATE_RECLONE_REPLICATION_CRITERIA table function.
    • Non-replicated objects on the copy node which are dependent upon replicated objects will be deleted as part of the software reclone. Prior to being restored from the source node, some replicated objects must be deleted on the copy node before the resynchronization can be completed. All dependent objects will also be deleted by cascading delete rules. Replicated dependent objects will be restored on the copy node by the software reclone, but non-replicated dependent objects will remain deleted. Examples of dependent objects include non-replicated views or indexes defined over a replicated table. If these objects are needed on the copy node, they should be saved prior to the software reclone and restored when it is complete. These objects are identified and listed in step 3 of the software reclone when using the Db2 Mirror GUI, or by using the QSYS2.EVALUATE_RECLONE_RELATED_OBJECTS table function.

    While not identified by the EVALUATE services above, objects which are replicated as definition only will have any contents deleted on the copy node and are replaced entirely with the object from the source node. This includes replicated job queues, output queues, and data queues, along with any database files which are specified as definition only. For output queues, all replicated spool files from the source node will be restored onto the copy node as part of software reclone processing.

  2. Copy node objects that will no longer be journaled.
    • Any non-replicated objects on the copy node which are journaled to a replicated journal will have journaling ended as part of the software reclone. Journaling will only be reestablished for replicated objects. Journaling will need to be reestablished manually for any non-replicated objects on the copy node after the software reclone is complete. These objects are identified and listed in step 2 of the software reclone when using the Db2 Mirror GUI, or by using the QSYS2.EVALUATE_RECLONE_JOURNALED_OBJECTS table function.
  3. Updates to replicated security objects and attributes.

    When performing a software reclone of SYSBAS, all user profiles, authority lists, function usage information, and security attributes must be equivalent on both nodes. The software reclone process will attempt to resynchronize OTL entries for these objects. If a comparison after the resynchronization shows differences, the software reclone will fail and user action to resynchronize those objects will be required. Any specific object differences are identified and listed as part of step 4 of the software reclone when using the Db2 Mirror GUI, or by using the QSYS2.CONFIRM_RECLONE_SECURITY_OBJECTS view. Any differences can be corrected individually or by completing a Save Security Data (SAVSECDTA) on the source node and a Restore User Profiles (RSTUSRPRF) and Restore Authority (RSTAUT) on the copy node.

Once the impacts to the copy node have been identified in the first three steps of the software reclone when using the Db2 Mirror GUI, or by using the EVALUATE Db2 Mirror services, the user needs to decide if any of the affected objects on the copy node should be saved.

As the software reclone progresses, a deferred record will be written to the Object Tracking List (OTL) for each non-replicated object that is deleted on the copy node and for every non-replicated table, view, index, library, data area, data queue, and IFS object that has journaling ended.
Note: The results of steps 1-3 of the software reclone using the Db2 Mirror GUI, or the EVALUATE services are a point-in-time capture of affected objects. The objects affected by the software reclone might have changed, particularly if there are active applications running on either node.