 |
|
Oracle Tips by Burleson |
Tuning Redo Logs
To tune redo logs you should:
-
Actually tune LGWR process to optimize
log writes
-
LGWR writes when log buffers 1/3 full,
or on COMMIT
-
Tune redo log size based on transaction
size, too small a size results in frequent inefficient IO, too
large results in too long a write
-
Be sure logs are not in contention with
each other or other files
To Determine average transaction size as far
as redo buffer writes:
(redo size + redo wastage)
----------------------------------
Redo writes
Use data from V$SYSSTAT. Size your log buffers to near this size,
error on too much rather than too little.
Size actual redo logs such that they switch every thirty minutes, or
based on the amount of data you can afford to lose (loss of the
active redo log results in loss of its data.)
Redo logs maintain a complete history of data and database changing
transactions. Redo logs are critical for recovery and operation of
the Oracle database system. Unfortunately redo logs are another
structure that is difficult to tune before an application system
goes active. The majority of tuning efforts with redo logs deal with
two important issues:
1. Minimize the impact of the
redo log/archive log/checkpoint processes on database
performance.
2. Maximize recoverability of the database
At times these two goals may be in
opposition since by maximizing recoverability (by reducing time to
recovery for example) you will cause a performance impact. I am
afraid you will have to balance these two goals while dealing with
redo log tuning, however one thing to remember is that you will
(hopefully) spend much more time dealing with an operational
database than you will recovering a database so in the greater
scheme of things perhaps optimizing for performance is the major
goal you should attempt to reach.
This is an excerpt by
Mike Ault’s e-book:
Tuning
Third-party Vendor Oracle Systems
Tuning when you can't touch the code
ISBN:
0-9740716-3-3
http://www.rampant-books.com/ebook_vendor_tune.htm
|
