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

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