RAID: Advantage or disaster? 
Author Message
 RAID: Advantage or disaster?

What do people think about the use of RAID for an IDS database these days?
Better, worse, or about the same on balance as JABOD? Any RAID levels to
prefer / avoid?

A client of mine is running RAID 5 on Compaq, and is getting 100% disk i/o
and frequent crashes. I haven't been able to look closely enough to
establish whether it's the RAID 5 that's causing this, but anyway they're
moving to a bigger box and planning to go RAID 5 again.

Conventional wisdom and past experience tells me this would be a disaster.
Has the technology moved on so as to tip the scales?

--
-Andy Kent-
Bristol, England

Remove '.DontSpamMe' from return address to respond.



Sun, 23 May 2004 18:51:24 GMT
 RAID: Advantage or disaster?

Quote:

>What do people think about the use of RAID for an IDS database these days?
>Better, worse, or about the same on balance as JABOD? Any RAID levels to
>prefer / avoid?

>A client of mine is running RAID 5 on Compaq, and is getting 100% disk i/o
>and frequent crashes. I haven't been able to look closely enough to
>establish whether it's the RAID 5 that's causing this, but anyway they're
>moving to a bigger box and planning to go RAID 5 again.

>Conventional wisdom and past experience tells me this would be a disaster.
>Has the technology moved on so as to tip the scales?

What are you trying to achieve with RAID - I/O bandwidth, reliability,
or both?

If you need the I/O bandwidth then you really can't avoid RAID. If you
need the reliability, likewise.

RAID 1+0 is wonderful, and solves most of your problems, but is expensive.

RAID 0 reduces the disk reliability but is great for performance.
Don't use it unless you're willing to assume the risk.

RAID 5 is OK in its place. Traditionally it's been considered to be very
poor for write performance but good for read, however I've recently seen
very impressive results with striped RAID-5 sets (RAID 5+0 ?) behind
a very large RAM cache (16 GB). I still wouldn't recommend it for redo
logs though.

--
Andrew Mobbs - http://www.chiark.greenend.org.uk/~andrewm/



Sun, 23 May 2004 19:45:14 GMT
 RAID: Advantage or disaster?
We had similar problems with a database here, that had all the data
files on the same filesystem.
If you look at File IO, you may find its one file causing most of the
bottleneck.  In our case it was TEMP.
So we moved this onto another filesystem (not raided incidentally as its
write intensive).  And no more problems...
Heres teh File IO SQL to be run as system, it works on 7.3.4 and I think
on 8i, I'm not certain of that mind.
Good luck.

 SELECT name, phyrds, phyrds * 100 / trw.phys_reads read_pct,
              phywrts,  phywrts * 100 / trw.phys_wrts write_pct,
                db.tablespace_name
   FROM  tot_read_writes trw, v$datafile df, v$filestat
fs,dba_data_files db
  WHERE df.file# = fs.file#
  and df.file# = file_id

Geoff
Geoff Reader
University of Brighton  

Quote:

> What do people think about the use of RAID for an IDS database these days?
> Better, worse, or about the same on balance as JABOD? Any RAID levels to
> prefer / avoid?

> A client of mine is running RAID 5 on Compaq, and is getting 100% disk i/o
> and frequent crashes. I haven't been able to look closely enough to
> establish whether it's the RAID 5 that's causing this, but anyway they're
> moving to a bigger box and planning to go RAID 5 again.

> Conventional wisdom and past experience tells me this would be a disaster.
> Has the technology moved on so as to tip the scales?

> --
> -Andy Kent-
> Bristol, England

> Remove '.DontSpamMe' from return address to respond.



Sun, 23 May 2004 21:19:53 GMT
 RAID: Advantage or disaster?

Quote:

> RAID 1+0 is wonderful, and solves most of your problems, but is expensive.

> RAID 0 reduces the disk reliability but is great for performance.
> Don't use it unless you're willing to assume the risk.

