Re: Raw Vs. File systems, your opinion?

Someone asked me for my opinion?

Filesystems are great for small instances, most often where performance isn't a major issue. They offer the DBA the convenience of using the available space in whatever manner the DBA desires, and, in most cases, the system admin the ability to "grow" a filesystem to accommodate additional datafiles.

In the automotive world- would you like that high-performance sports car with an automatic transmission, or a manual? Both sell.

There are many products which will allow you to bypass those nasty (value-added) characteristics that accompany the filesystem layerblock  I/O and file-system level(gasp) caching. Asynchronous I/O is a good thing that is hard to do through/past the filesystem layer. Why fsck a filesystem that has 20 files in it- and just *what* do you do when one of these has been marked bad? I'd rather Oracle take care of the internals of it's own datafile(system).

Although it *is* possible to turn caching to an advantage, if you have enough physical memory and a small enough database:-) Reads are *really* fast if you never have to go to disk!

However- with a good volume manager, and raw files, you can change the entire layout of the database on the fly, without taking down the database. You also avoid those nasty problems that occur when you've placed your control files on three different filesystems... that are all on the same physical disk (not that I've ever seen that..). Asynchronous I/O isn't something you have to fake- and writes occur when they should, rather than at the convenience of the OS.

BUT, Jared is completely correct- It does require good planning, and as Rachel alluded- a good rapport with your systems admin.

Is planning a bad thing?

In answer to the question "..should I be concerned about the type of storage the os has.." -someone needs to be. Everyone should be- otherwise you end up with control files all on the same (physical) disk- again, not that I've ever seen that. A really good layout is a combination of the characteristics of the database matched with the characteristics of storage. Teach the sysadmins how your database works, let them teach you how the storage works, and between you, you'll have a *really* good system, that will be easier to maintain and troubleshoot in the long run.

Back to the dark corners...

-jack

>
>
>
> Cooked: requires less planning
> Raw: Requires much planning
>
> Will your environment allow you to use raw?
>
> Jared
>
> On Tue, 5 Dec 2000, Ron Rogers wrote:
>
> > Jared, you were partually correct about starting something with reference to "cooked vs raw" devices. The information at the web site you listed was informative and very detailed But this still doesn't answer to question I posted on Nov 16
> > "> List,
> > > At my last interview I was asked about "cooked" and "raw" devices for the storage and the advantages/dis-advantages of each. AS a DBA should I be concerned about the type of storage the os has? Needless to say I didn't get the job offer.... Could anyo
> ne
> > direct me to the answers to the questions or explain it in layperson terms.
> > > Thanks.
> > > ROR mª¿ªm"
> >
> >
> > >>> carmichr_at_hotmail.com 12/04/00 07:02PM >>>
> > well, I'm fighting on your side in this one. I don't like using raw unless I
> > am forced to (because I'm using OPS)
> >
> >
> > >From: "Joseph S. Testa" <teci_at_oracle-dba.com>
> > >Reply-To: ORACLE-L_at_fatcity.com
> > >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> > >Subject: Re: Raw Vs. File systems, your opinion?
> > >Date: Mon, 04 Dec 2000 15:00:29 -0800
> > >
> > >let the holy war begin.
> > >
> > >joe, the anti-raw device DBA
> > >
> > >bruce.taneja_at_mcd.com wrote:
> > > >
> > > > We have been using raw devices for Oracle datafiles.. though I hear
> > >that
> > > > unix file systems
> > > > are the prefered way.. Any one has bad experiences that made them
> > >switch
> > > > one to other?
> > > > Any other opinions?
> > > >
> > > > thanks!
> > > > Bruce
> > > >
> > >--
> > >Joe Testa http://www.oracle-dba.com
> > >
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Ron Rogers
> > INET: RROGERS_at_galottery.org
> >
> > 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).
> >
>
> Jared Still
> Certified Oracle DBA and Part Time Perl Evangelist ;)
> jkstill_at_teleport.com
> jkstill_at_bcbso.com
> jkstill_at_regence.com
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: jared still
> INET: jkstill_at_teleport.com
>
> 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
Received on Tue Dec 05 2000 - 14:14:36 CST