Message-ID: <021f01c7254b$98f55ba0$0200a8c0@Primary>
From: "Jonathan Lewis" <jonathan@jlcomp.demon.co.uk>
To: <oracle-l@freelists.org>
Subject: Re: oracle-l Digest V3 #373
Date: Thu, 21 Dec 2006 22:01:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed;	charset="iso-8859-1";	reply-type=response
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: jonathan@jlcomp.demon.co.uk


Apologies to Prashant for attributing to him the suggestion
to read the article quoted below.  The suggestion actually
came from Murtuja.khokhar.

Regards

Jonathan Lewis
http://jonathanlewis.wordpress.com

Author: Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html


----- Original Message ----- 
From: "Jonathan Lewis" <jonathan@jlcomp.demon.co.uk>
To: <oracle-l@freelists.org>
Sent: Thursday, December 21, 2006 9:15 AM
Subject: Re: oracle-l Digest V3 #373


>
> Prashant,
>
> Before recommending that link again, you might like to think carefully
> about the quality of the content. Here's just one small example of how 
> erroneous it is:
>
>   " By segregating high activity tables into a separate, smaller data buffer, 
> "
>   " Oracle has far less RAM frames to scan for dirty block, improving the"
>   "  throughout and also reducing CPU consumption.  This is especially "
>   " important for super-high update tables with more than 100 row changes "
>    " per second."
>
> Since Oracle 8.1, dirty blocks go on to the checkpoint queue the moment
> they are made dirty - and they stay in place on that queue until the database 
> writer has written them; and DBWR picks them off the queue in the correct 
> order without having to scan the buffer.  That's why you see far fewer 
> "checkpoint not complete" errors, and how the fast_start_mttr_target
> can be made to work.
>

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