One of the funnier arguments for raw I heard a year ago was this (from a DBA): "I always use raw files, because it makes it highly unlikely that anybody will delete a datafile by accident, since it's so hard to get rid of raw devices." :-).
Dejam, Ruth wrote: >I had responded to Witold privately but it seems that people want more so >here goes: > >We went raw with our production billing system a few months ago >because the vendor told damagement that it would be faster. We also >converted our failover and testing environments because we do some >combination of SRDFs and BCVs of the production system (we are an HP shop). >FWIW, each of these monsters is a 2.4T OLTP database. > >Their code was crappy in a cooked database, and unbelievable as >it may seems, performs slightly less crappy in a raw database. > >We have few SAs and DBAs that have ever worked with raw devices. >Despite excellent documentation, configuring aio was *challenging*. >The lack of experience has also given us ample opportunity to practice >backups and restores. > >The good news is that our failover has worked flawlessly. :) > >The upshot is yes, we've gotten slight performance gains. Can you imagine >what would happen if we tuned the code, make a few database architectural >changes, etc? In the meantime, it was easier and faster to go raw rather >than fix the code. Add in the poor resources and you have a weiner! > >My personal opinion is that we will not realize enough gains to justify >going raw. I imagine it's only a matter of time before our business grows >enough to bring the system to a screeching halt again. By them we will have >implemented yet another version or 2 and will not be able to figure out >exactly what to do. I guess, at that time, we can go back to cooked. :) > >It was probably done for the vendor's own job security and most of our >management is totally clueless. For me personally, it's been great because >I'm one of 3 DBAs here who have worked with raw before so I have more things >to play with now. > >If you decide to go this route, make sure your SAs and DBAs are educated and >careful and get thyself some good backup software. > >You can check out past discussions about raw vs cooked at >http://www.fatcity.com/ListGuru/login.php > >hth, >~Ruth > >Ruth Dejam >Senior Oracle DBA >VoiceStream Wireless > >Do not meddle in the affairs of dragons for you are crunchy and taste good >with ketchup. > >-----Original Message----- >To: Multiple recipients of list ORACLE-L >Sent: 1/17/02 6:50 AM > >I have been searching for the same answers for a long time and have >downloaded a lot of papers on the "raw vs cooked" and to get definitive >answers is a complicated task. Simple methods and opinions and examples >will go a long way in the understanding of a controversial and >complicated subject. Yes, I know that it is faster, more complicated, a >bear to administer but the answer is "it is used today in quite a few >shops". More informative answers would be appreciated and would help in >the decision process of "should we or shouldn't we use raw devices" and >what are the pitfalls and advantages if we do. A guide ,reference, or >link to help in the decisions would be a blessing. >ROR m���m > > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Mogens =?ISO-8859-1?Q?N=F8rgaard?= INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
