Re: Informix (raw or cooked)? -Reply Raw is SUPPERIOR

PMEAD@HANYS.ORG wrote: >Malcolm Weallans states: >>As Ian Goddard, a sef-confessed UNIX and INFORMIX GURU, something >>I would never admit to being, has stated, the COOKED option is really >>only there for testing and emergency use. The impact of using >>COOKED is slower performance, problems with recovery if UNIX >>crashes, and the fact that although the coked files are backed up by >>standard UNIX back-up regimes they cannot effectively be used. >This may be true for informix but it is not true in general. Some systems >using Journaled File Systems (notably HP) have much better >performance using cooked files. Again this also depends on the type of >transaction. JFS excels in serial read and write transaction. But you do >have more potential problems as you have stated. >In fact I having just completed a side by side decision support benchmark >using Sybase Oracle and Informix and I can state that using JFS with >Sybase resulted in a significant increase in load and query performance. >Your generalization about cooked files being slower is not true, and >different installations should consider all the options because some >lesser options may be better given unique circumstances. Don't throw >out the baby with the bath water. >Phil Mead >Healthcare Association of New York State I have to completely disagree with this follow up. It is the nature all the various file systems to perform block style I/O. This block size is predetermined by the hardware and does not always work hand in hand with the software. For example. When interfacing with the JFS, and performing small record reads there is quite a bit of overhead in the actual reading of the data. When you open the file and instruct it to read some record from a table (via a cursor or select) that has a column length of 150 bytes, you will not be reading 150 bytes. You will read a full page. This is true because the device the mount points are sitting on are block style devices not character style devices. If any particular DB vendor fails to gain significant improvements it is because it was not tuned to take advantage of the character style I/O interface. Completely throwing the performance argument out the window, I can't imagine how any company would want to run under cooked files when the integrity is completely shot to hell! As we all know it is the nature of UNIX in general to write data to shared caching buffers for file system updates, unless your maching is in a continuous "sync" you will never be assured that the logs, data spaces, or anything has the most recent changes to the data. I would love to continue this discussion with you and find out how you came to the conclusion that cooked files were a better fit for your environment. I have only heard this from one of the other DB vendors and that was ORACLE, which didn;t surprise me. look forward to hearing from ya. (entrican@exo.com)