Both Long running and Large transactions could potentially impact the restart of InfoSphere CDC since the earliest open log position is tracked and used when InfoSphere CDC restarts replication.
- If the earliest open log position is not contained in the staging space, then InfoSphere CDC will need to start back in the log, and if a transaction has been open for days, there is risk that the log would not be available
- For InfoSphere CDC z, if you have an invalid long running transaction (Unit of Recovery), then you can utilize the ENDUR command to dispose of it from replication scope. Note that this command must be used with great caution as you could incur replication data loss if you actually required the data in the transaction that you forced disposal of.
For very large transactions you need to ensure that the transaction staging space is large enough to contain the number of concurrent transactions being processed
- InfoSphere CDC LUW – Must set mirror_global_disk_quota_gb large enough to hold the transactions
InfoSphere CDC z - Uses a staging store to hold URs in memory above the bar until a commit is received. It must be large enough to contain all concurrent open URs. The size of this store is controlled by two parameters:
- STG64LIMIT total amount of memory which can be used by all users of above the bar memory in the address space
MAXSUBSCRSTAGESIZE amount of memory which can be used by the staging space for a single subscription
- It has an additional argument which specifies the number of completed commit groups in the staging store, defaulting to 10. Once this number is achieved, InfoSphere CDC will stop reading log data until one has been sent to the target and removed from the store