Apply program with ASN1051W in its log

转自:http://www-01.ibm.com/support/docview.wss?uid=swg21404030

Technote (troubleshooting)

Problem(Abstract)

What should I do if I see the ASN1051W message in the Apply log in SQL replication?

Symptom

ASN1051W APPLY "APP" : "WorkerThread" : The Apply program detected a gap in changed data between the source table "DB2ADMIN.TAB" and 
the target table. The error code is "4A5102"

Cause

If the Capture program was started with startmode=cold, then this message is normal and can be ignored. It indicates that a full refresh of target tables was initiated. Otherwise, Capture performed retention limit pruning of a CD or UOW table because of inactive subscription sets

Environment

With DB2 V8.2, the message is ASN1051E; the message is ASN1051W with DB2 V9 or higher

Diagnosing the problem

Some hints include:

Deadlocks in Capture log
For example, on DB2 V8.2 you might see a message like this:

<CWorkerMain> ASN8999D "Capture" : "ASN" : "WorkerThread" : deadlock from updateCDSynchpoint.

On DB2 V9 or higher, you might see messages like these:

<pruneCDNormalRetention> ASN0542E "Capture" : "ASN" : "PruneThread" : The maximum number of lock time-out or deadlock retries has been reached.
<pruneCDUOWRetention> ASN0589I "Capture" : "ASN" : "PruneThread" The program received an unexpected return code "915" from routine "pruneCDNormalRetention".
<pruneCDNormalRetention> ASN8016D "Capture" : "ASN" : "PruneThread" : The program encountered a lock time-out or a deadlock.

 There are one or more SYNCHTIME values in the IBMSNAP_PRUNE_SET table that are more than 7 days old (retention_limit).


Resolving the problem

Inactive subscription sets cause the replication programs to initiate retention limit pruning. During retention limit pruning, the Capture program checks for those records in the CD table whose age is greater than the RETENTION_LIMIT value specified in the IBMSNAP_CAPPARMS table. The Capture program then removes these old records from the CD tables and UOW table.


While normal pruning removes rows that have been copied by the Apply program, retention limit pruning
removes even those rows that have not been copied by the Apply program but have been retained longer than the retention period. When this happens, gaps occur between source and target tables. Full refresh is needed to get data back into synch.

In addition, retention limit pruning is done in one unit of work, while regular pruning commits after every 500 rows. In other words, retention limit pruning can cause deadlocks.

Here are some recommendations to resolve the problem:
    Remove old subscription sets.
    Activate the inactive subscription sets (full refresh will be necessary because retention limit pruning occurred).
    If you do not want to or cannot delete the subscription sets yet, deactivate them by doing something like this for each set:

Update asn.ibmsnap_subs_set set activate=0 where set_name = 'SET1';
Update asn.IBMSNAP_PRUNE_SET SET SYNCHPOINT= x'00000000000000000000', Synchtime= NULL where SET_NAME= 'SET1' and apply_qual= 'APP1' and  target_server = 'TARGETDB';
Update asn.IBMSNAP_PRUNCNTL SET SYNCHPOINT= NULL , Synchtime= NULL where SET_NAME= 'SET1' and apply_qual= 'APP1' and target_server = 'TARGETDB';