Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: RAID Newbie question...

Re: RAID Newbie question...

From: Kevin <kcheung_at_poboxes.com>
Date: Thu, 11 Jan 2001 00:03:06 +0800
Message-ID: <3a5c87aa@newsgate.hknet.com>

I would wonder if RAID 5 can be a good candidate for read intensive applications ?
The read / write ration of our application is about 10:1 in general and we are also have our O7 DB running over several RAID5 arrays.

I tried to talk with our system admin and he said that even if you put table and index datafiles on the same array group would not cause IO bottleneck. His arguement is that RAID5 would distribute the I/O evenly among the disk group in the array.

Any comment is welcome.

Regards,
Kevin

--

"Howard J. Rogers" <howardjr_at_www.com> wrote in message
news:3a5c69db_at_news.iprimus.com.au...

> 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 - 10:03:06 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US