COMMITFREQ
Commitment control is a capability of CDC for z/OS that groups data changes. It is based on an exchange of capabilities between the source and target systems. The COMMITFREQ parameter affects the subscription only if commitment control is enabled.
If either the source or target is not able to process COMMIT or ROLLBACK statements, then both sides work with a stream of table changes that are not delineated in any manner. The message CHC1108I is issued at subscription startup to indicate that commitment control is disabled.
If both sides are able to process COMMIT or ROLLBACK, then the source sends the data changes and generates a COMMIT statement that is based on the setting of the COMMITFREQ parameter. The target makes the changes that it receives from the source and then commits them when it receives the COMMIT statement.
If you do not see message CHC1108I issued for a subscription, then commitment control is in effect for that subscription and you can use COMMITFREQ to configure how changes are grouped and how commits are generated from the source.
COMMITFREQ specifies how frequently mirrored changes that are received from the source server are committed to the subscription database.
This keyword is set to a triplet of three mandatory values:
- The first value is the number of changes that can be applied to tables before a COMMIT is triggered.
- The second value is the threshold number of seconds that can pass since the last COMMIT was applied before a COMMIT is triggered.
- The third value is the number of commit groups that must be received from the source since the last COMMIT before a COMMIT is triggered.
If commitment control is not in effect, a COMMIT will be performed immediately whenever either of the first two conditions (number of changes or number of seconds) is satisfied.
If commitment control is in effect, a COMMIT will always be performed at a corresponding source commit boundary. When the next complete commit group is received after any of the three conditions is met, the data will be committed
When COMMIT is performed, the change counter, timer, and commit group counter are all reset.
The COMMITFREQ settings apply to each subscription separately. Changes or commit groups received for one subscription do no affect when COMMIT is performed for any other subscription. Similarly, each subscription has its own commit timer, which is not necessarily synchronized with any other subscription's commit timer.
The higher the settings for the COMMITFREQ keyword, the greater the increase in throughput that will be achieved. However, the increased throughput will be obtained at the cost of increasing the number, level of, and duration of DBMS locks that are acquired when the changes are being applied and an increased cost of handling deadlock/timeout retry situations.
For example, if COMMITFREQ=(1000,60,1) and
commitment control is not in effect. COMMIT will be performed after
1000 changes are received or 60 seconds pass, whichever occurs first.
Since commitment control is not in effect, no commit groups should
be received.
In another example, if COMMITFREQ=(10000,300,10) and
commitment control is in effect. COMMIT will be performed at the end
of the next commit group after 10000 changes are received, at the
end of the next commit group after 300 seconds pass, or after 10 complete
commit groups are received. In addition, if, after 300 seconds pass,
the last thing received was a complete commit group (no partial commit
group), COMMIT will be performed.
Note the following considerations for this keyword:
- Performance improvements are directly proportional to the size of the commit groups that you replicate.
- Commit group integrity is never compromised by this feature.
- Once commit groups have been grouped to the point that 500 or more changes are being made between commits, no further performance gains are possible.
This keyword is optional.
Default Setting—(1000 (records), 1 (second), 100 (commit groups))