Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: RE: RAID or NOT to RAID?


From: Denmark Weatherburne <>
Date: Thu, 09 Aug 2001 15:59:45 -0700
Message-ID: <>

Hi DBA's:

I've been researching this issue as well. All the expert advice seems to point to using RAID 1+0 for OLTP implementations and RAID 5 for DSS (Read-Only) implementations. I also found out that you can use raw partitions on NT as well. Does anyone have experience with setting up raw partitions on NT? I still don't know how one would separate datafiles from indexfiles and REDOLogfiles under RAID implementations? Any ideas?

I agree that it boils down to the fundamental question of cost vs performance. Nevertheless, DBA's and SA's still have to be familiar with these configurations to be efficient.


Denmark Weatherburne

>From: Berj Kacherian <>
>To: " Discussion" <>
>Subject: RE: RE: RAID or NOT to RAID?
>Date: Thu, 9 Aug 2001 10:19:26 -0700
>You've got the right idea. RAID 1+0 is the best that you can use, but also
>expensive. It all comes down to the age old question of money and
>performance. Just remember, when the system is slow, management is not
>going to ask the finance guy why he did not spend more for a better layout,
>they are going to ask the dba why the db is so slow. Always ask for the
>best layout that you know. When they balk at it, make sure you document in
>an email that they are giving up performance. When the system starts
>running slow, you've got yourself covered!
>-----Original Message-----
>From: []
>Sent: Thursday, August 09, 2001 5:25 AM
>To: Discussion
>Subject: RE: RE: RAID or NOT to RAID?
>Guys I know there have been discussions about this but can someone confirm
>my understanding of the situation. Working and researching use of RAID
>Oracle it has been come clear to me that there are many views in regards to
>Oracle databases. I.E. stripe using RAID and don't worry at all about
>separating segments. Stripe using RAID but still don't put all types of
>Oracle segments (even striped) on the same physical disks. It seems to me
>that even using RAID 1+0 the optimum situation is to have enough disks to
>stripe and to also separate out redo logs, archives, data from index (at
>least). However, this can definitely become expensive. Of course, you can
>use different types of RAID but then SA balk at the complexity and is the
>bang worth the buck. If it is a highly concurrent medium sized OLTP system
>with Oracle on Sun using RAID 1+0 (Veritas) what is the best way to go.
>Also, I have tried separating redo versus all data stripped all across
>available disks and the redo write waits reported by my monitoring tool
>about the same and still high (supposedly should be about 20ms and was
>reporting at times 30-60 ms). Also, the workload I was running to test was
>a migration workload which means large batch writes and in my mind I can't
>both optimize I/O layout for both that and common random I/O of typical
>daily operations. So I would optimize for the typical daily operations -
>try to get the developer to tune the batch process - change some of the
>memory parameters for the migration process (as nothing else will be
>happening on the system) and live with any I/O constraints after that. Any
>advice - would appreciate info. from the Quest contributors the tool I have
>been using to monitor is indeed Spotlight.
>Oracle documentation is here:
>To unsubscribe: send a blank email to
>To subscribe: send a blank email to
>Visit the list archive:
>Tell yer mates about
>By using this list you agree to these

Get your FREE download of MSN Explorer at
Please see the official ORACLE-L FAQ:
Author: Denmark Weatherburne

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
To REMOVE yourself from this mailing list, send an E-Mail message
to: (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Thu Aug 09 2001 - 17:59:45 CDT

Original text of this message