Re: onmode -B

onmode -B does not flush the pages from the buffer pool. It simplywrites dirty pages to disk. The page still remains in the buffer pool. onmode -B is probably a much better solution to the long checkpointissue than using very low LRU values because it uses chunk writes rather than LRU writes. The engine uses two basic approches to writing dirty pages to disk. The chunk writes that are used during the checkpoint (and onmode -B) are sorted and organized arround the physical chunk. Because of this, they are are rather efficient -- sort of like using scatter-gather IO. The LRU writes are not organized and thus not nearly as efficient. "rkusenet" <rkusenet@sympatico.ca> wrote in message news:<bcdg1i$hjsh3$1@ID-75254.news.dfncis.de>... > "tomL" <schmotom@yahoo.com> wrote in message news:e70357eb.0306131324.46d4e8b8@posting.google.com... > > greetings! > > apparently, onmode -B is an undocumented feature that many people use. > > > > We are running informix 9.21 HC5-1 on UNIX-HP ver 11.00 and have > > employed the contorted method of running a cron job that fires onmode > > -B, sleeps for 2, then runs onmode -c. It has taken our long & painful > > checkpoints that use to last anywhere from 20-132 seconds (!) and > > dropped checkpoints to 1 second - a remarkable improvement. What I > > would like to know is if anyone know if there is a price to pay for > > doing this? > > > > We currently have a case in Informix support and have not heard > > anything back yet so we are going with this "solution" for now because > > it is really needed. > > I think your approach is incorrect. By clearing buffer every 2 min, > u are losing the benefit of buffer read. What you should do is to automatically > do onmode -B some 15-20 seconds before checkpoint. However the question is, > how do we know when was the last checkpoint. Except for online log file, > Informix does not record anywhere when the checkpoint occured. So u may have > to write a perl program to parse the onling log file and note the last checkpoint > time and add CKPTINTVL to it to know accurately when is the next scheduled > checkpoint. Just 15-20 seconds before the next scheduled checkpoint, it should > fire onmode -B. Pls note that this will fail when there is a forced checkpoint > due to 75% of physical log full or any other special event.