How time intensive is raid to implement and maintain? Which company(s) make
this hardware? Is it mainly in the hardware? Or do we need to write code to
implement this?
"Howard J. Rogers" <dba_at_hjrdba.com> wrote in message
news:aglk04$61j$1_at_lust.ihug.co.nz...
> There are 4 levels of RAID to consider.
>
> RAID 0 is the best for performance on both reads and writes... data is
> striped across many physical disks, so you are effectively parallelizing
> reads and writes. The degree of parallelism is effectively the number of
> physical drives you are striping across. Trouble is, as the name implies,
> RAID 0 has no actual redundancy at all: lose one hard disk, and the entire
> set it broken, and all data it loses is gone.
>
> RAID 5 is similar, in that data is striped across lots of hard disks.
> However, for each write, a piece of "parity" information is calculated
that
> allows you to work out the value of what was written on the other disks.
For
> example, if I told you that A+B = C, and on disk C you saw the value 3,
and
> on disk A you saw the value 1, you could work out that disk B must have
had
> the value 2. So, in RAID 5, whilst you've got the striping of RAID 0, you
> *do* have a high level of redundancy, because the parity information can
be
> used to "replace" the data lost when one of RAID disks decides to die.
> However, RAID 5 is NOT good for performance: rather than just stripe your
> data across multiple drives, you've got to take time out to calculate the
> parity information. Note that RAID 5's performance penalty is entirely on
> the write side of things: for reads, it's just as parallelized as RAID 0,
> and just as fast as a result. But in a write-intensive database (and most
> database involve lots of writes, though not all), the write penalty is
> sufficient to warrant avoiding RAID 5.
>
> It gets more complicated than that, because with battery-backed caches and
> all sorts of other hardware goodies which are entirely vendor-dependent,
> RAID5 can be made pretty attractive even for writes.
>
> RAID 1 is mirroring. You write your document to drive C, and it gets
> automatically written to drive D as well. There's no performance gain here
> at all... purely data redundancy. If Drive C bites the dust, your document
> is safe and sound on drive D.
>
> So they're the three main forms of RAID, and you might reasonably wonder
> what the fourth is I mentioned at the start. Well, it's just RAID 1+0,
> mirroring AND striping. You have five mirror sets, A, B, C, D and E, each
> comprising (say) 2 disks. A1 is mirrored with A2, B1 with B2 and so on:
>
> A1 B1 C1 D1 E1
> A2 B2 C2 D2 E2
>
> You write 100K of data: 20K gets written to A1, and mirrored to A2;
another
> 20K is written to B1, mirrored to B2 and so on. Notice there are no
> cross-letter dependencies: I mean, that A is not dependent on B, nor B on
C.
> You of course need to be able to read *something* from all 5 arrays if you
> want your 100K back, but whether you read from A1 or A2, it makes no
> difference -you've read something from the A array. Therefore, if disk C1
> blows up, you just replace it, and resilver it from C2. Meanwhile, A2, B2,
> C2, D2, and E2 have all been readable, and you've also been able to read
> from A1, B1, D1 and E1. Most of the entire array is therefore still
useable.
>
> So, if it were me, and the money someone else's I'd go for RAID 1+0 every
> time. Unfortunately, 1+0 is the most expensive option, because it requires
a
> large number of disks -the number for the stripe times at least two
> (depending on how many mirrors you want). As a reasonable compromise, RAID
5
> is a good bet, provided it is a *good* implementation of RAID 5 (things
like
> those battery backed caches) which minimise the write penalty. But it *is*
a
> compromise. Hold out for 1+0 if you aren't writing the checks.
>
> Incidentally, you can also do RAID 0+1 -stripe then mirror. Your data is
> striped across A1, A2, A3, A4, A5. The whole lot then gets mirrored to B1,
> B2, B3, B4 and B5. That sounds rather like 1+0, but it isn't: if disk A2
> dies, then the entire A-array is dead, and of no use to anyone. Your
> database would be relying entirely on the B array -and one more failure
> there would mean no database.
>
> Hope that helps
> Regards
> HJR
>
>
> "JohnWood" <jwood_at_microsoft.com> wrote in message
> news:KDrX8.6566$kt5.247951_at_news1.telusplanet.net...
> > I need to get some advice here about what RAID to use for Oracle 9i
> > database. I am a novice Oracle user.
> > I am building a database for about 600G. I am planning to use 2 logical
> > drives, one for storing files for data tablespace and one for index
> > tablespace. I am confused what to use for each logical drive. Should I
> use
> > RAID 1 or RAID 5 for the logical drive ?
> > I was told I should use RAID 1 for Database as it will have better
> > performance and redundancy even though it takes more physical drives to
> > form. But when I read books, it said the RAID 5 will have better
> > performance as the data will spread across different physical drives.
> > Please advise or point me to some site that I can find answer in a
> practical
> > sense.
> > Thanks.
> >
> >
>
>
Received on Fri Jul 12 2002 - 04:01:36 CDT
