Its like one of the most common arguments against raw.
"Don't use raw since a sysadmin might mistakenly
create a file system over the top of it"...
... I've always thought thats an argument against
having a shoddy sysadmin rather than not using raw :-)
- Mogens Nørgaard <mln_at_miracleas.dk> wrote: > 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).
Connor McDonald
http://www.oracledba.co.uk (mirrored at
http://www.oradba.freeserve.co.uk)
"Some days you're the pigeon, some days you're the statue"
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: =?iso-8859-1?q?Connor=20McDonald?=
INET: hamcdc_at_yahoo.co.uk
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).
Received on Mon Jan 21 2002 - 15:37:39 CST
