IBM Support

Manual bind is needed for replication when CUR_COMMIT is set ON in DB2

Flash (Alert)


Abstract

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.

Content

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:

Q Apply
db2 bind @qapply.lst isolation ur blocking all grant public concurrentaccessresolution wait_for_outcome

Q Capture
db2 bind @qcapture.lst isolation ur blocking all concurrentaccessresolution wait_for_outcome

SQL Apply
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

SQL Capture
db2 bind @capture.lst isolation ur blocking all concurrentaccessresolution wait_for_outcome

Document information

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