Oracle10g Log Buffer Tunning Tips
Oracle10g Log Buffer Tunning Tips
Oracle10g Log Buffer Tunning Tips
Donald K. Burleson
Important note for Oracle 10gr2 and beyond: Per Metalink note 351857.1, starting in
release 10.2 and beyond, Oracle will automatically size the log_buffer on your behalf and
log_buffer cannot be changed dynamically. The automatic log_buffer sizing is based on
the granule size (as determined by to _ksmg_granule_size):
select
a.ksppinm name,
b.ksppstvl value,
a.ksppdesc description
from
x$ksppi a,
x$ksppcv b
where
a.indx = b.indx
and
a.ksppinm = '_ksmg_granule_size';
Also note that if you are Oracle's Automatic Memory Management AMM (AMM is Not
recommended for some databases), the log_buffer is part of the memory_target algorithm.
2 - Size online redo logs to control the frequency of log switches and minimize system
waits.
The log_buffer is one of the most complex of the Oracle RAM region parameters to
optimize, but it's a low-resource parameter (only using a few meg of RAM), so the goal
in sizing log_buffer is to set a value that results in the least overall amount of log-related
wait events.
The big issue with the log buffer is determining the optimal sizing for the log_buffer in a
busy, high-DML database. Common wait events related to a too-small log_buffer size
include high "redo log space requests" and a too-large log_buffer may result in high "log
file sync" waits.
For more details on log_buffer sizing, see Bug 4930608 and MetaLink Note 604351.1.
Per MetaLink MetaLink note 216205.1 Database Initialization Parameters for Oracle
Applications 11i, recommends a log_buffer size of 10 megabytes for Oracle Applications,
a typical online database:
A value of 10MB for the log buffer is a reasonable value for Oracle Applications and it
represents a balance between concurrent programs and online users.
The value of log_buffer must be a multiple of redo block size, normally 512 bytes.
Even though Oracle has traditionally suggested a log_buffer no greater than one meg, I
have seen numerous shops where increasing log_buffer beyond one meg greatly
improved throughput and relieved undo contention.
The log_buffer should remain small. This is perpetuated with Metalink notes that have
become somewhat obsolete:
“It has been noted previously that values larger than 5M may not make a difference.”
Metalink notes that in 10gr2, we see a bug in log_buffer where a customer cannot reduce
the log_buffer size from 16 meg:
“In 10G R2, Oracle combines fixed SGA area and redo buffer [log buffer] together. If
there is a free space after Oracle puts the combined buffers into a granule, that space is
added to the redo buffer. Thus you see redo buffer has more space as expected. This is an
expected behavior.. .
In 10.2 the log buffer is rounded up to use the rest of the granule. The granule size can
be found from the hidden parameter "_ksmg_granule_size" and in your case is probably
16Mb. The calculation for the granule size is a little convoluted but it depends on the
number of datafiles”
If the log_buffer has been set too high (e.g. greater than 20 meg), causing performance
problems because the writes will be performed synchronously because of the large log
buffer size, evidenced by high log file sync wait. Oracle consultant Steve Adams notes
details on how Oracle processes log file sync waits:
"Before writing a batch of database blocks, DBWn finds the highest high redo block
address that needs to be synced before the batch can be written.
DBWn then takes the redo allocation latch to ensure that the required redo block address
has already been written by LGWR, and if not, it posts LGWR and sleeps on a log file
sync wait."
It's important to note that log buffer shortages do not always manifest in the top-5 timed
events, especially if their are other SGA pool shortages. Here is an example of an Oracle
10g database with an undersized log buffer, in this example 512k (This is the database as
I found it, and there was a serious data buffer shortage causing excessive disk I/O):
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) DB Time Wait Class
------------------------------ ------------ ----------- --------- -----------
log file parallel write 9,670 291 55.67 System I/O
log file sync 9,293 278 53.12 Commit
CPU time 225 43.12
db file parallel write 4,922 201 38.53 System I/O
control file parallel write 1,282 65 12.42 System I/O
In addition to re-sizing log_buffer, you can also adjust the hidden Oracle10g parameter
_log_io_size (but only at the direction of Oracle technical support) and adjust your
transactions_per_rollback_segment parameters. In 10g, the _log_io_size parameter
govern the offload threshold and it defaults to log_buffer/3.
For example, if TRANSACTIONS is 101 and this parameter is 10, then the minimum
number of rollback segments acquired would be the ratio 101/10, rounded up to 11."
At startup time, Oracle divides transactions by transactions_per_rollback_segment to
have enough rollback space, and Oracle guru Osamu Kobayashi has a great test of
transactions_per_rollback_segment:
The number of CPUs is also indirectly related to the value of log_buffer, and Metalink
discusses multiple LGWR slaves that are used to asynchronously offload the redo
information.
The hidden parameter _lgwr_io_slaves appear to govern the appearance of multiple log
writer slaves, and the Metalink note that clearly states that multiple LGWR processes will
only appear under high activity. The Oracle docs are very clear on this:
“Prior to Oracle8i you could configure multiple log writers using the
LGWR_IO_SLAVES parameter.”
“Starting with Oracle8, I/O slaves are provided. These slaves can perform asynchronous
I/O even if the underlying OS does not support Asynchronous I/O. These slaves can be
deployed by DBWR, LGWR, ARCH and the process doing Backup. . .
As there may not be substantial log writing taking place, only one LGWR IO slave has
been started initially. This may change when the activity increases.”
The Oracle8 docs note that the value for the parameter log_simultaneous_copies is
dependent on the number of CPU’s on the server:
“On multiple-CPU computers, multiple redo copy latches allow multiple processes to
copy entries to the redo log buffer concurrently. The default value of
LOG_SIMULTANEOUS_COPIES is the number of CPUs available to your Oracle
instance”
If transactions are small, or if there is only one CPU on the server, then the redo
allocation latch also copies the transaction data into the log buffer cache.”
We also see that log file parallel writes are related to the number of CPU’s. Metalink
note 34583.1 “WAITEVENT: "log file parallel write" Reference Note”, shows that the
log_buffer size is related to parallel writes (i.e. the number of CPU’s), and discusses how
LGWR must wait until all parallel writes are complete. It notes that solutions to high
“log file parallel write” waits are directly related to I/O speed, recommending that redo
log members be on high-speed disk, and that redo logs be segregated onto
(including low activity from other sources against the same disk controller)”.
Here are some great tips by Steve Adams for sizing your log_buffer:
"If the log buffer is too small, then log buffer space waits will be seen during bursts of
redo generation. LGWR may not begin to write redo until the _log_io_size threshold (by
default, 1/3 of the log buffer or 1M whichever is less) has been exceeded, and the
remainder of the log buffer may be filled before LGWR can complete its writes and free
some space in the log buffer.
Ideally, the log buffer should be large enough to cope with all bursts of redo generation,
without any log buffer space waits.
Commonly, the most severe bursts of redo generation occur immediately after a log
switch, when redo generation has been disabled for some time, and there is a backlog of
demand for log buffer space"