Troubleshooting Q Replication
This information helps you diagnose, recover from, and resolve problems that are encountered when you are using Q Replication.
| Issue | Solution |
|---|---|
The target table enters a nonaccessible state because load fails and the Db2®
NOT LOGGED INITIALLY parameter is used. |
Drop and re-create the affected target table. |
| Initial load for row organized table replication fails. | Ensure that the Db2 registry variable
DB2_LOAD_RESTRICTED_IO_PATH in the Db2 container has the correct Q Replication path:
/mnt/qrepdata/bludr/logs/replication for replication. |
| A Db2 table with unique key enforce does not allow duplicate rows with the same key. When Q Capture fails to handle the duplicate row error, the duplicate row should not be replicated, but Q capture passes the duplicate row to the target. If the target table has unique key, the duplicate row goes to an exception table; if not, the target will have the duplicate row, which is not in the source table. | Q Capture correctly handles rolled back rows for a unique key violation. Both source and target table must have the same unique key constraint for correct handling by Q Capture. |
| Q Replication cannot support private link on Db2 Warehouse SaaS. |
In versions 11.5.9 and older, you can replicate Db2 data cross regions on Db2 Warehouse SaaS where public link to access Db2 and Q Replication is required. Starting from Db2 version 12, host validation is turned on by default. As a result, any replication performed within the same region must also use public link since private link access to Db2 requires host validation to be turned OFF. |