Re: RAID Newbie question...

At a rough guess, I would say that read performance is faster for normal table access (which usually consists of getting a row here and a row there -the fact that the data is selected randomly means that it NOT being in large contiguous blocks is utterly irrelevant). For that same reason, there really is little performance penalty in having multiple extents for table scattered throughout a tablespace, interspersed with extents form other segments, when using no RAID at all.

Why would RAID be faster for such random access than boring old files on separate disks? -because the reads are scattered across multiple physical disks, and hence any given disk head is not traversing great swathes of the platter to retrieve the next bit of data. Instead, the other disk heads are picking up the slack.

BUT... yes, if you attempt to read large contiguous chunks of data from a table (ie, do a full table scan) multiple scattered extents can slow things down, and hence RAID would as well. I suspect the difference would not be enormous however, given the seek times we see on disks these days. However, I have no proof of that, and I await the inevitable correction!

Non-RAID response to disk failure would involve retrieving your backups from tape, restoring the relevant data files onto whatever disk(s) remain in operation, getting to the mount stage, issuing the 'alter database rename datafile 1 from 'd:\usedtobehere' to 'd:\butnowitshere', and then issuing the 'recover datafile 1' command, and await the application of archived and online redo. Recovery time is a function of how long it takes to restore the lost files from tape plus however long it takes to replay the redo. Given that you don't have to run 24x7, you could do cold backups evey night. Application of redo is therefore not going to be a major drama (though it depends on the transactional activity you're anticipating, of course).

Boring old mirroring (is that RAID 0??!) is an excellent way of protecting you against hardware failure -if one disk fails, the mirror is still available. It's a lousy way of protecting you from user error ("oops, just deleted the system datafile") or gamma ray strikes (DBWR corrupts a block during a read) -because those errors are simply mirrored across. You will need a combination of the two approaches -backups and Redo to protect against errors and User stuff-ups, some form of RAIDing (I vote for mirrors and stripes without parity) to provide rapid responses to hardware failues (and the performance benefits of striping).

If money is tight, however, the Redo (and archive) system is there to guarantee no data loss, regardless of the type of failure (with the exception of the "oops, I didn't mean to..." kind of error).

Regards
HJR <gdas_at_my-deja.com> wrote in message news:93h8ud$ap2$1_at_nnrp1.deja.com...
> Thanks to everyone for the responses, it makes sense regarding losing
> the ability to control where the data and indexes are allocated when
> using RAID 5. What still doesn't make sense is how RAID 5 can provide
> any performance benefit at all. I know there is a write penalty, but
> I've also read that read performance is faster. I guess I can't fully
> grasp how even this could be possible since I'd imagine RAID can't
> allocate contiguous blocks on disks in conjunction with the oracle
> extents.
>
> In other words if we have extents on indexes and tables etc and
> concurrent write activity happening...It seems to me the data would be
> written to the stripes in a very fragmented way. So I would imagine
> there would be some read penalty especially when performing table or
> index scans. Is that right?
>
> I agree, RAID-5 sounds like a very bad idea. However, if we don't have
> the budget to implement RAID 1 or RAID 0+1. What can we do and still
> maintain a reasonable failure recovery time? Our application is not
> mission critical. It doesn't need to be up 24/7. We can deal with
> downtime, but our threshold is about an hour at most.
>
> Is it wise to go with RAID 0 or no RAID at all and then hope that if a
> failure occurs, we can simply keep redundant drives on hand and replace
> them right away and then hope all goes well with our DB recovery from
> our hot backup onto the new drive or are there any other options that
> we have?
>
> and we are running this on NT/2000
>
> Thanks very much,
> Gavin
>
>
> In article <3a5aece2_at_news.iprimus.com.au>,
> "Howard J. Rogers" <howardjr_at_www.com> wrote:
> > The idea of separate disk files for indexes, tables, rollback
 segments and
> > so on is simply to try and keep the simultaneous i/o's that inevitably
> > occurs during normal DML separate from each other. With a RAID array,
> > yes -it looks like one disk, but of course is comprised of multiple
 physical
> > disks -so, in fact, the RAID array is separating those conflicting
 i/o's out
> > for you already.
> >
> > Hence, no -you won't need multiple RAID arrays. Effectively, you bung
> > everything onto the one array, and let the RAID hardware deal with
 the i/o
> > problem.
> >
> > That said, RAID 5 is a real big no-no when it comes to Oracle (or any
 RDBMS
> > for that matter)... because whilst the striping bit of RAID 5 is good
> > (separating out those i/os across lots of disks), the calculation of
 parity
> > bit of RAID 5 makes writes (relatively speaking) extremely slow.
 Certainly,
> > the last place you want to use RAID 5 is for the redo log sub-system,
> > because the frequent, intensive and sequential nature of the writes
 makes it
> > inappropriate, and if your redo subsystem is running slow, the entire
> > database will run slow in sympathy. There's an argument that RAID
 5'ing
> > your data files is not nearly so bad, because of the scattered nature
 and
> > relative infrequency of the writes.
> >
> > Personally, I wouldn't touch RAID 5 with a barge pole, but pure
 striping
> > without the parity (I can never remember my RAID numbers, but I think
 that's
> > RAID 0!) is excellent for performance -though, of course, there's no
> > redundancy. You will hear people talk about RAID1+0, but the
 mirroring
> > element there seems to me to be of dubious benefit, since a cock-up
 on one
> > half of the mirror is invariably reflected onto the other half in the
> > twinkling of an i/o. The Redo Log/Archive Log mechanism provides
 sufficient
> > redundancy for many situations, without the need for hardware
 mirroring. I
> > guess it all depends on your budget.
> >
> > Regards
> > HJR
> >
> > <gdas_at_my-deja.com> wrote in message news:93efdm$5h4
 $1_at_nnrp1.deja.com...
> > > Hi,
> > > I'm hoping someone can help. I've been doing alot of reading of
 RAID
> > > stripping levels and everything seems clear (but no hands-on
 experience
> > > yet).
> > >
> > > I'm still somewhat confused as to how Oracle and RAID 5 work
 together.
> > > I've read several posts on this newsgroup and even read the white
> > > papers at orapub.com, but I'm confused on one thing still.
> > >
> > > If you are running a raid 5 array, it is my understanding that all
 the
> > > disks in the array appear as one single logical disk. Is that true?
> > >
> > > If so, how does a DBA allocate his/her database on this array?
> > >
> > > I've got it fixed in my mind that I need to put data on their own
> > > physical disks, indexes on their own and temp/system/rollback on
 their
> > > own.
> > >
> > > If I have 4 physical disks, this is easy to do. But if I have a
 RAID 5
> > > array where the entire array appears as one logical disk, what do I
> > > do?
> > >
> > > Does this mean that I need 4 separate arrays? I believe you need at
> > > least 3 disks for raid 5...so this means 12 disks? Is that correct?
> > >
> > > I've read alot about when to and when not use different stripping
> > > levels. I'm asking this question from a purely academic
 perspective...
> > > Let's say for some reason that you have made the choice to implement
> > > oracle on a raid 5 array. How is it done?
> > >
> > > Thanks for any help.
> > > Gavin
> > >
> > >
> > > Sent via Deja.com
> > > http://www.deja.com/
> >
> >
>
>
> Sent via Deja.com
> http://www.deja.com/
Received on Wed Jan 10 2001 - 07:55:45 CST