Database buffer cache

The largest component of the SGA is usually the database buffer cache, which is the part of the SGA that holds copies of blocks of data read from the Oracle datafiles on disk. The size of the database buffer cache is controlled by the INIT.ORA parameter DB_BLOCK_BUFFERS, which specifies the number of database blocks that will be contained in the database buffer cache. Since this is expressed as database blocks, the size of the database buffer cache is the value of DB_BLOCK_BUFFERS multiplied by the DB_BLOCK_SIZE. For example, if a database has been created with a DB_BLOCK_SIZE of 8192 (8K) and DB_BLOCK_BUFFERS is set to 1000, then the database buffer cache component of the SGA would be 8192 × 1000 or 8,192,000 bytes.

When a user process needs data from the database, Oracle first checks to see if the required block is already in the database buffer cache. If it is, it is retrieved from the cache and a disk I/O operation is avoided. Oracle maintains an LRU (least recently used) list of blocks in the cache; when a block is read, its identifier is moved to the end of the list, making it the last block to be purged from the cache. One exception to this rule is that blocks read as the result of a full table scan are placed at the top of the LRU list; the assumption is that they are unlikely to be requested again soon. This behavior may be overridden by using the CACHE clause when creating or updating a table.

If the requested block is not resident in the database buffer cache, then a free block must be located. If the cache is full, then the block at the top of the LRU list is removed, and the requested block is read from disk. If the block at the top of the LRU is a “dirty” block—meaning that its data has been modified—then the identifier for that block is moved to the dirty list to await processing by the DBWR process. If a free buffer block cannot be located, the DBWR process is notified that its services are required, and the dirty blocks are written to disk.

When a block of data is not available in the database buffer cache and must be read from disk, it is considered a cache miss . Likewise, when a block is available in the buffer, it is considered a cache hit. The ratio of these two occurrences, called thehit/miss ratio , is an important metric for Oracle database tuning. The larger the size of the database buffer cache, the more likely it is that a particular block resides in cache memory, and the better the hit/miss ratio will be. Since memory access is orders of magnitude faster than disk access, most Oracle databases are configured with the largest possible database buffer cache.

Tip

Be extremely careful not to set DB_BLOCK_BUFFERS so high that paging results, since paging degrades the performance of the database much more than Oracle I/O operations from disk.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset