Q-Replication - Tables with secondary unique index

Gopalan Venkatramani

Q-Replication - Tables with secondary unique index


I'm doing a complete schema level replication which has around 600+ tables. However I'm good on 200+ tables however 350+ tables are replicated because of 

"ASN7624I  "Q Apply" : "ASNUTGT" : "BR00000" : Found "1" secondary unique index(es) for Q subscription "TABLESAMPLE0001" (receive queue "ASNUSRC.SAMPLE_TO_ASNUTGT.CMSDBOC.DATA", replication queue map "ASNUSRC_TO_ASNUTGT")."

All tables having secondary indexes is not getting replicated. 

What am I missing here ? 

Already my Capture and apply program is running. Is there a way I can re-initiate these tables alone without stop and start ?

Appreciate for any support !!!

 

This is how I create the subscription for whole Schema...

CREATE SCHEMASUB SAMPLE_SCHMEA_NEW SUBTYPE U REPLQMAP ASNUSRC_TO_ASNUTGT FOR TABLES OWNER LIKE ********OPTIONS ASNUNI ;

 

Gopalan Venkatramani

DB2 LUW

Gopalan Venkatramani

RE: Q-Replication - Tables with secondary unique index - Resolved and Closed
(in response to Gopalan Venkatramani)

I found the way to replicate the tables having secondary indexes. Just drop the unique index on the target (apply) database. Stop and start the q-replication program. Its working now :) 

I found it from pdf "Understanding and Using Q Replication for High Availability Solutions on the IBM z/OS Platform"

Page : 157


"Unique key violation retries
Section 2.3.2, “The Q Apply oldest committed transaction time for a queue” on
page 33 describes how secondary unique indexes can create unique key
violations when Q Apply attempts to update a row in the target table that contains
the same data for the (secondary) unique key columns.
The only meaningful method to avoid unique key violations is to restrain from
adding more than one unique constraint on Q Replication maintained (target)
tables. This is however not always possible, especially in bidirectional replication
where the (target) site is also the (source) site where user transactions rely on
the secondary unique indexes to enforce application logic."

 

 

 

Gopalan Venkatramani

DB2 LUW