Possible inconsistencies in tab_name in HDR

Dear Sir/Madame, I think I should re-send this email hoping somebody would have a look and possibly give me a clue. IIUG membership no: 14433 Last name: NGUYEN email: lnguyen@ruralco.co.au Regards, Long Huy Nguyen MIS(Analyst Programmer) Ruralco Limited P.O.Box 515 Wentworthville NSW 2145 (Ph) 02 9688 8528 (Fax) 02 9896 7763 lnguyen@ruralco.com.au ----- Forwarded by Long Nguyen/HO/STAFF/MINet on 02/01/2007 11:17 AM ----- Long Nguyen To: informix-list@iiug.org 15/12/2006 09:54 cc: AM Subject: Possible inconsistencies in tab_name in HDR Dear Sir/Madame, I would like to add: "We use HDR/ER in our system". Regards, Long N. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----- Forwarded by Long Nguyen/HO/STAFF/MINet on 15/12/2006 09:54 AM ----- Long Nguyen To: informix-list@iiug.org 13/12/2006 10:50 cc: AM Subject: Possible inconsistencies in tab_name in HDR Dear Sir/Madame, I am an Informix AP and a member of the IIUG Classics forum. I have wrongly reported this HDR problem to classics@iiug.org. Arg S. Kagel has advised me to re-send it to the IDS forum (which I have not been a member of its, so please advise me how to register to the IDS forum) or its gateway email "informix-list@iiug.org". The following is the description of the problem: We use HDR in our systems. Recently we often get these messages in the DR log file: 12:17:03 Results: Possible inconsistencies in 'esser:"informix".stoshipd 12:17:03 Action: Run 'oncheck -cDI esser:"informix".stoshipd 12:17:03 stack trace for pid 6462 written to /tmp/af.42dc78e 12:17:03 See Also: /tmp/af.42dc78e 12:17:07 Page Check Error in bfput 12:17:07 invoke_alarm(): /bin/sh -c '/usr/informix-10.00.FC4/alarm.sh 5 6"Internal Subsystem failure: 'MT'" "Page Check Error in bfput" Run "oncheck ?cDI esser:stoshipd" on the DR site and get the messages: ERROR: Index i6oshipd for esser:informix.stoshipd is bad. Please check index 'esser:informix.stoshipd#i6oshipd' on DR primary server. If the index is ok on DR primary server, it does not need to be rebuilt, but can be transferred to DR secondary server by running "onmode -d index ..." command on the DR site. Every time we have to run "onmode ?d index database:tab_name#index_name" to replicate the index from the Primary site to the Secondary (DR) site. But this transfer cannot be done for tables that are heavily accessed during the day, as it will lock the access to that index during the transfer. I would much appreciate if I could receive your advice on how to solve this problem. Any long time solution is very much welcome. Truly yours, Long Huy Nguyen MIS(Analyst Programmer) Ruralco Limited P.O.Box 515 Wentworthville NSW 2145 Australia (Ph) 02 9688 8528 (Fax) 02 9896 7763 lnguyen@ruralco.com.au