cdr check repair holding locks too long

Gentlemen, IDS 10.00.FC8, Master Solaris , Target LINUX I have a replica running REPLICATE TABLE SELECT ---------------------------------------------------------------------------- pavail_tag_tbl res0@g_crsprod:informix.tag_tbl select * from tag_tbl pavail_tag_tbl pavail@g_availdb01:informix.tag_tbl select * from tag_tbl pavail_tag_tbl pavail@g_availdb02:informix.tag_tbl select * from tag_tbl pavail_tag_tbl pavail@g_availdb04:informix.tag_tbl select * from tag_tbl pavail_tag_tbl pavail@g_availdb05:informix.tag_tbl select * from tag_tbl I was checking that data was in sync on a unidirectional replica using the command Server g_availdb05 was recently added and populated, then I just wanted to be sure tabla on that server was sync'ed. So this command was ran cdr check repl -R -m g_crsprod -r pavail_tag_tbl g_availdb05 After about 2.5 Hs (table is pretty big), ReplayID stopped moving and cdr hold a lock on a record. I killed the process after 40 minutes to free it. My question is. Is this intended behavior?, Does anyone know the internals of this command? Could the activity on the target cause this lock being hold? I cant find any doc on how this work. Thanks Walter

It could. In order to compare the rows, we have to read the rows. If there are u= ser threads blocking the scan, then that could cause problems with the scan= . We've done a lot of work on 'cdr check' in 10xC9 to address issues like= this. ------------------------------------- Madison Pruet, STSM IDS Replication Architect = "Walter Milan" = <Walter.Milan@hil = ton.com> = To Sent by: ids@iiug.org = ids-bounces@iiug. = cc org = Subj= ect cdr check repair holding locks t= oo 02/25/2009 11:50 long [15028] = AM = = = Please respond to = ids@iiug.org = = = Gentlemen, IDS 10.00.FC8, Master Solaris , Target LINUX I have a replica running REPLICATE TABLE SELECT -----------------------------------------------------------------------= ----- pavail_tag_tbl res0@g_crsprod:informix.tag_tbl select * from tag_tbl pavail_tag_tbl pavail@g_availdb01:informix.tag_tbl select * from tag_tb= l pavail_tag_tbl pavail@g_availdb02:informix.tag_tbl select * from tag_tb= l pavail_tag_tbl pavail@g_availdb04:informix.tag_tbl select * from tag_tb= l pavail_tag_tbl pavail@g_availdb05:informix.tag_tbl select * from tag_tb= l I was checking that data was in sync on a unidirectional replica using = the command Server g_availdb05 was recently added and populated, then I just wanted= to be sure tabla on that server was sync'ed. So this command was ran cdr check repl -R -m g_crsprod -r pavail_tag_tbl g_availdb05 After about 2.5 Hs (table is pretty big), ReplayID stopped moving and c= dr hold a lock on a record. I killed the process after 40 minutes to free it. My question is. Is this intended behavior?, Does anyone know the intern= als of this command? Could the activity on the target cause this lock being ho= ld? I cant find any doc on how this work. Thanks Walter ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =