Lyall,
I am not sure what you are referring to when you say "that RAID
5 is real redundant and that it uses extra disks". I have a
feeling that there may be some miscommunication here.
One can create a RAID 5 volume with a minimum of 3 disks. This
is because RAID 3/5/7 all utilize "(n+1)" disks for a degree of
stripe of "n". And you talk striping the lowest degree of
striping is 2. The level of redundancy in a RAID 5 volume is a
function of the I-O sub-system architecture and support for one
more "hot spares" that take the place of "failed disks". In
very crude terms "RAID 5 is a poor man's mirroring accmplished
via parity on stripes which are distributed across the disks in
the RAID 5 volume".
Here is an excerpt about RAID 5, from the paper I am presenting
at Oracle OpenWorld 2000 - "Implementing RAID on Oracle
Systems". The paper goes into much more detail, providing you
with configuration details, but this should provide a "primer"
to the topic.
RAID 5: This is by far one of the most common RAID
implementations today. In this level of RAID, data redundancy
is provided via parity calculations like in RAID 2, 3, 4, and 7,
but the parity is stored along with the data. Hence, the parity
is distributed across the number of drives configured in the
volume. For many environments RAID 5 is very attractive,
because it results in minimal loss of disk space to parity
values, and it provide good performance on random read
operations and light write operations.
RAID 5 caters better to Input Output Per Second (IOPS) with its
support for concurrently servicing many I-O requests. This is
because the spindles in a RAID 5 volume, work in an independent
fashion, thus providing the capability to service more small
random I-O requests. This is a significant difference when
compared to RAID 3, where the spindles spin in a synchronous
fashion, hence supporting better data-transfer rates. RAID 5
should not be implemented for write-intensive applications,
since the continuous process of reading a stripe, calculating
the new parity and writing the stripe back to disk (with the new
parity), will make writes significantly slower.
An exception to this rule that requires consideration is when
the I-O sub-system has significant amounts of “write cache” and
the additional overhead imposed by the Error Correction Control
(ECC) algorithms is measured and confirmed by analysis to be
minimal. The definition of “significant” is left to the
discretion of the reader, but in general a write cache sized in
many gigabytes can be considered significant.
On many systems, however, the performance penalty for write
operations can be expensive even with a “significant write
cache” depending on the number of writes and the size of each
write. RAID 5 is best suited to read-only applications. Like
RAID 3, it is best suited for data mart/data warehouse
applications, but it can support many application users
performing random I-O instead of bulk sequential I-O.
Hope that helps,
Gaja
- Lyall Barbour <lbarbour_at_stanford.edu> wrote:
> Raid 5 is fine if you want to be real redundant and safe with
> mirroring and
> (i think) it's cheap.... But, as all Oracle people know (and
> database
> people in general) Oracle databases are I/O bound. If you use
> raid 5 with
> all it's extra disks, then Oracle and the OS will have to
> write to all
> those extra disks. Talk about a performance problem. Read
> any book, right
> now I'm reading one about performance tuning with the Oracle
> kernel and the
> Unix kernel. One of the first thing the author talks about is
> raid. He
> doesn't spend much time on it, but he specifically states the
> differences
> about them and why they are good/bad for Oracle.
>
> HTH
>
> I don't remember the name of the book or the author at the
> moment.
> Lyall Barbour
>
> At 11:17 AM 8/17/00 -0800, you wrote:
> >I am not going to be much help in regards to your initial
> question, but I am
> >wondering what is wrong with RAID 5? I have had alot of
> success with that
> >configuration in the past. What am I missing?
> >
> >Steve McClure
> >----- Original Message -----
> >To: Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> >Sent: Thursday, August 17, 2000 11:14 AM
> >
> >
> > > Get rid of RAID 5.
> > >
> > > Lyall
> > >
> > > At 06:46 AM 8/17/00 -0800, you wrote:
> > >
> > > >I am in the process of building two DB servers - one live
> and the other
> > > >standby. We are not overly concerned with disk capacity
> - but rather
> >with
> > > >speed of access.
> > > >
> > > >Our current configuration is
> > > >
> > > >primary has 10 disks in RAID 0+1
> > > >standby has 6 disks in RAID 5
> > > >
> > > >This is to give us 5 physical devices for production - I
> think a holdover
> >of
> > > >OFA guidelines.
> > > >
> > > >What I am looking for is a bit of advice on the best
> optin for current
> > > >configurations. I can add disks to this later. I am
> also using Veritas
> >VM
> > > >and FS and so can relayout my RAID 5 to RAID 0+1 pretty
> easily as well.
> > > >Adding disks to the system is also a breaze.
> > > >
> > > >All of these disks are in one FS mounted to /u01 .. .for
> easy management
> >on
> > > >our site we elected one mount point and one very
> expandable FS.
> > > >
> > > >I am considering breaking my configuration and going with
> 8 disks in 0+1
> >for
> > > >both systems - or going with 10 and 6 but both in 0+1 - I
> don't think
> >that
> > > >RAID 5 is a good idea ever - even for a standby system,
> but there is some
> > > >pressure to have 5 physical devices and RAID 5 with 6
> gives us that
> >too...
> > > >
> > > >
> > > >Anybody out there willing to throw two cents my way?
> > > >
> > > >
> > > >thanks!
> > > >
> > > >adam
> > > >--
> > > >Author: Adam Turner
> > > > INET: ATurner_at_concretemedia.com
> > > >
> > > >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: ListGuru_at_fatcity.com (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).
> > >
> > > --
> > > Author: Lyall Barbour
> > > INET: lbarbour_at_stanford.edu
> > >
> > > 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: ListGuru_at_fatcity.com (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).
> > >
> >
> >--
> >Author: Steve McClure
> > INET: steve_at_pactr.com
> >
> >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: ListGuru_at_fatcity.com (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).
>
> --
> Author: Lyall Barbour
> INET: lbarbour_at_stanford.edu
>
> 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: ListGuru_at_fatcity.com (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).
Gaja Krishna Vaidyanatha
Director, Storage Management Products
Quest Software Inc.
Received on Fri Aug 18 2000 - 11:49:27 CDT
