Re: RAID and Oracle Databases

Well, first off, get some *** stats *** on >>> your <<< system, both at the OS and Oracle level. And come up with a Performance *and* Recovery plan, as the two don't normally complement each other.

Be VERY, VERY wary of taking advice from a newsgroup, no matter how well intentioned it is, because without a detailed knowledge of your db, application, requirements, etc., etc., etc., people are guessing - me included. For instance, your system may work perfectly well all installed on RAID5, if it is write light, and not I/O bound. We run three small systems on RAID5 (and have done so for over 3 years) and they work *perfectly* well (and we monitor them to make sure). We also run large I/O intensive databases of 200Gig+ on a mix of RAID and non-RAID. The point I'm trying to make is that one solution does not suit all.

Read below for a bit more advice on *general* matters relating to your post. Like I said, don't take it as gospel - do some research, design and testing on a realistic set-up for your system.

Vicky Hillsgrove wrote in message <362CCD69.3BB6D3CA_at_city.lakeland.net>...

[snipped intro.]

>I am very hesitant about configuring this new box with on line and
>archived redo logs
>and temporary tablespace on RAID 5. I understand that redo logs should
>not be put on
>disk arrays if possible, but that is my only option.

All of the above will *work* on RAID5. How *fast* it is compared to the alternative configurations can only be determined by *testing*. Only then will you have some hard *facts* on which to make a decision.

> Therefore, my
>configuration plan is as
>follows:
>
>1. Bind 9 disks as a RAID5 Logical Unit and assign to one controller. I
>plan on putting
>my true datafiles and indexes on this unit.

Well, this means all the I/O for your data and indexes is against this one array and controller. Again, this may be OK. On the other hand, it may be better to try and pull some hot sections of your db (both data and indexes) apart. RAID controllers are cheap. Get some on loan to test a few configurations, and get some stats on how hard you hit critical parts of your db.

>2. Bind 10 disks as a RAID 1 (or 1/0) Logical Unit and assign to the
>other controller. I
>am planning on putting on line-redo logs, archived redo-logs and the
>temporary
>tablespace on this unit.

Well, a 10 disk stripe set is a lot, and with RAID1 I take it you mean a mirrored set of 5 disks? You've got to be a bit more specific here, as '10 disks as RAID1 (or 1/0)' doesn't mean much. Note that mirrored redo will be written at the same time.

>3. Have the remaining disk as a hot-swappable.
>
>My question regarding this configuration is: even though I am able to
>keep redo logs off
>RAID 5, am I going to gain an even bigger performance problem with
>controller
>contention? Which is worse, Redo's, etc. on RAID 5 - or - some
>controller contention?

They are both bad if they become the bottleneck. Do some testing and monitoring to find out how close to flooding the RAID adapter or disks you get. You might find you become CPU bound long beforehand...

>As far as I have researched, it is my understanding you can only have 1
>logical unit per
>controller - is this correct?

Depends on the controller. Check with your supplier.

One other point: beware of controllers with spectactular performance - it's usually down to very large on-board cache, which isn't normally battery backed. Lose a controller and you may lose your db. Enable write-thru if you aren't sure of how solid the cache protection is.

MotoX.

>
>Any advice you can send my way is VERY much appreciated. Please respond
>to all.
>
Received on Wed Oct 21 1998 - 00:00:00 CDT