Re: NT Oracle database with RAID-5 hardware controller - Is it good?

James Arvigo wrote in message <35BEB32D.C2E54BD_at_Spam_Rage.com>...
>I have come to use a pretty simple set of formula-like reasonings for my
DB's:

I'm always wary of 'simple formulas' :-) Still, you gotta *start* somewhere. Best thing to note is that each client's requirement is different, and getting a good grip on what they actually want and what they can afford has always been the difficult part in my experience.

>
>1) If the DB is *mostly* READ-centric, and very large, then use RAID-5.

Yep, gives you good fault-tolerance for a cheap price. Still, I'm not a great fan of redo, rollback, and temp all dump on the same RAID5 array as the rest of the db. Having said that, I know many customers who do it and are happy with the performance. Just gotta be careful to make sure you still mirror things like the control files and redo logs to a separate directory, which I find people sometimes miss (sorta, hey, it's RAID5, it does it all for me, kind of attitude).

You can also look at setting up multiple RAID5 groups to try and balance the I/O across controllers. This can also help segment you database for maintenance purposes.

>
>2) If the DB is *mostly* WRITE-centric, then use 0+1 mirroring, and as much
>as possible try to segment the DB accross multiple drives. (Although we're
>using mostly 9 and 18 Gig SCSI-III drives now, that allows for alot of data
>per drive.)

Yep, if it's an option. RS600 (IBM UNIX) doesn't offer this on it's SSA adapters, only RAID5.
The other element is also cost. Some of my clients run TB sized databases, and RAID0+1 can become very costly.

Still, RAID0+1 is probably the best case solution out there for most db's.

>
>3) When mirroring drives in 0+1, if at all possible, try to mirror
*accross*
>drive controllers. Meaning, Drive1 on Controller1, mirroring Drive2 on
>Controller2. This is not *really* necessary, except that it adds that
extra
>level of security for the completely paranoid about "what if the whole
drive
>controller fails?". (This is still a questionable idea to me, and I'm
>researching it's actual practical value.)

Er, I think this one is very important. I've set up many systems with mirrored drives where we've put all the drives in external cabinets, each mirror group being in it's own cabinet with it's own power supply and dual (mirrored) disk adapters per cabinet.

In a number of banking and telecomms sites the uptime requirements are very strict and money (for hardware) isn't any issue, so the above makes sense. As does mirroring the host CPU/Memory (with OPS or a 'switchover' product).

Remember you also get the benefit of not flooding a single controller with split adapters.

>
>4) Separate Indexes and Logs and Rollback segments from the actual data
>tablespace itself.

And separate them from each other. And redo. And redo group members. I'd also say a more intelligent split is based on volatility/use of objects. Just splitting data from indexes is not necessarily the best solution, especially if many of those indexes/tables are infrequently accessed or you've cached the required blocks in memory. It's really a question of looking *why* disks are being hit.

I'm a big fan of partitioning, at all levels. Volume Groups, Logical Volumes, Tablespaces, Tables & Indexes and logical groups thereof (esp. with Oracle 8 facilities), disk adapters, drives, CPUs, etc. I've found this becomes critical when the database becomes very large - as performance tuning and maintenance can become immpossible without it - i.e., how do you backup/recover a 1TB database?... Without heavy partitioning throughout, you might not be able to. And how do you monitor which parts of your db are really the bottlenecks with analysis tools? - I've found that difficult without some prior partitioning.

>I always try and put my data in a tablespace that spans
>ONE set of drives on, and my indexes and other control files on a
completely
>different set of drives.

I'd say this is only applicable to small databases with a level spread of data/index access across all objects (which is unusual) and simple recovery requirements. It's OK as a start, and OK as long as you monitor your system and don't see the hardware peaking in usage (mainly disk and then CPU, in my experience). Once you hit problems (and preferably before) it's usually time for a slightly more detailed rethink beyond this model.

Just my thoughts.

MotoX.

>
>That's about it.
>
>This simple set of principles helps me make *lots* hardware and DB layout
>decisions.
>
>If anyone has a rule to add to my list, I always appreciate the input. *S*
>
>Regards,
>
>James Arvigo
>Developer / DBA
>Thrifty Call, Inc.
>San Marcos, TX
>jamesa_at_NOSPAM.thriftycall.com
>(just remove the NOSPAM)
>
>
>fantail2 wrote:
>
>> I just heard that if you install an Oracle database on a COMPAQ ProLiant
>> with a RAID-5 disk controller, the performance of the database is greatly
>> reduced.
>>
>> Can someone can explain to me why?
>>
>> Thanks!
>
>
>
Received on Wed Jul 29 1998 - 02:29:04 CDT