> RAID 5 is OK in its place. Traditionally it's been considered to be very
> poor for write performance but good for read, however I've recently seen
> very impressive results with striped RAID-5 sets (RAID 5+0 ?) behind
> a very large RAM cache (16 GB). I still wouldn't recommend it for redo
> logs though.

I do not think that especially for Oracle are a good idea any RAIDs
with stripes (data area spreads across several discs). The best option
for perfomance is RAID1, because you will get a good perfomance and
you always know when each part of your data is, that's something very
hard to achieve with stripes, especially with RAID5. So using one
RAID5 set for all database files is a very bad thing for I/O
perfomance.
I usually advise in those situations: plug as many disc as possible,
mirror them and then spread all your files properly across them and
your Oracle instance will be happy.

--
_________________________________________

Dusan Bolek, Ing.
Oracle team leader


can call it an overture to bankruptcy) on that server. I'm still using
this email to prevent SPAM. Maybe one day I will change it and have a
proper mail even for news, but right now I can be reached by this
email.



Sun, 23 May 2004 23:15:37 GMT
 RAID: Advantage or disaster?
tried your SQL, what is the tot_read_writes  table ??????

--
John Jones
Senior Oracle DBA
Duke University, OIT


Quote:
> We had similar problems with a database here, that had all the data
> files on the same filesystem.
> If you look at File IO, you may find its one file causing most of the
> bottleneck.  In our case it was TEMP.
> So we moved this onto another filesystem (not raided incidentally as its
> write intensive).  And no more problems...
> Heres teh File IO SQL to be run as system, it works on 7.3.4 and I think
> on 8i, I'm not certain of that mind.
> Good luck.

>  SELECT name, phyrds, phyrds * 100 / trw.phys_reads read_pct,
>               phywrts,  phywrts * 100 / trw.phys_wrts write_pct,
>                 db.tablespace_name
>    FROM  tot_read_writes trw, v$datafile df, v$filestat
> fs,dba_data_files db
>   WHERE df.file# = fs.file#
>   and df.file# = file_id

> Geoff
> Geoff Reader
> University of Brighton


> > What do people think about the use of RAID for an IDS database these
days?
> > Better, worse, or about the same on balance as JABOD? Any RAID levels to
> > prefer / avoid?

> > A client of mine is running RAID 5 on Compaq, and is getting 100% disk
i/o
> > and frequent crashes. I haven't been able to look closely enough to
> > establish whether it's the RAID 5 that's causing this, but anyway
they're
> > moving to a bigger box and planning to go RAID 5 again.

> > Conventional wisdom and past experience tells me this would be a
disaster.
> > Has the technology moved on so as to tip the scales?

> > --
> > -Andy Kent-
> > Bristol, England

> > Remove '.DontSpamMe' from return address to respond.



Sun, 23 May 2004 23:50:37 GMT
 RAID: Advantage or disaster?
I'm going to disagree with your assertion.  If you have only a few
data files, you cannot take advantage of parallel query without a
striped set of some kind as you will bottleneck on a single spindle
and have idle processes that are doing nothing but waiting.  Now, I
used to be a RAID5 is great always zealot.  I've since modified that
stance, but I will say this: most applications are read intensive, and
it's a documented fact that RAID5 sets are very good at reading data
off the disk.  There is a write penalty, but with modern controllers
(note: there is not a standard for implementing RAID5.  It varies from
manufacturer to manufacturer) and the huge caches that are available
and the high speed microprocesses on the new controllers, the
bottleneck is still the disk behind the array.  It's just the nature
of the technology.  However, there are cases, and redo is one of the
most prominent, where a RAID5 set is not the best solution.  Depending
on how often you switch log files, you may want to have the highest
throughput device you can get when it comes to redo so that you aren't
waiting on redo switches.  Temporary space is also one of these areas
as they are about 50/50 read/write.  In datawarehousing applications
where you may want to have large arrays, RAID5 make alot of sense (and
cents <grin>).

