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: Ron Rogers 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Dejam, Ruth 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).
