The reason that I consider it a problem is that I have increased the physical IO on
my database. I see Full Table Scans on these two tables, which are large tables
relative to the others. I moved them to they RECYCLE pool so that they would have
less of an impact on the DEFAULT pool. By doi
At a high level, I think the various pools operate in pretty
much the same way - but there are some differences,
some of which may be affected by various hidden
parameters.
For example, Steve Adams has this note (dated Oct 2000)
on his website as one of several observations on the 'new'
LRU mecha
t; From: Jonathan Lewis [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 02, 2003 3:44 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Buffer Pool Testing
>
>
>
> The 'problem' is, as you say, related to the tablescan.
> Craig is correct that NOR
The 'problem' is, as you say, related to the tablescan.
Craig is correct that NORMALLY a full tablescan will
only permit a limited number of blocks to get into
the cache at the LRU end of the chain - the number
is typically the size of db_file_multblock_read_count.
There are a couple of special c
So it seems like my problem is the full table scan. Craig Shallahammer mentions
this in his "All About Oracle's Touch-Count Data Block Buffer Algoithm" paper - "The
modified LRU algorithm places full-table scanned blocks read into the buffer cache at
the LRU end of the LRU chain and only perm
I think you are seeing expected behaviour.
Blocks subject to tablescan are loaded in to the LRU
end of the cache, even when using a RECYCLE
cache. However, if there are free blocks in the
cache (state = 0) Oracle uses those rather than
flushing other blocks.
Consequently, when you startup and s
