onmode -B

[tomL]

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.

TIA,
Tom

[rkusenet]

"tomL" <schm...@yahoo.com> wrote in message news:e70357eb.03061...@posting.google.com...

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.

[Jonathan Leffler]

tomL wrote:
> 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?

The complexity of running the cron job - mainly. This technique does
not clear the buffer pool completely (as Ravi - rkusenet - implied);
it simply writes out all the dirty pages (marking them as clean). The
pages in the buffer pool do not have to be re-read to be re-used.

There is a small potential penalty; your users might modify a page
between the time when the onmode -B flushes it and the time of the
checkpoint proper; that page will be written twice in short
succession, which would not have happened without the onmode -B. On
the other hand, this minor penalty is usually more than offset by the
reduced duration of the checkpoint proper.

As Ravi also pointed out, there is a slight chance that something
weird could happen and overfill the physical log (75%) or otherwise
trigger a checkpoint. However, by setting the checkpoint interval to,
say, 10 minutes and running the cron job every 5 minutes, and by
sizing your system appropriately, you can pretty much avoid those
problems. You might have problesm if the cron job stops working - but
then the automatic systems would kick in and do checkpoints anyway,
just more slowly.

> 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.

Go with what works for you.

--
Jonathan Leffler #include <disclaimer.h>
Email: jlef...@earthlink.net, jlef...@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

[Madison Pruet]

onmode -B does not flush the pages from the buffer pool. It simply
writes dirty pages to disk. The page still remains in the buffer pool.
onmode -B is probably a much better solution to the long checkpoint
issue 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" <rkus...@sympatico.ca> wrote in message news:<bcdg1i$hjsh3$1...@ID-75254.news.dfncis.de>...

[tomL]

We now are down to 0 or 1 seconds for checkpoints....Much better.
Great advice! - It seems to work very well so we will go with it......
Thnaks again

Jonathan Leffler <jlef...@earthlink.net> wrote in message news:<3EEA8F90...@earthlink.net>...