RE: Very old page bug

'rk' I'm going to chip in from your original post as subsequent ones seem to muddy the waters as I understand the situation. First. The bug is 101062 and can be confirmed by using 'onstat -g ath' to get the session id of the ontape process then 'onstat -g stk <session id>' and look for arc_very_old_page occurring frequently (all the time !!) Second. The bug was identified in pre 7.31 versions, has a workaround at 7.31 UC7 but is not fixed until 9.3. The workaround is to have 'CCFLAGS 0x400000' in the onconfig file of the engine. Third. Because of the cyclic nature of timestamps once you start hitting the bug you will continue to hit it, and get worse as your database size increases, unless you can radically prune your data and reorganise to reduce the number of allocated pages. For every page that is updated by the archive process another one will become old and need to be updated on the next archive, also for every new page allocated one will become old in the next archive (perhaps not strictly true and a bit simplistic but a close rule of thumb). Fourth. Not sure about your dummy statements not being logged. Certainly in our ER situation we occasionally get records going out of sync and we use a dummy update to force ER updates to go from one machine to the other. As ER uses log snooping these updates must be logged. May be a special case with ER. Fifth. I think trying to update tables with old pages would be counter-productive as you would be trying to shoot an ever moving target which moved further the move you try to update!! (see Third above). Much better (only option) is to upgrade to a version with the fix coded. We reduced a 72 hour daily (!!!!) level 0 to 16 hours. Keith -> -----Original Message----- -> From: rkusenet [mailto:rkusenet@sympatico.ca] -> Sent: Tuesday, March 23, 2004 5:11 PM -> To: informix-list@iiug.org -> Subject: Very old page bug -> -> -> I am trying to help someone who I think is experiencing the -> very old page bug. -> I read some postings in c.d.i archives and I have 3 questions :- -> -> (a) When ontape finds that the page has really very old timestamp, it -> updates the timestamp of that page to latest timestamp. -> Shouldn't this -> be done only once (till that page becomes very old again in future). -> -> (b) I read that dummy statement update table set colmun1 = column1 is -> not logged as the engine knows that it is a dummy statement. Is this -> true? What about buffers. Does dummy update avoid flooding -> the buffer. -> -> (c) Is there a script to find out which page has really old -> timestamp. -> This way the table can be identified and update statement issued for -> only that table. -> -> thanks. -> -> -> -> -> ********************************************************************************** This message is sent in strict confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems. ********************************************************************************** sending to informix-list