Re: Raw Devices: Increased Performance?

From: Kurtis D. Rader <krader_at_crg8.sequent.com>
Date: 1996/06/27
Message-ID: <4quudo$eje_at_scel.sequent.com>#1/1


This makes me think of the favorite TLA of the sales force:

   FUD: Fear, Uncertainty, and Doubt

joelga_at_rossinc.com (Joel Garry) writes:

>There was a thread on this a while ago, with some folks claiming minimal
>increase, while others claimed up to 300%.
 

>Personally, I think the one time that someone unthinkingly writes over
>the raw system will more than make up for any increase. In other words,
>it requires greater control over administration than any place can be
>expected to have over a long period of time.

This is true only for raw disk partitions. If you are using a logical volume manager (ala Veritas VxVm or ptx/SVM) then the risk of overwriting your raw database is no greater than overwriting a cooked database file. And in fact I have never taken a call from a customer who has accidentally destroyed his raw database. Yet I have taken four calls (that I can remember) in the past six years from customers who have accidentally blown away their cooked database. For that matter, I ran both raw and cooked databases back when I was a sysadmin/DBA and never had a problem with either.

This is something I have studied extensively in my role designing system architectures for some of the largest Oracle sites in the world. Performance is actually pretty low on my list of reasons for favoring raw over cooked databases. A matrix I use when discussing this with clients shows the number of factors in favor of raw outweighing the number favoring cooked. That des not mean I always choose a raw implementation. It simply means that you shouldn't let FUD (see the start of the post) drive a decision.

-- 
Kurtis D. Rader, Senior Consultant           krader_at_sequent.com (email)
Sequent Computer Systems             +1 503/578-3714 (voice)  +65 223-5116 (fax)
80 Robinson Road, #18-03                   Currently on assignment in the
Singapore, 0106                                 Asia-Pacific region
Received on Thu Jun 27 1996 - 00:00:00 CEST

Original text of this message