Re: Database and RAID

Matt Reprogle <mcreprog@ictest.delcoelect.com> offerred: +We knew we were taking a risk using cooked, because the Informix +community seems very slanted toward disk farm/raw storage. Oracle seems +to embrace cooked files as equivalent to raw. Also, with cooked you +have more backup options than with raw, where you are pretty much tied +to Informix utilities. Just out of curiosity, have you ever had the occasion to restore a system from these other backup options? A few issues you should be aware of: If your "alternate" backup is performed while Informix is on-line, then the contents of that backup are most likely useless. Since the server will be writing to different locations in your cooked file during the "alternate" backup, the backup itself will contain the chunk in an inconsistent state. Part of Informix's functionality with the backup utils is handling the changed data such that the backup contents are consistent. If your "alternate" backup requires Informix to be brought down, then the fact that you are using cooked files is irrelevant. There are any number of ways of backing up the contents of a raw device if it is not being written to (dd will work, for example). Version 7.3 of IDS allows the use of external backup mechanisms. While the server can be technically "on-line" during such a backup, in fact all update activity is blocked. Effectively, you have a read-only system while the backup occurs. The theory is that some of these external backup mechanisms can be quite fast, so the read-only period is short enough to be tolerable. A potential problem with cooked files that, to my mind, is truely the most serious, is that a write() to the file does not guaratee that the data has actually been sync()ed, i.e. it may be sitting in a Unix buffer waiting to be written. Should a crash occur at that point, your data is lost. Informix took to opening all cooked deviced with the O_SYNC flag back in the 5.0 days, if I recall, but this relies on the o/s actually implementing the device driver to acknowledge the flag and act accordingly. The other issues revolve around performance; if it is good on your system, then they are no big deal (although you should be able to realize even BETTER performance with raw disk). FIrst, kaio can only be used against raw devices. Kaio is usually considerably faster than using aio vps for i/o. Second, the db server has no control over the physical location of data in a cooked device, since Unix is handling the physical allocation of space. Unix commonly uses a smaller basic i/o unit than Informix, so it is possible that the 100Kbyte extent you think of as contiguous is, in fact, made up of blocks scattered about the phsical disk. A sequential scan of that extent might not be as "smooth" as the same extent created on a raw device. Now that you've read the standard line, the fact of the matter is that a lot of this is much less of an issue with up-to-date Unix systems. The filesystems have gotten much more efficient, so fragmentation tends to be less of an issue (although I would still avoid creating my cooked files for Informix on the same disk as any regular file systems). The O_SYNC flag is pretty universally supported, so unflushed writes are pretty uncommon. Kaio is still an issue, and the multiple buffering that occurs with a Unix file (once from disk to Unix, again from Unix to Informix) does add overhead. But cooked files are not a great evil by any stretch. I prefer raw files myself - one of the reasons being that an overzealous individual, looking to "clean up" the system and remove unnecessary "large temporary files" will probably not target your raw devices as being in that category (yet another lesson in who should actually have root privs). Then again, similar-minded individuals will not decide to build a file system on your cooked device either (moral of the story? Idiots will someday rule the earth, because the rest of us will get fed up with them and move somewhere else ;-)). Dave Dave Kosenko davek@summitdata.com Director of Training Services (732) 469-4070 Summit Data Group (an Informix Authorized Education Center)