How To
Summary
Most resynchronization operations within Db2 Mirror succeed, however there are sequences of operations on certain objects that fail even if the objects are processed in tracking time order. This document attempts to illustrate an example of how to handle one such case and the general steps required to resolve these kinds of issues.
Objective
Environment
Steps
While most resynchronization operations succeed, there are sequences of operations on certain objects that fail even if the objects are processed in tracking time order.
Most of these cases involve a combination of save and restore entries within the Object Tracking List (OTL) or a rename or move operation. For these situations, user intervention is necessary. In this example, DATALIB is a library that is always included in replication. There are no specific rules for any *FILE objects in the library, so all eligible files are always included in replication. Suppose the following operations are performed on the primary node while in TRACKING state, with entries added to the OTL to track the changes:
- Restore table DATALIB/SIMPLE1 (SIMPLE1 did not exist before the restore).
- Create a view DATALIB/SIMPLE1V that depends on SIMPLE1.
- Rename table DATALIB/SIMPLE1 to SIMPLE2.
When resynchronization is attempted, the save and restore entries cannot be processed because SIMPLE1 no longer exists. Since the object cannot be found on the primary or secondary node, the save and restore entries are deferred. When the CREATE VIEW is attempted, it also fails because SIMPLE1 cannot be found. Finally, the rename operation also fails because SIMPLE1 cannot be found. The following figure shows the errors as they are recorded in the OTL. The errors can be found in the resynchronization job log to provide additional information to help identify the problem.
During resynchronization, it is possible that one or more objects are successfully restored before a failure is encountered, such as the CPF3204 message encountered for SIMPLE1V described here. In those cases, we want to perform the steps outlined in the example against all objects including any dependencies of the objects that encompass the errors recorded in the OTL. In this specific case, we are only concerned with the files associated with the renamed table, the view, and getting those objects replicated to the secondary node. The most efficient way to resolve this problem requires the following steps:
-
Change the RCL to exclude the file’s old name (SIMPLE1), new name (SIMPLE2), and the view name (SIMPLE1V). When objects are excluded from replication, any entries within the OTL for those objects are removed. This step can be done though the Db2 Mirror GUI or by calling the following procedures:
CALL QSYS2.ADD_REPLICATION_CRITERIA(INCLUSION_STATE => 'EXCLUDE', IASP_NAME => '*SYSBAS', LIBRARY_NAME => 'DATALIB', OBJECT_TYPE => '*FILE', OBJECT_NAME => 'SIMPLE1', APPLY => 'PENDING', APPLY_LABEL => 'FIXOTL'); CALL QSYS2.ADD_REPLICATION_CRITERIA(INCLUSION_STATE => 'EXCLUDE', IASP_NAME => '*SYSBAS', LIBRARY_NAME => 'DATALIB', OBJECT_TYPE => '*FILE', OBJECT_NAME => 'SIMPLE2', APPLY => 'PENDING', APPLY_LABEL => 'FIXOTL'); CALL QSYS2.ADD_REPLICATION_CRITERIA(INCLUSION_STATE => 'EXCLUDE', IASP_NAME => '*SYSBAS', LIBRARY_NAME => 'DATALIB', OBJECT_TYPE => '*FILE', OBJECT_NAME => 'SIMPLE1V', APPLY => 'PENDING', APPLY_LABEL => 'FIXOTL'); CALL QSYS2.PROCESS_PENDING_REPLICATION_CRITERIA(IASP_NAME => '*SYSBAS', APPLY_ACTION => 'COMMIT', APPLY_LABEL => 'FIXOTL');All error entries relating to these objects are now removed or deferred within the OTL.
-
If any objects that were excluded from replication exist on the secondary node, delete the object from that node. Care must be taken to ensure that all dependent objects are also excluded from replication so that any cascaded deletes do not affect those replicated objects.
-
Now that the error entries for these objects are removed from the OTL and any objects are cleaned up from the secondary node, change the RCL to again include all files in DATALIB for replication. This step can be done though the Db2 Mirror GUI or by calling the following procedures:
CALL QSYS2.REMOVE_REPLICATION_CRITERIA(IASP_NAME => '*SYSBAS', LIBRARY_NAME => 'DATALIB', OBJECT_TYPE => '*FILE', OBJECT_NAME => 'SIMPLE1V', APPLY => 'PENDING', APPLY_LABEL => 'FIXOTL'); CALL QSYS2.REMOVE_REPLICATION_CRITERIA(IASP_NAME => '*SYSBAS', LIBRARY_NAME => 'DATALIB', OBJECT_TYPE => '*FILE', OBJECT_NAME => 'SIMPLE2', APPLY => 'PENDING', APPLY_LABEL => 'FIXOTL'); CALL QSYS2.REMOVE_REPLICATION_CRITERIA(IASP_NAME => '*SYSBAS', LIBRARY_NAME => 'DATALIB', OBJECT_TYPE => '*FILE', OBJECT_NAME => 'SIMPLE1', APPLY => 'PENDING', APPLY_LABEL => 'FIXOTL'); CALL QSYS2.PROCESS_PENDING_REPLICATION_CRITERIA(IASP_NAME => '*SYSBAS', APPLY_ACTION => 'COMMIT', APPLY_LABEL => 'FIXOTL'); -
Resume replication either from the Db2 Mirror GUI or by using the QSYS2.CHANGE_MIRROR procedure.
CALL QSYS2.CHANGE_MIRROR(IASP_NAME => '*SYSBAS', REPLICATION_STATE => 'RESUME');
Note: Dependencies between files, it might be necessary (or at least better from a performance perspective) to also include certain dependent files. For example, assume that there is another table called COMPLEX1 and that a unique keyed logical file (LGLUNQ) exists over both SIMPLE1 and COMPLEX1. COMPLEX1 is not also excluded and then included again in the RCL, it is possible that duplicate key failures might occur. Even if duplicate key errors would not occur, the index for LGLUNQ would need to be rebuilt if COMPLEX1 is not also included.
Related Information
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
01 December 2022
UID
ibm10959079