Re: Interaction between databse cache, DBWR and datafiles

"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message news:3e394a86$0$245$ed9e5944_at_reading.news.pipex.net...
> "Rachel Wilson" <wilsonr_at_logica.com> wrote in message
> news:936259dc.0301300707.7d093fc2_at_posting.google.com...
>
> I expect that you will get a clearer explanation from some of the
educators
> on this list about the rest of this but i can offer two hopefully helpful
> remarks
>
> > 4. if it isn't found, the block is read into the middle of the LRU
> > list, or the MRU end, or the first free block from the LRU end
> > depending on which document you read(?)
>
> > it is step 4 that most troubles me as the documentation seems to
> > contradict itself
>
> Thats because it depends on (at least) what type of access you are doing.
A
> FTS won't place its blocks at the MRU end of the list, whereas a access by
> rowid will. I suspect that the mechanism may be altered slightly fvor the
> kmeep and recycle pools (otherwise what's the point of the recycle pool at
> least).

Hi Niall,

Actually, my understanding (so be warned) is that these pools pretty well work in exactly the same way as the default pool, with one key exception which you might be alluding to. However, the "point" of these pools is that the type of objects that get loaded into each pool gives the pool it's different "characteristic".

The KEEP pool is designed for those frequently accessed objects that we effectively want cached in memory. The one key exception I mentioned earlier is with regard to this pool in that the NOCACHE option has no effect and all blocks are loaded into the MRU portion of the list. Other than that (albeit a rather significant "that" which I'm guessing was your point) the behaviour of the pool is the same and blocks aged and are moved to the MRU as accessed. However, blocks that "aged" out here are a bit of a no no in that we access them regularly, we don't want to keep re-reading them from disk. By reading them in, it means something else has to go, which has to be re-read and so on and the whole point of the keep pool is severely diminished. Therefore, it should really be sized to accommodate *all* segments you wish to place here.

The RECYCLE pool works pretty well the same as the default pool. Difference being though that we don't really expect these blocks to be reused again (except perhaps by the same transaction that read them in) so we kinda want to get rid of them pretty quickly so they don't just sit there like stunned mullets wasting memory. Therefore we would generally size this pool to be relatively small so that objects age out quickly, but not too small such that they aged out before perhaps the transaction itself has a chance to re-access the block as necessary. You don't want to induce additional physical I/Os by making it too small, but you don't want to make it too big and waste memory either.

That's where rolling our sleeves and tuning these babies comes into play ;)

Cheers

Richard Received on Fri Jan 31 2003 - 08:45:23 CST