database releases now can leverage automatic shared memory tuning.
Redo log buffer
The redo log buffer caches redo information until it is written to the physical redo log files stored on a disk. This buffer also improves performance. Oracle caches the redo until it can be written to a disk at a more optimal time, which avoids the overhead of constantly writing the redo logs to disk.
Other pools in the SGA
The SGA includes several other pools:
Large pool
Provides memory allocation for various I/O server processes, backup, and recovery, and provides session memory where shared servers and Oracle XA for transaction processing are used.
Instance Memory and Processes
|
51
Java pool
Provides memory allocation for Java objects and Java execution, including data in the Java Virtual Machine in the database.
Streams pool
Provides memory allocation used to buffer Oracle Streams queued messages in the SGA instead of in database tables and provides memory for capture and apply.
Dynamic initialization parameters available for these pools include LARGE_POOL_
SIZE, JAVA_POOL_SIZE, and STREAMS_POOL_SIZE. These are automatically set if MEMORY_TARGET or SGA_TARGET is specified.
Automatic PGA management
Oracle automatically manages the memory allocated to an instance Program Global Area (PGA). The PGA consists of session memory and a private SQL area. The memory amount can be controlled by setting the PGA_AGGREGATE_TARGET initialization parameter. Automatic PGA management, available since Oracle Database 10 g , greatly simplified management of SQL work areas and eliminated the need to set several different initialization parameters that previously existed. As of Oracle Database 11 g , PGA memory allocation is automatically tuned along with the SGA memory allocations by setting MEMORY_TARGET.
Background Processes for an Instance
The most common background processes are shown in Figure 2-8 and vary from Oracle release to release. Among the background processes in Oracle Database 11 g are the following:
Database Writer (DBWn)
Writes database blocks from the database buffer cache in the SGA to the datafiles on disk. An Oracle instance can have up to 20 DBW processes to handle the I/O load to multiple datafiles—hence the notation DBW n . Most instances run one DBW. DBW writes blocks out of the cache for two main reasons:
• If Oracle needs to perform a checkpoint (i.e., to update the blocks of the datafiles so that they “catch up” to the redo logs). Oracle writes the redo for a transaction when it’s committed, and later writes the actual blocks. Periodically, Oracle performs a checkpoint to bring the datafile contents in line with the redo that was written out for the committed transactions.
• If Oracle needs to read blocks requested by users into the cache and there is no free space in the buffer cache. The blocks written out are the least recently used blocks. Writing blocks in this order minimizes the performance impact of losing them from the buffer cache.
52
|
Chapter 2: Oracle Architecture
Log Writer (LGWR)
Writes the redo information from the log buffer in the SGA to all copies of the current redo log file on disk. As transactions proceed, the associated redo information is stored in the redo log buffer in the SGA. When a transaction is committed, Oracle makes the redo information permanent by invoking the Log Writer to write it to disk.
System Monitor (SMON)
Maintains overall health and safety for an Oracle instance. SMON performs crash recovery when the instance is started after a failure and coordinates and performs recovery for a failed instance when youhave more than one instance accessing the same database, as with Real Application Clusters. SMON also cleans up adjacent pieces of free space in the datafiles by merging them into one piece and gets rid of space used for sorting rows when that space is no longer needed.
Process Monitor (PMON)
Watches over the user processes that access the
Redo log buffer
The redo log buffer caches redo information until it is written to the physical redo log files stored on a disk. This buffer also improves performance. Oracle caches the redo until it can be written to a disk at a more optimal time, which avoids the overhead of constantly writing the redo logs to disk.
Other pools in the SGA
The SGA includes several other pools:
Large pool
Provides memory allocation for various I/O server processes, backup, and recovery, and provides session memory where shared servers and Oracle XA for transaction processing are used.
Instance Memory and Processes
|
51
Java pool
Provides memory allocation for Java objects and Java execution, including data in the Java Virtual Machine in the database.
Streams pool
Provides memory allocation used to buffer Oracle Streams queued messages in the SGA instead of in database tables and provides memory for capture and apply.
Dynamic initialization parameters available for these pools include LARGE_POOL_
SIZE, JAVA_POOL_SIZE, and STREAMS_POOL_SIZE. These are automatically set if MEMORY_TARGET or SGA_TARGET is specified.
Automatic PGA management
Oracle automatically manages the memory allocated to an instance Program Global Area (PGA). The PGA consists of session memory and a private SQL area. The memory amount can be controlled by setting the PGA_AGGREGATE_TARGET initialization parameter. Automatic PGA management, available since Oracle Database 10 g , greatly simplified management of SQL work areas and eliminated the need to set several different initialization parameters that previously existed. As of Oracle Database 11 g , PGA memory allocation is automatically tuned along with the SGA memory allocations by setting MEMORY_TARGET.
Background Processes for an Instance
The most common background processes are shown in Figure 2-8 and vary from Oracle release to release. Among the background processes in Oracle Database 11 g are the following:
Database Writer (DBWn)
Writes database blocks from the database buffer cache in the SGA to the datafiles on disk. An Oracle instance can have up to 20 DBW processes to handle the I/O load to multiple datafiles—hence the notation DBW n . Most instances run one DBW. DBW writes blocks out of the cache for two main reasons:
• If Oracle needs to perform a checkpoint (i.e., to update the blocks of the datafiles so that they “catch up” to the redo logs). Oracle writes the redo for a transaction when it’s committed, and later writes the actual blocks. Periodically, Oracle performs a checkpoint to bring the datafile contents in line with the redo that was written out for the committed transactions.
• If Oracle needs to read blocks requested by users into the cache and there is no free space in the buffer cache. The blocks written out are the least recently used blocks. Writing blocks in this order minimizes the performance impact of losing them from the buffer cache.
52
|
Chapter 2: Oracle Architecture
Log Writer (LGWR)
Writes the redo information from the log buffer in the SGA to all copies of the current redo log file on disk. As transactions proceed, the associated redo information is stored in the redo log buffer in the SGA. When a transaction is committed, Oracle makes the redo information permanent by invoking the Log Writer to write it to disk.
System Monitor (SMON)
Maintains overall health and safety for an Oracle instance. SMON performs crash recovery when the instance is started after a failure and coordinates and performs recovery for a failed instance when youhave more than one instance accessing the same database, as with Real Application Clusters. SMON also cleans up adjacent pieces of free space in the datafiles by merging them into one piece and gets rid of space used for sorting rows when that space is no longer needed.
Process Monitor (PMON)
Watches over the user processes that access the
Similar Books
