To approximate size of the SGA (Shared Global Area), use following formula:
DB_CACHE_SIZE + DB_KEEP_CACHE_SIZE + DB_RECYCLE_CACHE_SIZE +DB_nk_CACHE_SIZE + SHARED_POOL_SIZE + LARGE_POOL_SIZE + JAVA_POOL_SIZE +LOG_BUFFERS + 1MB
Components of the SGA:
a) REDO LOG BUFFER (controlled by LOG_BUFFER)
The Redo Log Buffer is an area of allocated memory within the SGA for buffering redoinformation prior to being written to the redo log files. The redo buffers are a crucialcomponent of the Oracle recoverability process and are accessed for almost every databaseprocess and transaction. Even uncommitted transactions access the Redo Log Buffer.
The Redo Log Buffer helps to absorb processing spikes caused by the memory to memorytransfer of data (SGA to Redo Buffer) verses the memory to disk transfer of data (RedoBuffer to Redo Log). As the buffer fills up, the output process (LGWR) is awakened to emptythe buffer to the redo log files. The LGWR process requires some lead time, since it ispossible that a large transaction could generate redo faster than the LGWR process canwrite to disk. To help alleviate this possible bottleneck, once the redo buffer becomes onethird full, the LGWR process will be awakened into action. Otherwise the LGWR process willawaken every 3 seconds or during a checkpoint process.
The size of this buffer is specified in bytes using the
parameter. In general, alarger redo buffer size reduces redo log file I/O, particularly if transactions are long ornumerous. In a busy system, the value 65536 or higher is not unreasonable, howevervalues above 1Mb are unlikely to yield any significant benefit. The default size of the redolog buffer is dependant on the hardware and operating system platform. The size of theredo log buffer can be viewed with the following query:
select * from v$sgastat where name = 'log_buffer';
POOL NAME BYTES
----------- ------------------- ---------
When an Oracle database instance is started up, the size of 'Redo Buffers' shown can differfrom the value of the log_buffer size specified in the parameter file. This is due to memoryset aside for what is known as "guard" pages which help to protect the redo buffer.
NOTE: If you have small transactions each COMMIT causes redo to be flushed to disk beforethe COMMIT returns control to the user.
Tips for Tuning Redo
- Locate Redo Log files on a separate disk to data if at all possible
- Use larger Redo Log Files if necessary
- Increase the number of Redo Log Groups (& files)
- Use NOLOGGING where possible (Remeber: SQL statements such as UPDATE, DELETE,conventional path INSERT, and various DDL statements not listed above) are unaffected bythe NOLOGGING attribute)
- It is more effective to size Redo Logs larger and set LOG_CHECKPOINT_INTERVAL to ahigher number (ie. 9999999 - 7x9).
- Init Parameters:
- LOG_BUFFER - (Increase - Evaluate)
- CHECKPOINT_INTERVAL - (Increase)
- DB_BLOCK_MAX_DIRTY_TARGET - (Increase)