Previous | Table of Contents | Next

Page 59

at the far end of the MRU side are removed first. This way, blocks that are frequently accessed are kept in memory.

NOTE
The exception to the LRU loading rule is that data that is accessed through a full table scan is automatically placed at the bottom of the LRU list. This behavior can be overridden by specifying the table as CACHE.

Buffer blocks that have been modified are called dirty, and are placed on the dirty list. The dirty list keeps track of all data modifications made to the cache that have not been flushed to disk. When Oracle receives a request to change data, the data change is made to the blocks in the buffer cache and written to the redo log, and the block is put on the dirty list. Subsequent access to this data reads the new value from the changed data in the buffer cache.

The Oracle server uses deferred, multiblock writes to lessen the impact of disk I/O on database performance. This means that an update to a piece of data does not immediately update the data in the data files. The RDBMS waits to flush changed data to the data files until a predetermined number of blocks have been changed, space needs to be reclaimed from the cache to load new data, a checkpoint occurs, or DBWR times out. When DBWR is signaled to perform a buffer cache write, it moves a group of blocks to the data files.

The key to configuring the buffer cache is to ensure that the correct amount of memory is allocated for optimal caching of data. This doesn't necessarily mean allocating all possible memory resources to the buffer cache; however, as in most computer applications, there is a point of diminishing returns with increased memory allocation. You find that beyond a certain point, the increase in buffer cache hit percentage gained with an addition of memory becomes less and less worthwhile, and that the memory you are allocating to the buffer cache could be better used in other places, such as other Oracle memory structures.

Two initialization parameters determine the size of the buffer cache—DB_BLOCK_SIZE and DB_BLOCK_BUFFERS. The DB_BLOCK_SIZE parameter is used during database creation to set the size of the Oracle block (which is explained in detail in Chapter 7, "Exploring the Oracle Environment"). The DB_BLOCK_BUFFERS parameter determines the number of blocks to allocate to the buffer cache. Multiplying DB_BLOCK_SIZE * DB_BLOCK_BUFFERS gives you the total amount of memory (in bytes) of the buffer cache.

The Redo Log Buffer The redo log buffer is used to store redo information in memory before it is flushed to the online redo log files. It is a circular buffer, meaning that it fills from top to bottom and then returns to the beginning of the buffer. As the redo log buffer fills, its contents are written to the online redo log files.

The redo log buffer is sized by means of the LOG_BUFFER initialization parameter. The value is specified in bytes, and determines how much space is reserved in memory to cache redo log entries. If this value is set too low, processes contend with each other and the Log Writer (LGWR) (explained later) process reading and writing to the buffer, possibly causing performance problems. This is, however, a rarity in all but the most active of databases and can be monitored using the v$sysstat view. Query v$sysstat for the "value" field with the field "name"

Page 60

equal to "redo log space requests." This indicates the time user processes spent waiting for the redo log buffer.

To enforce the sequential nature of the redo log writes, the Oracle server controls access to the buffer using a latch. A latch is nothing more than a lock by an Oracle process on a memory structure—similar in concept to a file or row lock. A process must hold the redo allocation latch to be able to write to the redo log buffer. While one process holds the allocation latch, no other process can write to the redo log buffer using the allocation latch.

The Oracle server limits the amount of redo that can be written at one time using the value of the initialization parameter LOG_SMALL_ENTRY_MAX_SIZE. This parameter is specified in bytes, and the default value varies, depending on OS and hardware. For servers with multiple CPUs, the Oracle server does allow redo entries needing space greater than the value of the LOG_SMALL_ENTRY_MAX_SIZE parameter to be written using the redo allocation latch. Instead, processes must hold a redo copy latch. The number of redo copy latches available is equal to the value of the LOG_SIMULTANEOUS_COPY initialization parameter. The default for LOG_SIMULTANEOUS_COPY is the number of CPUs in the system. Using redo copy latches, multiple processes can simultaneously write to the redo log buffer.

You can monitor the redo allocation and copy latches using the v$latch dynamic performance view. (See Chapter 31, "Tuning Memory," for more information on tuning the redo latches.)

The Oracle Background Processes

At any one point in time, an Oracle database can be processing thousands (or millions!) of rows of information, handling hundreds of simultaneous user requests, and performing complex data manipulations, all while providing the highest level of performance and data integrity. To accomplish these tasks, the Oracle database divides the grunt work between a number of discrete programs, each of which operates independently of one another and has a specific role to play. These programs are referred to as the Oracle background processes, and are the key to effectively handling the many operational stresses placed upon the database. A complete understanding of the background processes and the tasks they perform helps you to analyze performance problems, pinpoint bottlenecks, and diagnose trouble spots in your database.

NOTE
On Windows NT servers, the background processes are implemented as multiple threads to the Oracle Service. This allows the Oracle process to use shared memory address space more efficiently, and results in less context changes by the Windows NT OS to handle Oracle operations.

The Oracle background processes are as follows:

Previous | Table of Contents | Next