There are few out of sync introduced on target on a table that is huge. There are several scenario that would help running compare on specific rowid:
1. Some rows are lost when discarding messages from queue to resolve replication problems.
2. On routine monitoring for out of sync on target table by running "show sync", a small # of out of sync are observed on certain table(s)
The table(s) affected is/are huge so running compare without options may not work as it would time out. Compare needs to be run on limited # of rows. This works in our favor as we can use the "where" clause in compare to limit the # of rows to be compared, thereby avoiding compare errors. Remember only one compare can be issued per rowid.
The following illustrates how compare will be run for repairing a specific rowid.
The *errlog.sql file taken from target /vardir/log directory shows the following out of sync:
-- session 1, 1 error --
--
-- [1] Tue Feb 7 15:07:38 2006
-- redolog seq#/offset 55274/4967832
-- redolog timestamp 581785655 (02/07/06 15:07:35)
-- original rowid AAAOPAAAeAAAXUnAAC
-- -- NOT FOUND
--
update owner.table set ......................where
rownum = 1 and .................;
The rowid mentioned in the listing is from source.
You can find out the primary key value from source based on this source rowid. The where clause you specify for compare will be used on both source and target.
The following syntax can be used to issue a compare to resolve this:
If the out of sync happened due to discarding of messages using qview, one still gets the rowid info and table names in qview output. That can be used to issue a compare with repair option similar to above compare command.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center