Getting back to the original posting, I would be more concerned as to
why the server is crashing.  I've been using Compaq hardware with a
variety of RAID sets (5, and 1+0) and I've never had a problem with
either.  I think he's got more of a problem with a bad driver or board
than with a drive configuration, IMO.  I've run a small data warehouse
on a Compaq 6500 with five RAID 5 arrays, and I've NEVER had to reboot
due to an Oracle or NT failure (which actually says alot considering
I've got NT on the thing!)

My $0.02, and I'll give it away for free, so you got what you paid
for.

Dan Peacock
DBA
Wolverine World Wide

Quote:


> > RAID 1+0 is wonderful, and solves most of your problems, but is expensive.

> > RAID 0 reduces the disk reliability but is great for performance.
> > Don't use it unless you're willing to assume the risk.

> > RAID 5 is OK in its place. Traditionally it's been considered to be very
> > poor for write performance but good for read, however I've recently seen
> > very impressive results with striped RAID-5 sets (RAID 5+0 ?) behind
> > a very large RAM cache (16 GB). I still wouldn't recommend it for redo
> > logs though.

> I do not think that especially for Oracle are a good idea any RAIDs
> with stripes (data area spreads across several discs). The best option
> for perfomance is RAID1, because you will get a good perfomance and
> you always know when each part of your data is, that's something very
> hard to achieve with stripes, especially with RAID5. So using one
> RAID5 set for all database files is a very bad thing for I/O
> perfomance.
> I usually advise in those situations: plug as many disc as possible,
> mirror them and then spread all your files properly across them and
> your Oracle instance will be happy.

> --
> _________________________________________

> Dusan Bolek, Ing.
> Oracle team leader


> can call it an overture to bankruptcy) on that server. I'm still using
> this email to prevent SPAM. Maybe one day I will change it and have a
> proper mail even for news, but right now I can be reached by this
> email.



Mon, 24 May 2004 06:00:03 GMT
 RAID: Advantage or disaster?

Quote:

> I'm going to disagree with your assertion.

I'm going to disagree with your, so it's OK. :-)

Quote:
>  If you have only a few
> data files, you cannot take advantage of parallel query without a
> striped set of some kind as you will bottleneck on a single spindle
> and have idle processes that are doing nothing but waiting.  Now, I
> used to be a RAID5 is great always zealot.  I've since modified that
> stance, but I will say this: most applications are read intensive, and
> it's a documented fact that RAID5 sets are very good at reading data
> off the disk.  

Maybe I'm wrong, but I think that you can have as much of datafiles as
you need. So If you want to take advantage of PQ, then you can have
tablespace with ten datafiles across ten disks.
If you're using RAID1 you can use PQ, because you already have your
data on two disk and can read from them in parallel.
The problem with RAID5 is that your files are not spread according to
your needs, but by internal mechanism. So is hard to tune your I/O
access by spreading across the disks, because you never know where
your files are.
The worst scenario is to use one RAID5 set for all datafiles, that's
very bad and I've seen it for many times.
The biggest advantage of RAID5 is the price for it. RAID1 is more
expensive because of disk prices and even more because of disk slot
prices. So If you have only few disk bays and can't afford bigger
server or external storage, then using RAID5 for some large tablespace
is definitely a good option. Just do not use RAID5 for redologs and
temp and do not put your index tablespace on the same RAID5 set as the
data tablespace, because you can realize that your indexes will be on
the same disk with appropriate data, because Murphys laws are
working. :-)

--
_________________________________________

Dusan Bolek, Ing.
Oracle team leader


can call it an overture to bankruptcy) on that server. I'm still using
this email to prevent SPAM. Maybe one day I will change it and have a
proper mail even for news, but right now I can be reached by this
email.



Mon, 24 May 2004 16:35:59 GMT
 RAID: Advantage or disaster?
Doh,  sorry not paying attention.

DROP TABLE tot_read_writes;

 CREATE TABLE tot_read_writes
  AS SELECT SUM(phyrds) phys_reads, sum(phywrts) phys_wrts
        FROM V$FILESTAT;

