enterprise rep cdr repair ats fails

IBM Informix Dynamic Server Version 11.50.FC6 HP-UX wuasp132 B.11.23 U 9000/800 any er experts out there can help please Trying to repair replicate using cdr repair cdr repair ats ats.ec_ap_uat_wlg.ec_ap_uat_akl.D_3.110623_10:20:06.2 ATS or RIS file format error at line 10 near character position 10. parse input file failed command failed -- Cannot repair - ATS/RIS repair failed. (164) the file TXH Source ID:5 / Name:ec_ap_uat_akl / CommitTime:11-06-23 10:20:05 TXH Target ID:6 / Name:ec_ap_uat_wlg / ReceiveTime:11-06-23 10:20:06 TXH Number of rows processed when transaction was aborted:1 TXH One or more rows in a transaction defined with tx scope were rejected TXH CDR:14 (Error: Failed conflict resolution rule) / SQL:0 / ISAM:0 ---------- RRH Row:1 / Replicate Id: 393281 / Table: ec_accept@paqis.ec_certificate_file_output / DbOp:Insert RRS 5 (ec_ap_uat_akl)|1308781205 (11/06/23 10:20:05) RRD 11341|off_xml|<metadata> <content-type>text/xml</content-type> <suffix>xml</suffix> <compression>gzip</compression> </metadata> |<1431, BLOB, SB>|2011-06-23 10:15:25

Here's your hint: TXH CDR:14 (Error: Failed conflict resolution rule) / SQL:0 / ISAM:0 There's a conflicting change to the data that cannot be resolved. Example: the row was updated locally after the remote row was updated and before the replicated change could be applied locally. Three options that I see: 1. You will have to manually bring the local and remote versions of the row into sync 2. Use cdr sync to propagate whichever copy is master all around automatically. 3. Decide that the remote change was made moot by the local change (ie both copies are identical now anyway) and delete the ATS/RIS files. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Sun, Sep 25, 2011 at 6:50 PM, KARL OLIVER <karl.oliver@maf.govt.nz>wrote: > IBM Informix Dynamic Server Version 11.50.FC6 > HP-UX wuasp132 B.11.23 U 9000/800 > > any er experts out there can help please > Trying to repair replicate using > cdr repair > > cdr repair ats ats.ec_ap_uat_wlg.ec_ap_uat_akl.D_3.110623_10:20:06.2 > > ATS or RIS file format error at line 10 near character position 10. > parse input file failed > command failed -- Cannot repair - ATS/RIS repair failed. > (164) > > the file > > TXH Source ID:5 / Name:ec_ap_uat_akl / CommitTime:11-06-23 10:20:05 > TXH Target ID:6 / Name:ec_ap_uat_wlg / ReceiveTime:11-06-23 10:20:06 > TXH Number of rows processed when transaction was aborted:1 > TXH One or more rows in a transaction defined with tx scope were rejected > TXH CDR:14 (Error: Failed conflict resolution rule) / SQL:0 / ISAM:0 > ---------- > RRH Row:1 / Replicate Id: 393281 / Table: > ec_accept@paqis.ec_certificate_file_output / DbOp:Insert > RRS 5 (ec_ap_uat_akl)|1308781205 (11/06/23 10:20:05) > RRD 11341|off_xml|<metadata> > <content-type>text/xml</content-type> > <suffix>xml</suffix> > <compression>gzip</compression> > </metadata> > |<1431, BLOB, SB>|2011-06-23 10:15:25 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --90e6ba212485467b8504adcd1313

thanks for that info Art Using cdr check replicate repair option fixes problem. However I dont know why we are getting replication errors in the first place. In our replication pair we only ever update at one site.So i dont know why the conflict is happening.for example data is updated on A and sent to B B is never updated sending to A. The error is always on smart blob as follows TXH CDR:14 (Error: Failed conflict resolution rule) / SQL:0 / ISAM:0 When doing a onstat -g nis on ec_ap_uat_wlg (A) i get CDR connections: Id Name State Version Sent Received --------------------------------------------------------------------------- 5 ec_ap_uat_akl RUN 9 3089 1033 when doing on ec_ap_uat_akl (B) I get CDR connections: Id Name State Version Sent Received --------------------------------------------------------------------------- 6 ec_ap_uat_wlg RUN 9 1945 2182 I would have thought sent from ec_ap_uat_wlg ,3089 would have equaled received on ec_ap_uat_akl , 2182 Obviously does not work that way What command can I use to see sent on ec_ap_uat_wlg = received on ec_ap_uat_akl

Open a case with IBM, maybe it is a known problem that there is a patch for. Don't work with ER enough to have seen this (not at all yet with SmartBLOBs). Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Mon, Sep 26, 2011 at 4:58 PM, KARL OLIVER <karl.oliver@maf.govt.nz>wrote: > thanks for that info Art > Using cdr check replicate repair option fixes problem. However I dont know > why > we are getting replication errors in the first place. In our replication > pair > we only ever update at one site.So i dont know why the conflict is > happening.for example data is updated on A and sent to B > B is never updated sending to A. > The error is always on smart blob > as follows > TXH CDR:14 (Error: Failed conflict resolution rule) / SQL:0 / ISAM:0 > > When doing a onstat -g nis on ec_ap_uat_wlg (A) > i get > CDR connections: > Id Name State Version Sent Received > --------------------------------------------------------------------------- > > 5 ec_ap_uat_akl RUN 9 3089 1033 > > when doing on ec_ap_uat_akl (B) > I get > CDR connections: > Id Name State Version Sent Received > --------------------------------------------------------------------------- > > 6 ec_ap_uat_wlg RUN 9 1945 2182 > > I would have thought sent from ec_ap_uat_wlg ,3089 would have equaled > received > on ec_ap_uat_akl , 2182 > > Obviously does not work that way > What command can I use to see sent on ec_ap_uat_wlg = received on > ec_ap_uat_akl > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --485b397dd0c78fec2e04ade20f35

