RE: Miserable Disks

Wolfgang's final sentence is an observation of Amdahl's Law at work: If I/O accounts for only a few percent of total response time, then even total elimination of I/O could improve total response time by only a few percent.

The problem I see over and over is people who think they have problems with X (in this case, X="disk I/O") because their OS or their V$ tables tell them they do. They "fix" X, and yet they still have the same performance problems when they're done.

Why guess? ...when you can KNOW whether X is contributing meaningfully to the response time of the business task you care about?

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Nullius in verba  

Hotsos Symposium 2007 / March 4-8 / Dallas Visit www.hotsos.com for curriculum and schedule details...

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Wolfgang Breitling Sent: Friday, May 26, 2006 12:21 AM
To: pythianbrinsmead_at_gmail.com
Cc: charlottejanehammond_at_yahoo.com; oracle-l_at_freelists.org Subject: Re: Miserable Disks

At 08:55 PM 5/25/2006, Mark Brinsmead wrote:

>Oh, by the way, I happen to know the site that Wolfgang referred
>to. It may amuse you to
>know that this particular site (last time I heard from them, anyway)
>was planning to deploy
>about 15TB of *new* storage in their existing CX-700 disk array,
>using 500GB SATA disks
>in a RAID-5 configuration. I think Wolfgang knew of this plan --
>perhaps he was just too
>polite to point it out. ;-)

Yes, I knew of the plan. Actually it was put in place while I was still there. I don't believe it is as bad as you make it out. It allowed us to use RAID 10 on the smaller, faster disks in the CX700 for the production databases by moving all development and support databases (~ 7 for each production database) to those big disks - without management crying foul.

In my experience, bad sql, or bad plan choices (helped along by poor sql) by the optimizer are more often the cause of poor performance than database parameters, OS parameters, or the IO subsystem - unless you made some very poor setup decisions. Case in point is the situation I described earlier. We noticed the IO problem in operations on the OS - backups, file copies - *not* in database performance, even though the IO times were abysmal. The backup took 4+ hours instead of 10-20 minutes. Nor did we see a big boost in database performance when the problem was resolved.

Regards

Wolfgang Breitling
Centrex Consulting Corporation
http://www.centrexcc.com

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l