should preced my query.  Thats what comes of trying to simplify
things....

Geoff
Geoff Reader
University of Brighton

Quote:

> tried your SQL, what is the tot_read_writes  table ??????

> --
> John Jones
> Senior Oracle DBA
> Duke University, OIT



> > We had similar problems with a database here, that had all the data
> > files on the same filesystem.
> > If you look at File IO, you may find its one file causing most of the
> > bottleneck.  In our case it was TEMP.
> > So we moved this onto another filesystem (not raided incidentally as its
> > write intensive).  And no more problems...
> > Heres teh File IO SQL to be run as system, it works on 7.3.4 and I think
> > on 8i, I'm not certain of that mind.
> > Good luck.

> >  SELECT name, phyrds, phyrds * 100 / trw.phys_reads read_pct,
> >               phywrts,  phywrts * 100 / trw.phys_wrts write_pct,
> >                 db.tablespace_name
> >    FROM  tot_read_writes trw, v$datafile df, v$filestat
> > fs,dba_data_files db
> >   WHERE df.file# = fs.file#
> >   and df.file# = file_id

> > Geoff
> > Geoff Reader
> > University of Brighton


> > > What do people think about the use of RAID for an IDS database these
> days?
> > > Better, worse, or about the same on balance as JABOD? Any RAID levels to
> > > prefer / avoid?

> > > A client of mine is running RAID 5 on Compaq, and is getting 100% disk
> i/o
> > > and frequent crashes. I haven't been able to look closely enough to
> > > establish whether it's the RAID 5 that's causing this, but anyway
> they're
> > > moving to a bigger box and planning to go RAID 5 again.

> > > Conventional wisdom and past experience tells me this would be a
> disaster.
> > > Has the technology moved on so as to tip the scales?

> > > --
> > > -Andy Kent-
> > > Bristol, England

> > > Remove '.DontSpamMe' from return address to respond.



Mon, 24 May 2004 21:07:22 GMT
 RAID: Advantage or disaster?
Doh,  sorry not paying attention.

DROP TABLE tot_read_writes;

 CREATE TABLE tot_read_writes
  AS SELECT SUM(phyrds) phys_reads, sum(phywrts) phys_wrts
        FROM V$FILESTAT;

should preced my query.  Thats what comes of trying to simplify
things....

Geoff
Geoff Reader
University of Brighton

Quote:

> tried your SQL, what is the tot_read_writes  table ??????

> --
> John Jones
> Senior Oracle DBA
> Duke University, OIT



> > We had similar problems with a database here, that had all the data
> > files on the same filesystem.
> > If you look at File IO, you may find its one file causing most of the
> > bottleneck.  In our case it was TEMP.
> > So we moved this onto another filesystem (not raided incidentally as its
> > write intensive).  And no more problems...
> > Heres teh File IO SQL to be run as system, it works on 7.3.4 and I think
> > on 8i, I'm not certain of that mind.
> > Good luck.

> >  SELECT name, phyrds, phyrds * 100 / trw.phys_reads read_pct,
> >               phywrts,  phywrts * 100 / trw.phys_wrts write_pct,
> >                 db.tablespace_name
> >    FROM  tot_read_writes trw, v$datafile df, v$filestat
> > fs,dba_data_files db
> >   WHERE df.file# = fs.file#
> >   and df.file# = file_id

> > Geoff
> > Geoff Reader
> > University of Brighton


> > > What do people think about the use of RAID for an IDS database these
> days?
> > > Better, worse, or about the same on balance as JABOD? Any RAID levels to
> > > prefer / avoid?

> > > A client of mine is running RAID 5 on Compaq, and is getting 100% disk
> i/o
> > > and frequent crashes. I haven't been able to look closely enough to
> > > establish whether it's the RAID 5 that's causing this, but anyway
> they're
> > > moving to a bigger box and planning to go RAID 5 again.

> > > Conventional wisdom and past experience tells me this would be a
> disaster.
> > > Has the technology moved on so as to tip the scales?

