Re: Database and RAID

David Kosenko wrote: > Just out of curiosity, have you ever had the occasion to restore a system from these > other backup options? > Several times on the Oracle system. Not yet on Informix. > 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. > I'm fully aware that an OS-level backup requires Informix be down. > 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). Most tape devices do not like to be dd'd to. I have heard this can even damage some tape drives. > 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. Am aware of this, too. In a DSS mode, writes aren't happening, except for nightly loads and temp tables. If it fails from the load, you reload. > 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).... With current CPU and OS technology, the performance margin should be slim indeed. > 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? Don't forget that a small error in calculating an offset when creating a raw chunk can destroy another chunk. This won't happen with cooked files. That said, we did once have a sys admin remove an Oracle database file because he couldn't tell what it was. :-O > Idiots will someday rule the earth, because the rest of us will get fed up with them > and move somewhere else ;-)). Idiots and users: the bane of a DBA's existence. -- Matt Reprogle IS Engineer, Delphi Delco Electronics Systems phone:(765)451-9651 FAX: (765)451-8230 mcreprog@ictest.delcoelect.com