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

In article <901697260.18251.0.nnrp-11.c2de712e_at_news.demon.co.uk>,   "MotoX" <rat_at_tat.a-tat.com> wrote:
>
> 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).
>

Yes we do that too - using HACMP

Regards

Oliver Willandsen
European Commission
http://europa.eu.int
All remarks are my own and do not necessarily reflect offical EC policy

> 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!
> >
> >
> >
>
>

-----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum Received on Wed Jul 29 1998 - 07:21:24 CDT