Raw vs Cooked space?

Can anybody point me to any factual information about the benefits/drawbacks of using raw vs cooked spaces. Cooked space is much easier to do backups on, since I dont have to do an informix backup. It seems to me that it is easier to use cooked space. I know that there are speed benefits to using raw space, but what are the concrete numbers? Am I going to get 100% performance improvement by using raw space? or is it going to be 10%? I am trying to do a cost/benefit analysis on this but I can't seem to find any information about it anywhere. Any info will be greatly appreciated. Paul Jazwierski, DBA

Paul Jazwierski wrote in message <38907BF8.72728574@earthlink.net>... >Can anybody point me to any factual information about the >benefits/drawbacks of using raw vs cooked spaces. Cooked space is much >easier to do backups on, since I dont have to do an informix backup. This is a false assumption. You cannot do online backups via UNIX, because each database page is backed up at a different time, and some modified pages may in any case be cached. Even if you shut the server pages may still be cached. So you must do Informix backups - anything else is just pants. > It seems to me that it is easier to use cooked space. It is probably easier to administer. > I know that there are speed benefits to using raw space, but what are the concrete numbers? Yes indeed. If course, the benefits vary depending upon your hardware, application, usage etc, but I don't think I've ever seeem anyone claim that raw disk was slower. > Am going to get 100% performance improvement by using raw space Who knows? But 15% seems reasonable. > .. cost/benefit Minimal cost, incalcuable benefit!

Hi Paul Basically RAW devices (i.e. character block devices) are much faster, and more robust than filesystem cooked files. There are town main reasons: 1. I/O to a Raw device bypasses the kernel IO filesystem layer within the Unix Kernel (which is an all things to all people I/O handler). Therefore faster. For example time copying a 500mb file from a filesystem on one disk to another disk using cp or cat, then time copying a 500mb raw partition to another using cp or cat (e.g. cat /dev/ru2 >/dev/ru3). You will experience a difference of between 30% and 100% depending on your disk subsystem. 2. I/O to a raw device bypasses the Unix FS I/O Cache (i.e. asyncronious i/o) therefore allowing the database engine control exactly which page writes will and wont be cached in the informix buffer pool. I/O to tables is always buffered, I/O to the logical transaction logs is also buffered until a transaction is commited. The server can be sure that unbuffered writes (i.e. commit operation) are truly physically written to the disk surface exactly when the server says so. With cooked files, some unix kernels will buffer all I/O thru its own cache (which has already been cached by the server) thenfore giving the db server the false impression that critical pages have been physically written to disk when they are still in the Unix FS I/O cache. YOU MUST BACKUP INFORMIX USING ONTAPE OR ONBAR. You cannot rely on Unix backups (TAR or CPIO) of Cooked files because they are NOT point in time backups. See Art's message. Some people think that 'dbexport' can be used as a backup tool also. This is rubbish unless the server is not receiving transactions. It's very very unrelyable!!!! Cooked files are very useful for development test platforms and for training purposes but not for live production systems. Cooked files can also be used in extreme emergenies when a DBSPACE is about to fill and there is no more raw spaces, or unused unix partitions available, but there is free space within a mounted filesystem. In such cases an additional chunk made up of a cooked file can be added to a dbspace to keep the show on the road. In this case it's just a short term 'life boat'. As soon as the crises is over replace the cooked space with raw space ASAP. It amazes me how many oracle sites also use Cooked files because the implementors simple don't know any better. RAW I/O is one of the reasons Informix on Unix (SCO or Linux) on an PC Server platform kills Informix on NT (NT does not support Raw I/O). I understand the there is an secret NTFS API used by Micropsoft for SQL-Server 7 which performs better that standard I/O to an NTFS partition (i.e. a semi-raw I/O facility that microsoft won't share with the compedition - Informix, Oracle etc). Hope this helps NOEL GRIFFIN Ireland Paul Jazwierski <uszko@earthlink.net> wrote in message news:38907BF8.72728574@earthlink.net... > Can anybody point me to any factual information about the > benefits/drawbacks of using raw vs cooked spaces. Cooked space is much > easier to do backups on, since I dont have to do an informix backup. It > seems to me that it is easier to use cooked space. I know that there are > speed benefits to using raw space, but what are the concrete numbers? Am > I going to get 100% performance improvement by using raw space? or is it > going to be 10%? I am trying to do a cost/benefit analysis on this but I > can't seem to find any information about it anywhere. > > Any info will be greatly appreciated. > > Paul Jazwierski, DBA >

Noel Griffin wrote: Just a couple of comments, Noel: > Hi Paul > > Basically RAW devices (i.e. character block devices) are much faster, and > more robust than filesystem cooked files. There are town main reasons: > > 1. I/O to a Raw device bypasses the kernel IO filesystem layer within the > Unix Kernel (which is an all things to all people I/O handler). Therefore True also of using COOKED device files -versus- a COOKED filesystem file. > [SNIP] > 2. I/O to a raw device bypasses the Unix FS I/O Cache (i.e. asyncronious > i/o) therefore allowing the database engine control exactly which page > writes will and wont be cached in the informix buffer pool. I/O to tables > is always buffered, I/O to the logical transaction logs is also buffered > until a transaction is commited. The server can be sure that unbuffered > writes (i.e. commit operation) are truly physically written to the disk > surface exactly when the server says so. With cooked files, some unix > kernels will buffer all I/O thru its own cache (which has already been > cached by the server) thenfore giving the db server the false impression > that critical pages have been physically written to disk when they are still > in the Unix FS I/O cache. [SNIP] Informix opens COOKED devices and files in O_SYNC mode which guarantees that the OS buffer is immediately flushed to disk BEFORE the write system call returns. Informix has ALWAYS done this so using COOKED devices and files IS SAFE, it is just dog slow. Art S. Kagel

Neil Truby wrote: > > Paul Jazwierski wrote in message <38907BF8.72728574@earthlink.net>... > >Can anybody point me to any factual information about the > >benefits/drawbacks of using raw vs cooked spaces. Cooked space is much > >easier to do backups on, since I dont have to do an informix backup. > > This is a false assumption. You cannot do online backups via UNIX, because > each database page is backed up at a different time, and some modified pages > may in any case be cached. Even if you shut the server pages may still be > cached. So you must do Informix backups - anything else is just pants. > Actually, Informix (v 7.3 and beyond, I think) does provide for something called an EXTERNAL backup (I think this was in response to an interesting EMC feature that was, I'm further thinking, in response to Oracle's miserable backup facilities). Basically, one uses the "onmode -c block" command to force a checkpoint and block any further transactions. One follows this with Unix (or NT) commands to backup your dbspaces - these could be raw or cooked. EMC can do this in seconds with Timefinder and BDFs, if their Sales Reps are to be believed. Finally, you unblock your database using the "onmode -c unblock" command. I've never used it, but it could be interesting in Terabyte situations. BTW, one can get fuller details in the "fine" (yes, I agree, Jim!) manual - "Backup and Restore Guide". Rudy