The iCluster continuous sync check provides quick notification in the monitor when some object pair fails the compare (is out of sync). With the multiple options available there is little need to run nightly scheduled sync checks and you can refer to the monitor to view the current health or fidelity of the objects selected in the replication group.
When you create or change a replication group you can have a continuous sync check configured to start when the group starts by utilizing the CONTSYNC (*YES) on the DMADDGRP or DMCHGGRP command. Select the desired additional options available to control how the Sync Check process will behave. To control the resource consumption of a CSC process, use the "Delay Between Objects" value to have the activity operate in accordance to your system balance. The default value is 200 milliseconds. I suggest a starting value of approximately 600 and then adjust as desired.
Alternatively, to start a continuous sync check for an active group use the command STRCNSC. Here is an example command syntax using 600 milliseconds delay between each object pair. STRCNSC TARGET(<backup node name>) GROUP(<group name>) DELAY(600)This can be submitted from a custom CLP or from a job scheduler to control the period of time you want Continuous Sync Checks active. End a Sync Check with command ENDHASC. The only parameter required is the Replication Group name.
The CSC does generate QAUDJRN user journal entries in the System Audit Journal If you have CSC running for all replication groups and the delay value is very low, the activity to the QAUDJRN can become significant. If you issue a DSPJRN JRN(QSYS/QAUDJRN) USRPRF(DMCLUSTER) you will see a number of journal entries of code U (user) and types \o, \A, \B, \C, and \g. Many IBM Power Systems are today configured with high performance controllers and SSD devices and the additional I/O to the QAUDJRN does not cause the system to break a sweat. However, if you wish to control or reduce the QAUDJRN activity you can use one (or both) of two strategies; 1. Increase the "Between Object Delay" value. 2. Only run CSC for the more critical replication groups.
Make sure you have automatic journal management turned on for QAUDJRN (and all journals used in replication) so that the journal receivers no longer required are automatically deleted and storage requirements are automatically maintained with very little effort once it is set up. That is a different BLOG post but find that area with iCluster command: DMWRKJRN *ALL/*ALL *NO
77 4th AvenueWaltham, MA 02451 USA
Rocket Support Community
All Support Offerings
About Rocket Software
Training and Services
Forum Terms and Conditions
Contact Forum Moderator