Manual bind is needed for replication when CUR_COMMIT is set ON in DB2
When the CUR_COMMIT configuration parameter is set to ON in DB2 for Linux, UNIX, and Windows Version 9.7 and later, you must issue the bind command manually with a new bind parameter to run the replication process without any issue.
When CUR_COMMIT is set to ON, a query returns the currently committed value of the data at the time when the query was submitted. The query does not wait for the outcome of other insert/update/delete operations that have not yet committed, and instead returns the result immediately.
Because of this behavior, the replication packages must be bound with CONCURRENTACCESSRESOLUTION WAIT_FOR_OUTCOME.
Examples of bind:
db2 bind @qapply.lst isolation ur blocking all grant public concurrentaccessresolution wait_for_outcome
db2 bind @qcapture.lst isolation ur blocking all concurrentaccessresolution wait_for_outcome
db2 bind @applycs.lst isolation cs blocking all grant public concurrentaccessresolution wait_for_outcome
db2 bind @applyur.lst isolation ur blocking all grant public concurrentaccessresolution wait_for_outcome
db2 bind @capture.lst isolation ur blocking all concurrentaccessresolution wait_for_outcome
More support for:
InfoSphere Replication Server
Software version: 9.7, 10.1, 10.2.1.0
Operating system(s): AIX, HP-UX, Linux, Solaris, Windows
Reference #: 1457826
Modified date: 10 February 2016