Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 4 ■ MEMORY STRUCTURES 141
Block Buffer Cache
So far, we have looked at relatively small components of the SGA. Now we are going to look at
one that is possibly huge in size. The block buffer cache is where Oracle stores database blocks
before writing them to disk and after reading them in from disk. This is a crucial area of the
SGA for us. Make it too small and our queries will take forever to run. Make it too big and we’ll
starve other processes (e.g., we won’t leave enough room for a dedicated server to create its
PGA, and we won’t even get started).
In earlier releases of Oracle, there was a single block buffer cache, and all blocks from
any segment went into this single area. Starting with Oracle 8.0, we had three places to store
cached blocks from individual segments in the SGA:
• Default pool: The location where all segment blocks are normally cached. This is the
original—and previously only—buffer pool.
• Keep pool: An alternate buffer pool where by convention you would assign segments
that were accessed fairly frequently, but still got aged out of the default buffer pool due
to other segments needing space.
• Recycle pool: An alternate buffer pool where by convention you would assign large segments
that you access very randomly, and which would therefore cause excessive buffer
flushing but would offer no benefit, because by the time you wanted the block again it
would have been aged out of the cache. You would separate these segments out from
the segments in the Default and Keep pools so that they would not cause those blocks
to age out of the cache.
Note that in the Keep and Recycle pool descriptions I used the phrase “by convention.”
There is nothing in place to ensure that you use neither the Keep pool nor the Recycle pool in
the fashion described. In fact, the three pools manage blocks in a mostly identical fashion;
they do not have radically different algorithms for aging or caching blocks. The goal here was
to give the DBA the ability to segregate segments to hot, warm, and do not care to cache areas.
The theory was that objects in the Default pool would be hot enough (i.e., used enough) to
warrant staying in the cache all by themselves. The cache would keep them in memory since
they were very popular blocks. You might have had some segments that were fairly popular,
but not really hot; these would be considered the warm blocks. These segments’ blocks could
get flushed from the cache to make room for some blocks you used infrequently (the “do not
care to cache” blocks). To keep these warm segments blocks cached, you could do one of the
following:
• Assign these segments to the Keep pool, in an attempt to let the warm blocks stay in the
buffer cache longer.
• Assign the “do not care to cache” segments to the Recycle pool, keeping the Recycle
pool fairly small so as to let the blocks come into the cache and leave the cache rapidly
(decrease the overhead of managing them all).
This increased the management work the DBA had to perform, as there were three caches
to think about, size, and assign objects to. Remember also that there is no sharing between
them, so if the Keep pool has lots of unused space, it won’t give it to the overworked Default
or Recycle pool. All in all, these pools were generally regarded as a very fine, low-level tuning