RE: db_file_multiblock_read_count and performance

If anyone is vague on the distinction between "performance" and "scalability," I wrote a paper called "Scalability is a rate of change" a few years ago to help clarify.

You can find it at www.hotsos.com.

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

Upcoming events:

- Performance Diagnosis 101: 1/4 Calgary
- SQL Optimization 101: 12/13 Atlanta
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Jared Still
Sent: Tuesday, December 07, 2004 2:07 PM To: Post, Ethan
Cc: Christian.Antognini_at_trivadis.com; ryan_gaffuri_at_comcast.net; Oracle-L_at_freelists.org
Subject: Re: db_file_multiblock_read_count and performance

Don't forget 'as scalable as possible'.

Check the stats I posted earlier.

On Tue, 7 Dec 2004 13:19:19 -0600, Post, Ethan <Ethan.Post_at_ps.net> wrote:  

> I would think ideal is "as fast as possible" and assuming you tell
> Oracle the truth about speed of multiblock reads verse single block with
> optimizer_index_cost_adj everything should work out fine, even if full
> scans are favored. Of course too many scans at the same time and
> optimizer_index_cost_adj is no longer valid because IO bandwidth may
> effect response times, so I guess this is where system stats has a
> supreme advantage.
>
>

-- 
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
--
http://www.freelists.org/webpage/oracle-l

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