Re: Recommended stripe depth for Oracle on a Raid?

Rick Denoire wrote:

>Daniel Morgan <damorgan_at_x.washington.edu> wrote:
>
>
>
>
>>I would dispute that based on benchmarking we performed just this year
>>with the latest
>>hardware and configurations.
>>
>>
>
>I would expect Raid 10 being faster, no question. The question is: How
>much faster? In my very short DBA life I have learned that 30% of
>speed increase is almost nothing. At least it is not worth the
>sacrifice for space compared to Raid 5. As you surely know, the true
>source of performance is the application itself. There seems to be no
>limit in potential performance improvement there. This is because most
>people who design the schema and write SQL/front_end don't bother
>about performance issues.. until it is too late.
>
>It happened a couple of weeks ago, that some developers asked me for
>help, because the instance of a Webbased DB product running on a
>notebook (a kind of demo platform) did not respond fast enough and the
>browser timed out. I intervened and tuned almost everything a DBA can
>do in one strike (since it was not a production environment). They
>were very impressed since afterwards the DB was working really faster.
>But this is a seldom case. I was having a hard time trying to tell
>them to be aware how Oracle executes their SQL statements. They don't
>seem to be aware that SQL is not a procedural programming language and
>that one has to put an eye on the execution plan. They rather expect
>ME to somehow make things faster. Jesus!
>
>In my opinion, DBAs who care whether hot data are contained in the
>outer zone of the disk (where linear speed is larger than towards the
>center of the disk) must be crazy. I have seen improvements from two
>days to several seconds... on the application side. No Raid
>configuration will ever achieve that. It is not worth even trying.
>
>Rick Denoire
>
>

I'd disagree. Hard disk is cheap. Through put is essential. And disk I/O is still the slowest
thing you can do on a computer. Likely always will be given current technology.

Must admit you are correct that the biggest limiting factors is the developers. But those
developer's lack of thinking, if anything, makes disk I/O more expensive ... not less.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)