> > > --
> > > -Andy Kent-
> > > Bristol, England

> > > Remove '.DontSpamMe' from return address to respond.



Mon, 24 May 2004 21:08:22 GMT
 RAID: Advantage or disaster?
Ahem... Correct me if I'm off the track, but isn't RAID 1 a mirroring? This
said, I can't see how RAID 1 can improve PQs by reading off 2 disks in
parallel unless the RAID controller is so smart it interleaves disk reads
between the mirrors. Anyway, from Oracle's point of view these two are
one so it will read from them (it) sequentially, wouldn't it?

--

Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet applications.
All opinions are mine and do not necessarily go in line with those of my employer.



Quote:
> > I'm going to disagree with your assertion.

> I'm going to disagree with your, so it's OK. :-)

> >  If you have only a few
> > data files, you cannot take advantage of parallel query without a
> > striped set of some kind as you will bottleneck on a single spindle
> > and have idle processes that are doing nothing but waiting.  Now, I
> > used to be a RAID5 is great always zealot.  I've since modified that
> > stance, but I will say this: most applications are read intensive, and
> > it's a documented fact that RAID5 sets are very good at reading data
> > off the disk.

> Maybe I'm wrong, but I think that you can have as much of datafiles as
> you need. So If you want to take advantage of PQ, then you can have
> tablespace with ten datafiles across ten disks.
> If you're using RAID1 you can use PQ, because you already have your
> data on two disk and can read from them in parallel.
> The problem with RAID5 is that your files are not spread according to
> your needs, but by internal mechanism. So is hard to tune your I/O
> access by spreading across the disks, because you never know where
> your files are.
> The worst scenario is to use one RAID5 set for all datafiles, that's
> very bad and I've seen it for many times.
> The biggest advantage of RAID5 is the price for it. RAID1 is more
> expensive because of disk prices and even more because of disk slot
> prices. So If you have only few disk bays and can't afford bigger
> server or external storage, then using RAID5 for some large tablespace
> is definitely a good option. Just do not use RAID5 for redologs and
> temp and do not put your index tablespace on the same RAID5 set as the
> data tablespace, because you can realize that your indexes will be on
> the same disk with appropriate data, because Murphys laws are
> working. :-)

> --
> _________________________________________

> Dusan Bolek, Ing.
> Oracle team leader


> can call it an overture to bankruptcy) on that server. I'm still using
> this email to prevent SPAM. Maybe one day I will change it and have a
> proper mail even for news, but right now I can be reached by this
> email.



Tue, 25 May 2004 02:36:56 GMT
 RAID: Advantage or disaster?

Generally mirrors will give read benefits (using round-robin scheduling or
even bouncing the request at both and seeing which comes back fastest), and
minimal write penalty since the writes are done in parallel.

But I do disagree with Dusan's assertion that stripes aren't good.

Cheers
Connor



Quote:
> Ahem... Correct me if I'm off the track, but isn't RAID 1 a mirroring?
This
> said, I can't see how RAID 1 can improve PQs by reading off 2 disks in
> parallel unless the RAID controller is so smart it interleaves disk reads
> between the mirrors. Anyway, from Oracle's point of view these two are
> one so it will read from them (it) sequentially, wouldn't it?

> --


http://www.dpsp-yes.com
Quote:
> Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet
applications.
> All opinions are mine and do not necessarily go in line with those of my
employer.





> > > I'm going to disagree with your assertion.

> > I'm going to disagree with your, so it's OK. :-)

> > >  If you have only a few
> > > data files, you cannot take advantage of parallel query without a
> > > striped set of some kind as you will bottleneck on a single spindle
> > > and have idle processes that are doing nothing but waiting.  Now, I
> > > used to be a RAID5 is great always zealot.  I've since modified that
> > > stance, but I will say this: most applications are read intensive, and
> > > it's a documented fact that RAID5 sets are very good at reading data
> > > off the disk.

