Re: Raw I/O

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: mln_at_miracleas.dk

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: ListGuru_at_fatcity.com (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).