Re: Performance Question: RAID or Individual drives ?

Dominic Baines wrote:

> Thanks MotoX:
>
> Following you're advise I tried this on a separate server with an almost
> identical datbase (export of original and imported onto the other) but this time
> used the 15 drive model for the database (DBA handbook rough example followed)
> but with the drive non-RAID'd and the performance was just so much better than
> the RAID5 version for both READ's (about 85% slower) and WRITE's (more than 55%
> slower). OK so that doesn't tell me much more that I expected really but is
> there a way to improve the RAID performance ?
>

Wow, that's quite a come-down on the reads - not what I'd expect. Maybe try a different adapter? Check the specs on any 'tweaking' options it might have for performance tuning.

> I believe the RAID set is one where every drive is striped across every disk and
> there is a parity member and there is a standby disk. RAID 5 ?

RAID5 strips the parity across all the disks, yes - rather than having a separate parity disk. The standby is your hot-spare, which you can configure to auto-rebuild when a disk fails.

> How would I capture the time taken for each process
> realistically ? I tried this as a rough stopwatch exercise from a sql*plus
> connection at both the server and at a client workstation.

Hey, nothing wrong with the old stopwatch! :-) Saves my life all the time.

You could try using - on UNIX - a shell script to log the output from iostat, vmstat, sar, etc. Or (and on NT) buy some additional software - although I've found this can be pretty expensive.

>
>
> At the end of the day I suppose it is the client and SLA's that will win on a
> recovery arguament rather than performance and as we both answer to the same
> person they will have to make a choice. The database is approximately 50/50
> read/write and it is growing at the rate almost across every tablepsace of some
> 15% per year in size.
>

Yep, many of my clients will happily accept the performance hit of RAID5 for the better fault-tolerance and lower cost, over, say, RAID0+1.

Regards,

Steve Phelan (MotoX).

> Regards,
>
> Dominic
>
> MotoX wrote:
>
> > That was well timed - I'm just in the middle of benchtesting strip v
> > non-strip v single disk v RAID5 for a client. It's a UNIX box, but the
> > outcome *should* be similar on NT. However, *test* you own kit with a mix of
> > the types of transactions *you* are going to perform. Anyway, here goes
> > (35,000,000 row test table):
> >
> > READING:
> >
> > One disk, best read rate 10MB/s per disk (one of).
> >
> > 3 striped disks, 3.4 MB/s per disk. If parallel query used (degree of 2 or
> > 4), rate goes to 5.7 MB/s per disk. In other words, if you stripe (64k),
> > it's also best to use parallel query when you can, because if you don't you
> > won't max out the I/O bandwidth you've created.
> >
> > On 6 striped disks, 1.95 MB/s per disk. With degree of 2 or 4, 4.4 MB/s per
> > disk. In other words, still use parallel, and although you continue to get a
> > boost, it's reducing.
> >
> > RAID5 - 1 processor, 8.3 MB/s per RAID set. Parallel with degree of 2 or 4,
> > 16.9 MB/s per RAID set. In other words, for reading, RAID5 is just as quick
> > as striped disks, but you still need to go parallel to max out the I/O. And,
> > of course, RAID5 (like striping) is much faster than non-RAID single disks,
> > as long as you can provide the CPU to drive it.
> >
> > WRITING (in summary as I haven't finished yet):
> >
> > 3 striped drives are about twice as fast as a single disk (not three times
> > faster).
> > 6 striped drives are about 4.5 times faster than a single disk.
> > NB. Like reading, the overhead of sync'ing the drives, memory bandwidth,
> > etc., affects how much real improvement you get - it won't be linear as you
> > add more drives.
> >
> > RAID5 - on my limited testing so far, writing (creating a 4 Gig tablespace)
> > has dropped from 3 x 6.8 MB/s per disk to 7.5 MB/s per RAID set. In other
> > words, RAID5 array is over twice as slow on heavy writing as the same disks
> > striped (non RAID5).
> >
> > In summary, look at striped disks (RAID0 or RAID0+1 or through an LVM) for
> > write intensive parts of your db. Look at RAID5 for read intensive sections,
> > and learn to live with the write penalty where you can.
> >
> > MotoX.
> >
> > Dominic Baines wrote in message <35AA0A1F.41151B15_at_hermes.cam.ac.uk>...
> > >I've an NT admin who RAID's everything on every NT box he touches. This
> > >is OK for redundancy if the system dies but I'm not sure this is the
> > >best option for an Oracle database performance reasons mainly. Are there
> > >any tuning guru's out there who could shine a like on the appropriate
> > >arguament to use IF it would be better to use individual drives rather
> > >than to rely on the RAID set ?
> > >
> > >What am I talking about ?:
> > >
> > >Standard set-up would be an Oracle server on NT 4 SP3 with system disk
> > >a mirrored pair and second 'drive' being a raid set over say 7 to 15
> > >disks. So ORANT is on D:, as is everything else. OK there are different
> > >drives and spindles but every read or write to anywhere on the RAID set
> > >would use every drive, wouldn't it ? These are 4GB Seagate SCSI drives.
> > >The controller is a proper RAID controller, whatever that may be. It's
> > >all on Compaq kit.
> > >
> > >Thanks,
> > >
> > >Dominic Baines
> > >
Received on Tue Jul 14 1998 - 16:43:23 CDT