Re: Raw device type for data files

In article 26809_at_sequent.com, krader_at_sequent.com (Kurtis D. Rader) writes:
> "Matthew M. Lih" <matt.lih_at_trw.com> writes:
>
> >I attended a seminar by Oracle on performance tuning, where they
> >said that there are few circumstances where you would want to use
> >raw devices. Apparently nowadays the speed increase over the file
> >system is 10%-15% (the figure they gave me). Weighed against the
> >difficulty of managing Oracle on raw devices, it sounded like
> >you would have to have your back against the wall before going to
> >raw devices.
>
> Piffle! (polite for b*sh*t)
>
> I've been working for one of the leading providers of database
> servers for over 5 years and have been using Oracle for 10. Assuming
> you are using a volume manager such as IBM's LVM, Sequent's SVM,
> or any of the various ports of the Veritas VxVM product almost
> every argument favors raw databases. I have a two page table
> comparing raw and cooked and the only point where cooked databases
> have an edge is in the number of backup options available.

Raw Oracle is indeed faster the Cooked Oracle. But performance is not the only thing you need to consider. Good hardware is getting cheaper and cheaper. Good Oracle people are thin on the ground. Its makes sense to optimize in favour of the cheapest resource. So what it runs 20% faster with raw devices? Big deal.If your hardware is at 80% capacity and you *need* raw devices to keep going you have other problems. If you want to *Really* speed things up stop using Oracle's referential integrity and database triggers in your applications. Stop using GUI's and go back to command line interfaces. Many of the things which slow Oracle down are there for a good reason. Developer costs beat hardware costs almost every time these days. It's not unusual to spend 100K on the machine and have five developers who cost their employer 100K *each* per year by the time you add in benefits etc.

The real long term cost of a system is related to how easy it is to maintain and work on, not how fast the underlying implementation is. Because raw devices are a pain in the ass to set up raw systems tend to squeeze too many objects into the one tablespace, which creates optimization problems. This is not a failing of raw devices - it's a reflection of the cost of using them. Cooked oracle is not as fast, but is easier to use and maintain. The current system I use has about a dozen tablespaces, ranging in size for 1MB to 880MB. It can be recreated by someone with 2 years experience in about a few hours, without needing to reconfigure a machine.

If you work in an environment where performance is everything then Kurtis is 100% right. But most people aren't in such environments. Many of us are in the cold and unglamorous world of MIS, and don't have the time to optimize to the nth degree, or have the oratorial skills to persuade our bosses that it would be worthwhile.

My 2 cents.

David Rolfe,
SunSoft,
Mountain View,
CA. Received on Thu Jul 27 1995 - 00:00:00 CEST