Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: RAID5 and Oracle 7.3.4

Re: RAID5 and Oracle 7.3.4

From: Ed Stevens <Ed.Stevens_at_nmm.nissan-usa.com>
Date: Mon, 24 May 1999 13:04:59 GMT
Message-ID: <7ibipq$tn1$1@nnrp1.deja.com>


Andy -

I'm a bit of a "contrarian" on this subject, so take what I say (and what everyone else says) with a grain of salt.

First, the undisputable facts. With all of your physical disks in a single array, there is nothing you can do with logical partitioning and/or file placement to reduce contention. Everything is being striped across all of the disks. Regardlesss of any logical organization (which will have benefits from an admin point of view) it's all still going to the same physcial device. Yes, there is benifit in putting all of the separate components on separate physical devices (with separate disk controllers!) but most of us don't have that luxury.

Now, for my contrarian view: Whether or not you will see performance degradation, the answer -- as always -- is "it depends." Yes, with all of your physical disks in a single array (of any RAID level) you will get head contention. Will it impact performance? Of course! Will it impact performace enough to bother the user? Maybe, maybe not. If one setup gave my end user average response time of 0.3 seconds, and another gave 0.6 seconds, I wouldn't get too lathered, even though the second is "twice as slow" as the first. Your philosophy may be different. Will you suffer a performance penalty for the use of RAID-5 (vs. RAID-1, or 0+1)? Maybe, maybe not. The theory, which many people take as gospel, is that RAID-5 is a dog when it comes to write intensive performance. The reason for this is that extra time is take to compute block parity data, and an extra operation is needed to write the parity data. In my view there are a lot of mitigating factors. Performance will be better with the RAID implemented in the controller rather than the OS. Better yet if the controller has a reliable on- board cache. Raid-5 gives a high degreee of parallelism on both read and write operations and this improves with and increasing number of physical disks. Your workload may or may not be enough to make it matter at a practical level. I have not had the luxury of running my own tests, but I do know that most of the pontificating I've read on RAID performance fails to take all of these variables into account. Bottom line is "your mileage may vary."

In article <37476D69.206A0E79_at_midwest.net>,   Andy Bennett <taylora_at_midwest.net> wrote:
> I'm a relative newbie to the DBA world of Oracle and have been handed
an
> Oracle 7.3.4 system to manage. The database server is a Sun 5500
> Enterprise Server running Solaris 2.6. It has 4, 400 Mhz CPUs, a 100
> Mhz bus, and an ES1000 controller running RAID5 over 4, 18 Gb discs.
> I've been assured that our server does not lack speed or raw
performance
> thanks to the 4 SMP processors and bus architecture (no argument
here).
>
> With all this being said, I am concerned about how to best utilize
this
> system while minimizing I/O contention during write intensive
operations
> and/or other performance degradation. I've read several articles
> recommending the use of separate physical devices for each specific
type
> of tablespace: SYSTEM, DATA1, DATA2, RBS, INDEX, TEMP, etc. This
> doesn't appear to be an option for the system at hand.
>
> I would like to layout the tablespaces to best use the physical
devices
> available and plan on organizing the needed tablespaces on appropriate
> logical volumes. Are there any other considerations I should factor
in
> regarding location?
>
> How does the SMP factor into this? Should we be considering tuning
with
> parallel query statement in our SQL?
>
> Is this database destined to suffer degraded performance for the sake
of
> the recoverability offered by the operating system and RAID5?
>
> Is there a good, recent reference for these concerns?
>
> I've got a million more questions, but will resist the urge for now.
>
> Thanks for any info you can provide,
>
> Andy
>

--
Ed Stevens
(Opinions are not necessarily those of my employer)

--== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.--- Received on Mon May 24 1999 - 08:04:59 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US