> > Maybe I'm wrong, but I think that you can have as much of datafiles as
> > you need. So If you want to take advantage of PQ, then you can have
> > tablespace with ten datafiles across ten disks.
> > If you're using RAID1 you can use PQ, because you already have your
> > data on two disk and can read from them in parallel.
> > The problem with RAID5 is that your files are not spread according to
> > your needs, but by internal mechanism. So is hard to tune your I/O
> > access by spreading across the disks, because you never know where
> > your files are.
> > The worst scenario is to use one RAID5 set for all datafiles, that's
> > very bad and I've seen it for many times.
> > The biggest advantage of RAID5 is the price for it. RAID1 is more
> > expensive because of disk prices and even more because of disk slot
> > prices. So If you have only few disk bays and can't afford bigger
> > server or external storage, then using RAID5 for some large tablespace
> > is definitely a good option. Just do not use RAID5 for redologs and
> > temp and do not put your index tablespace on the same RAID5 set as the
> > data tablespace, because you can realize that your indexes will be on
> > the same disk with appropriate data, because Murphys laws are
> > working. :-)

> > --
> > _________________________________________

> > Dusan Bolek, Ing.
> > Oracle team leader


> > can call it an overture to bankruptcy) on that server. I'm still using
> > this email to prevent SPAM. Maybe one day I will change it and have a
> > proper mail even for news, but right now I can be reached by this
> > email.



Tue, 25 May 2004 07:07:23 GMT
 RAID: Advantage or disaster?
Hi there,

   Read Metalink Forum ID: 140791.999

Allan W. Tham
DBA



Tue, 25 May 2004 15:26:47 GMT
 RAID: Advantage or disaster?

Quote:

> Generally mirrors will give read benefits (using round-robin scheduling or
> even bouncing the request at both and seeing which comes back fastest), and
> minimal write penalty since the writes are done in parallel.

Yes, indeed. When using good RAID controller, RAID1 can be a pretty
quick.

Quote:
> But I do disagree with Dusan's assertion that stripes aren't good.

I do not think that stripes are bad. However everything has some
trade-offs. If you can afford to place your data on separate disk sets
or even using separate controllers, you will get definitely better
performance than using one stripe set. So my suggestion is to use more
physical places for your data instead of using one RAID5 set, which do
this work (separate files on more disks) for you, but without any
control.

For example:

2x18GB RAID1   /u01/SID/data/index01.dbf
2x18GB RAID1   /u02/SID/data/app_data01.dbf
2x9GB RAID1   /u02/SID/data/system01.dbf

will be better than

4x18GB RAID1   /u01/SID/data/index01.dbf
               /u01/SID/data/app_data01.dbf
               /u01/SID/data/system01.dbf

because in the first case you know when your datafiles are. With the
second place you can be lucky and have all datafiles separate, but
maybe they will be placed together and then you can't expect a great
performance.
However in the second case you will save two 9GB disks and 2 drive
bays.

--
_________________________________________

Dusan Bolek, Ing.
Oracle team leader


can call it an overture to bankruptcy) on that server. I'm still using
this email to prevent SPAM. Maybe one day I will change it and have a
proper mail even for news, but right now I can be reached by this
email.



Tue, 25 May 2004 16:32:25 GMT
 
 [ 13 post ] 

 Relevant Pages 

1. RAID: Advantage or disaster?

2. RAID: Advantage or disaster?

3. RAID 1+0 with RAID 5 or RAID 0+1 with RAID 5

4. To RAID or not to RAID (...or how to RAID)

5. Raid 0+1 Versus Raid 1 (Raid Again)

6. blocks size/and RAID 1+0 versus RAID 5 NT4 SS7

7. Raid 5 vs Raid 1+0

8. Raid 5 vs Raid 10

9. Raid 5 v. Raid 10

10. RAID 5 write performance versus RAID 1

11. RAID 0 + 1 or RAID 50

12. RAID 5 vs RAID 10


 
Powered by phpBB® Forum Software