Karl, This was an insert operation. I suspect that the replicate is defined = with IGNORE conflict resolution rather that always apply or timestamp. I al= so suspect that the row already existed on the target server. If a row already exists, and one of the source nodes tries to perform an insert operation on that row, then you will get a conflict resolution error. M.P. |------------> | From: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| |"KARL OLIVER" <karl.oliver@maf.govt.nz> = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| |------------> | To: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| |ids@iiug.org = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| |------------> | Date: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| |09/25/2011 05:51 PM = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| |------------> | Subject: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| |enterprise rep cdr repair ats fails [25026] = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| |------------> | Sent by: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| |ids-bounces@iiug.org = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -| IBM Informix Dynamic Server Version 11.50.FC6 HP-UX wuasp132 B.11.23 U 9000/800 any er experts out there can help please Trying to repair replicate using cdr repair cdr repair ats ats.ec_ap_uat_wlg.ec_ap_uat_akl.D_3.110623_10:20:06.2 ATS or RIS file format error at line 10 near character position 10. parse input file failed command failed -- Cannot repair - ATS/RIS repair failed. (164) the file TXH Source ID:5 / Name:ec_ap_uat_akl / CommitTime:11-06-23 10:20:05 TXH Target ID:6 / Name:ec_ap_uat_wlg / ReceiveTime:11-06-23 10:20:06 TXH Number of rows processed when transaction was aborted:1 TXH One or more rows in a transaction defined with tx scope were reject= ed TXH CDR:14 (Error: Failed conflict resolution rule) / SQL:0 / ISAM:0 ---------- RRH Row:1 / Replicate Id: 393281 / Table: ec_accept@paqis.ec_certificate_file_output / DbOp:Insert RRS 5 (ec_ap_uat_akl)|1308781205 (11/06/23 10:20:05) RRD 11341|off_xml|<metadata> <content-type>text/xml</content-type> <suffix>xml</suffix> <compression>gzip</compression> </metadata> |<1431, BLOB, SB>|2011-06-23 10:15:25 ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =

Madison, th replicate is defined as follows ------------------------------ REPLICATE: ec_accept_ec_certificate_file_output STATE: Active ON:ec_ap_uat_akl CONFLICT: Timestamp FREQUENCY: immediate QUEUE SIZE: 0 PARTICIPANT: ec_accept:paqis.ec_certificate_file_output OPTIONS: transaction,ats,fullrow REPLID: 393281 / 0x60041 REPLMODE: PRIMARY ON:ec_ap_uat_akl APPLY-AS: INFORMIX ON:ec_ap_uat_akl entry from logical log at time of error is below 321018 56 BEGIN 91 8040 0 09/26/2011 16:05:06 673791 ecert 321050 48 CDR 91 0 321018 UPDCOLS 3002e2 000001000000000000 321080 280 SBLOB 91 0 321050 CREATE [11,12,10215,1264136364] 10 0x1 addr len type xid id link 321198 80 SBLOB 91 0 321080 CHALLOC (13,879,2) 0x1 3211e8 80 SBLOB 91 0 321198 EXTEND [11,12,10215,1264136364] (13,879,2) -1 321238 2080 SBLOB 91 0 3211e8 UDINSERT_LT 13,879,24,2020,10215 322274 208 SBLOB 91 0 321238 UDINSERT_LT 13,880,24,148,10215 322344 112 SBLOB 91 0 322274 HDRUPD [11,12,10215,1264136364] 0,2168 1317006306,1317 006306 323018 68 SBLOB 91 0 322344 REFCOUNT [11,12,10215,1264136364] 0x1 32305c 68 SBLOB 91 0 323018 REFCOUNT [11,12,10213,1264136363] 0x2 3230a0 64 SBLOB 91 0 32305c PDELETE [11,12,10213,1264136363] 3230e0 292 HUPBEF 91 0 3230a0 3002e2 25a05 227 323204 292 HUPAFT 91 0 3230e0 3002e2 25a05 227 323328 56 BEGCOM 91 0 323204 324018 68 SBLOB 91 0 323328 DELETE [11,12,10213] 0x1 32405c 52 SBLOB 91 0 324018 CHFREE (13,813,2) 324090 56 COMMIT 91 0 32405c 09/26/2011 16:05:06 325018 120 HUPBEF 334 0 31e0c8 30009a 105 55 325090 120 HUPAFT 334 0 325018 30009a 105 55 325108 56 COMMIT 334 0 325090 09/26/2011 16:05:06 I have logged a PMR about why we are getting the replication errors . number 04599,999,796