Re: Writing to disk or server cache?

Andris wrote: > IDS 9.21 on HP-UX 11, raw devices. Time to get an upgrade - 9.40 please. > Another thoughts about checkpoint time. During checkpoint IDS does not > write data to server cache memory, but tries to write directly to disk > array. Yet, writing to memory can be done more quickly. > > Is it possible to make Informix to use cached disk write during > checkpoint? For example by moving tablespaces from raw devices to file > systems storage or is there other way to force this? If cached write > is possible how it can impact Informix server reliability, any ideas > about that? The main point of having a checkpoint is that it gives the server a reference point at which it knows that all the data on disk was coherent with what it had in memory. Fuzzy checkpoints somewhat modify this, but the general concept remains valid - the checkpoint gives the database server a reference point where the data on disk is in a known state relative to the data in memory. If you do the cached writes as you suggest, what guarantees are there that the cached data will be preserved if the machine crashes? If they are rock solid, then you can probably use the mechanism - it may not be supported, but it will probably work. OTOH, if your caching mechanism does not guarantee that what was written to cache will be returned regardless of inopportune crashes, then you are subverting the entire system. This might not be a total disaster - you can always recover from your last archive and your backed up logs. However, most people find that possibility more serious than the loss of performance at the check point. It is much better to do your utmost to minimize the duration of the checkpoint, and there is much you can do. Hunt 'onmode -B' in Google over the last couple of years, for example. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Hello. Thanks, onmode -B indeed seems to be the solution for long checkpoints, have to test it on IDS 9.21 yet. Anyway, another question remains - how to force IDS to use or not to use cache memory? Andris Jonathan Leffler <jleffler@earthlink.net> wrote in message news:<PN1wc.1541$uX2.805@newsread2.news.pas.earthlink.net>... > Andris wrote: > > IDS 9.21 on HP-UX 11, raw devices. > > Time to get an upgrade - 9.40 please. > > > Another thoughts about checkpoint time. During checkpoint IDS does not > > write data to server cache memory, but tries to write directly to disk > > array. Yet, writing to memory can be done more quickly. > > > > Is it possible to make Informix to use cached disk write during > > checkpoint? For example by moving tablespaces from raw devices to file > > systems storage or is there other way to force this? If cached write > > is possible how it can impact Informix server reliability, any ideas > > about that? > > The main point of having a checkpoint is that it gives the server a > reference point at which it knows that all the data on disk was > coherent with what it had in memory. Fuzzy checkpoints somewhat > modify this, but the general concept remains valid - the checkpoint > gives the database server a reference point where the data on disk is > in a known state relative to the data in memory. > > If you do the cached writes as you suggest, what guarantees are there > that the cached data will be preserved if the machine crashes? If > they are rock solid, then you can probably use the mechanism - it may > not be supported, but it will probably work. OTOH, if your caching > mechanism does not guarantee that what was written to cache will be > returned regardless of inopportune crashes, then you are subverting > the entire system. > > This might not be a total disaster - you can always recover from your > last archive and your backed up logs. However, most people find that > possibility more serious than the loss of performance at the check > point. It is much better to do your utmost to minimize the duration > of the checkpoint, and there is much you can do. Hunt 'onmode -B' in > Google over the last couple of years, for example.

Andris wrote: > Thanks, onmode -B indeed seems to be the solution for long > checkpoints, have to test it on IDS 9.21 yet. > > Anyway, another question remains - how to force IDS to use or not to > use cache memory? What do you mean by cache memory? Informix's shared memory? The disk system cache memory? Something else? Presumably the disk...you can't directly force Informix to use it, but if the devices you give IDS to play with are cached, then, of necessity and in total ignorance, Informix will use the cache on the disk. You can't directly force Informix not to use it. Depending on the disk system, you may be able to tell Informix to use a device which isn't cached, in which case it will, of necessity and in total ignorance, ignore the cache. > Jonathan Leffler <jleffler@earthlink.net> wrote: >>Andris wrote: >> >>>IDS 9.21 on HP-UX 11, raw devices. >> >>Time to get an upgrade - 9.40 please. >> >> >>>Another thoughts about checkpoint time. During checkpoint IDS does not >>>write data to server cache memory, but tries to write directly to disk >>>array. Yet, writing to memory can be done more quickly. >>> >>>Is it possible to make Informix to use cached disk write during >>>checkpoint? For example by moving tablespaces from raw devices to file >>>systems storage or is there other way to force this? If cached write >>>is possible how it can impact Informix server reliability, any ideas >>>about that? >> >>The main point of having a checkpoint is that it gives the server a >>reference point at which it knows that all the data on disk was >>coherent with what it had in memory. Fuzzy checkpoints somewhat >>modify this, but the general concept remains valid - the checkpoint >>gives the database server a reference point where the data on disk is >>in a known state relative to the data in memory. >> >>If you do the cached writes as you suggest, what guarantees are there >>that the cached data will be preserved if the machine crashes? If >>they are rock solid, then you can probably use the mechanism - it may >>not be supported, but it will probably work. OTOH, if your caching >>mechanism does not guarantee that what was written to cache will be >>returned regardless of inopportune crashes, then you are subverting >>the entire system. >> >>This might not be a total disaster - you can always recover from your >>last archive and your backed up logs. However, most people find that >>possibility more serious than the loss of performance at the check >>point. It is much better to do your utmost to minimize the duration >>of the checkpoint, and there is much you can do. Hunt 'onmode -B' in >>Google over the last couple of years, for example. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/