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

In article <1993Aug17.171804.15624_at_exlog.com>, Lee Parsons <lparsons_at_exlog.com> wrote:

>At a large company I was at not to long ago, I had a group of individuals
>that wanted their dinky 20M of data database raw because they read someplace
>that is was GOOD.

I'd have to agree. For 20Mb, raw probably isn't worth it. The systems I'm dealing with have 2-12Gb of data.

>Not me Jack. I'm a Oracle Geek. If you think I'm going to spent 2 months
>writing a backup routing that uses a glorified copy command to backup
>production data while I'm doing my real job AND then bet my furture with
>this company that it will work, Your nuts. Go write me a routine that
>handles tape errors, does something to figure out that new datafiles
>have been added since last time, writes logfiles someplace so we can
>review them and creates labels so that in in 2 years when we have to
>recover we know which files sets to put where.

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).

>Oh and don't forget to shutdown the database.

Sorry, we aren't allowed to shutdown the database. :-)

>I'm not saying that all of the above is not possible, But that people
>somehow think they get raw for free. They often are not willing to pay
>the price to to the job correctly and get burned.

Good point. Do it right, or don't bother (you'll regret it).

>You might want to ask oracle for a paper by Cary Millsap entitled
>"Making the Decision to Use UNIX Raw Devices". Basically it sez there are
>cases where raw is the answer but there are a lot of other things to try
>first.

In our case, there are lots of other things to try _at_the_same_time_. As always, application tuning/indexing gives the most bang, followed by INIT.ORA adjustments, and raw devices somewhere behind.

>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.
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.

>Of course all this is numberless theory and should really be backedup
>with a benchmark. But that would require work and might prove me
>wrong :-}

Let's not confuse the issue with facts... ;-)

-Dave.

-- 
David Schmitt, Manager, Technical Services	Voice:	(708)538-4699
Motorola, Inc. - Land Mobile Products Sector	FAX:	(708)538-4638
1301 E. Algonquin Rd. (IL02 SH1C)		E-Mail:	cds016_at_email.mot.com
Schaumburg, IL 60196