Re: Raw is SUPPERIOR

Lots of food for thought here were to start... Well first I completely agree with you that raw space is more secure for transactions. However Decision Support is not concerned with transactions unless it resides on the same box (in our case we do not have transaction processing on the boxes we use for decision support and the data is loaded on a monthly basis). As far as files systems go Journaled File Systems (JFS) is reasonably secure in that changes are logged so recovery is simplified. I know theoretically this is a duplication of effort but if it works better do we care? Now for the question of block versus character style I/O. Your point about character devices and reading too much data may be theoretically correct but from the test I did in Sybase and Oracle I saw between a 24% and 97% increase in read performance using identically tuned systems but switching from Raw to Cooked ( on a side note I do not think saying that these databases are tuned for raw will wash because they both beat informix by margins of 11-87% raw or otherwise). None of the tuning guides stated that the configuration should be radically altered if I used raw or cooked I/O. Informix uses a Read Ahead parameter measured in PAGES so the example you use of only reading 150 bytes out of a 4k page is confusing to me. I can't see how any of the databases are using this feature of characters devices (even though you point them to it in the configuration). On the issue of the block size and the database read size mismatch Informix, Sybase and Oracle allow you to tune the block size to match the block size used on I/O. In fact they all recommend that you synchronize these values and put this step in the setup procedures. Tuning the database blocksize to the hardware size should negate the impedance mismatch you were concerned about. If you use Asynchronous I/O both Sybase and Oracle tell you to use the block device. In fact both databases strongly urge the use of asynchronous I/O when using raw devices because It reduces the overhead of having multiple DBwriters and the blocking of the character device that essential serializes writes. In our case we choose not to used asynchronous I/O because it only aided database write performance while disabling the disk controller caching. Finally, How did I come to the conclusion that cooked was better for our installation? Well the benchmarks told me that and since we can live on the edge of TP security I don't see the drawback as being severe. HOWEVER I would not recommend this without careful consideration and a DBA with a clue on site. What we are going to do on this box could not be considered a standard situation and our solution is not standard. In fact for the vast majority of DBA's this is a very risky move. But we are a decision support shop, transaction processing represent less than 2% of all system activity on all of our boxes. Our uniqueness has forced us to reject the standard notions of how a database ought to setup and find our own way. De-normalization is also extensively used in our search for better performance gains (which is often viewed as the forbidden fruit in the DBA garden of eden). >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.