04-16-2002 11:32 PM
We have earlier installed all our Informix databases to raw devices.
Is raw device still recommended for Informix chunks on VA7400?
As you know Oracle recommends filesystem instead raw device.
04-16-2002 11:44 PM
You will find that informix recommends to use
'raw' and not filesystems.
We have informix here, and the very mention
of using cooked filesystems in front of our
DBA's is close to swearing.....
You will find that each DB vendor has their
own preference as to whether they use 'raw'
04-16-2002 11:57 PM
what Michael said is fully supported from my side with just one remark:
From what I found out and what was verified from some other INFORMIX guys you should place your TMPDBS on a filesystem and not on a raw device.
you will have perfomance improvements in case you have large sorts or things like that.
(improvements come from the file system buffer cache)
04-17-2002 12:30 AM
See the section on Raw File Support in:
04-17-2002 12:45 AM
In practical point of view , we understand that informix performs very well with raw volumes than cooked volumes.
04-17-2002 03:50 AM
Michael, Rainer, Deepak, and U.SivaKumar; I had an interesting discussion about this very topic yesterday with EMC, and we have found a trend to go exactly the other way towards "cooked" filesystems rather than raw in cases where you have disk arrays with large amounts of cache. The advantages of a raw filesystem are disappearing because the speed of disk IO and caching. Backups of a "cooked" filesystem over a raw filesystem is also a leg up.
Hell, five years ago I tried to get my DBA's to move oracle to raw filesystems, but the DBA's didn't like the idea because they couldn't "SEE" the files. To me, then, that was a very lame excuse! Maybe that's the difference between informix DBA's and Oracle DBA's, because the informix dba's are the exact opposite!
live free or die
04-17-2002 05:00 AM
Using cooked files sends the i/o through the streams interface (fseek vs. lseek, fread vs. read etc). This adds an extra function call layer to every i/o.
It also means that when informix thinks it's i/o has been safely written to a disk, it could still be in the machines buffer memory, which is dangerous should your system PANIC or TOC, if you have MCSG for instance. I wouldn't trust it to completely rollforward its transactions if that happened.
What we really need is for someone to do some tests with cooked files on VXFS using the mincache=direct mount option, to compare performance, then tell us all the results on the ITRC forums.
I tried cooked files last year using a NetApp filer. On aggregate it ran about the same speed as a single (jbod) disk, when loading large amounts of data that outgrew the filer cache memory.
I think the final call you make ultimately depends on your application.
I also spoke to a salesman of NAS/SAN products who recommended files, but it was obvious why in his case - the product wouldn't work without cooked files over NFS mounts - ugh! - stay clear of cooked files over NFS.
The other thing about informix vs. Oracle cooked file storage is that informix cannot grow the storage (chunk) file size by itself, whereas Oracle can. In informix the DBA has to add extra chunks to a dbspace/blobspace. In Oracle the DBA can increase the tablespace(=informix dbspace) manually or allow Oracle to grow it up to the limit of your filesystem.
08-01-2013 11:13 AM
If you're going to use cooked file-system, you must make sure that rootdbs, tempdbs, and dbspaces that will have high transaction volatility are on different volume groups altogether. Then you must stripe your file-system. There is no hard and fast rule for the stripe set, but if you have some time to experiment try different stripe sets to see which gives you the best performance. You have to have balance for read and write so do both these activities in your r & d. Using stripes allows you to use multiple spindles at the same time.