Re: Raw Disk Partition vs. Unix File System (Oracle 6)

When you tune a system you should have performance measures and criteria in hand and tune your system to accordingly. Tuning by blindly modifying system configuration introduces risk of degrading overall system throughput. A more cost effective approach is to identify system bottlenecks and tune those.

Before you go off and decide to do the Raw Disk thing, first identify that file I/O is a throughput limitation. The sqldba monitor facility and system level perf monitors are quite good at identifying problems like this.

Mike

In article <1993Aug18.155644.348_at_exlog.com> lparsons_at_exlog.com (Lee Parsons) writes:
> In article <1993Aug17.201454.26784_at_lmpsbbs.comm.mot.com>
 cds016_at_isadmin1.comm.mot.com (David Schmitt) writes:
> >
> >Hmmm. No matter what mechanism you use to back up your database, you
 are
> >foolish if you don't test it. Also, if I'm not willing to bet my
 future
> >that backups work, then my company has hired the wrong person (because
 they
> >_are_ betting significant money that backups do work).
>
> I don't have any problems putting my job one the line provided I 1) get
> control over how things that could get me fired are done or 2) get the
> time to do them the way the customer wants.
>
> My general concern is that there are too many shops out there who want
> their Sys Adm/DBA to whip out a set of backup routines, accounting
 scheme,
> security guidelines etc., But wont acknowledge that if they are going
> to do it right someone else should reset Joe Users password for him
> three times a day. "Oh just do this increadibly vital company function
> in your spare time."
>
> I'll acknowlege that these are cases where Managment does the wrong
> thing. But I'll also argue that cases like yours where the right thing
> is done are not as prevalent as we would like to think.
>
> And (to bring this thread back in line with the Subject line) a whole
 lot
> of people are hearing things like "GO RAW" and thinking to themselves
> "Gee a whole 15% increase in performance, for FREE"
>
> Stop and think about this guys or you are going to wake up in two years
> with 1) no more database 2) a stupid expression on you face and
> 3) a whole bunch of realatively unused backup tapes.
>
> CASE-IN-POINT: Another response to the original posting that started
> this thread stated that backups should be unaffected after going raw.
>
> >>I'm also not sure I agree with the performance improvment statement in
> >>ALL cases. Seems to me that if you are dealing with large FS
 blocksizes
> >>ie) 32K-64K, then your improvement should be if not negligable then
> >>atleast greatly reduces. Further if your dealing with SunOS and have
> >>a large amount of RAM that is used as a massive transparant buff cache
> >>then the FS could be a win. Depenting on the setup up they may beable
> >>to get near raw performance on a cooked db.
> >
> >My assumptions:
> >1) Oracle buffering overhead (& savings) are always there, raw or not.
> >2) File system buffering must add _some_ overhead.
>
> Possibly large overhead, possibly very small overhead, But yes per
> read/write always some overhead.
>
> >3) If you tune Oracle buffers correctly, you will always win over
> > Oracle buffering overhead plus file system buffering overhead.
> > Admittedly, the difference may be small, but there is still a
 difference.
>
> Still not sure about this one, If you tune the SGA correctly your
> having to tune memory for average utilization/load. But what about
> peaks in the load? At 3:00 every day you do something really ugly
> that could use a ton of Block Buffers if they where there. You
> can't make the SGA Really big all the time because that would waste
> memory most of the day. You cant shutdown/startup with new SGA
> because people are used it. So instead you let SUN/OS buffer these
> I/Os in its extended cache a feature you wouldn't get from raw.
>
> An overly specific example I know, But still for the shop that has
> this need the FS may be a win.
> --
> Regards,
>
> Lee E. Parsons Baker Hughes Inteq, Inc
> Oracle Database Administrator lparsons_at_exlog.com

--

~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Michael R. Riggs                      mriggs_at_pencom.com (Internet)
Pencom Software                                     
Austin, Tx