Re: Redo log buffers

rsenn wrote:
>
> Do the redo log buffers flush from memory to disk every few seconds, or
> only when they fill up and the oldest data is moved out? [ If I set
> the redo log buffers to 1M or maybe more, would I be at risk of losing
> 1M or maybe more of recent activity in the event of an abnormal abort? ]

Logwriter (LGWR) flushes the log buffer from the SGA to an online redo log file when: a commit occurs, every 3 seconds, when the buffer is 1/3 full, or when DBWR cleans dirty block buffers. Since a transaction is not committed until the buffer is flushed to the online redo log (disk),
you aren't in grave danger of losing committed data during a crash. However,
before you grow the size of the buffer, you may want to first check for any
log buffer space contention and/or redo allocation contention. Check your
bstat/estat reports for:

Size of the Redo Log Buffer (LOG_BUFFER) In order to write to the log buffer, a latch must be obtained and space must be allocated. If it is to small, processes must wait for space before
they can access it. This contention can be reduced by increasing it's size.
Zero waits for space requests is desirable.

Redo Allocation Latch Contention
If a process cannot get the redo allocation latch (one per instance), the process spins and trys again. If after spinning a certain amount of time, the process sleeps until it wakes up and retries again, and
so on... Redo copy latches can be used to reduce contention for this latch.
Also, by decreasing the LOG_SMALL_ENTRY_MAX_SIZE parameter, processes are
forced to obtain a redo copy latch to write to the buffer, and the allocation latch is free'd. In this manner large, potentially time consuming, redo is done with a copy latch.

Redo Copy Latch Contention
Having acquired the redo allocation latch, if the redo information is greater than LOG_SMALL_ENTRY_MAX_SIZE, a nowait get of the redo copy latch
is attempted. If a latch is unavailable, the process holds the allocation
latch to perform the (large) write, potentially causing other processes waiting for it to sleep. Additionally, if a processes redo is made up of
many small pieces, it can be better to tell Oracle to combine these pieces
before requesting the latch. This is done by setting the parameter LOG_ENTRY_PREBUILD_THRESHOLD (bytes) to the maximum number of bytes to piece together, hence prebuilding a single redo entry from multiple ones.
Redo copy latch contention can be decreased by increasing the number of latches via the LOG_SIMULTANEOUS_COPIES parameter (up to twice the number
of CPU's).

Sorry if this is more than you asked for... I thought I would pass on some
information that I spent some time putting together for myself. Mike Received on Mon Sep 15 1997 - 00:00:00 CDT