When a transaction is ready to write its changes to the redo log, it first has to grab the Redo Allocation Latch, of which there is only one, to keep others from writing to the log at the same time.  If someone else has that latch, it has to wait for the latch, resulting in a "miss".

Once it grabs that latch, if the change is larger than log_small_entry_max_size bytes and if your server has multiple CPU's, it then tries to grab a Redo Copy Latch, of which there can be up to 2 times the number of CPU's, which would allow it to release the Redo Allocation Latch for someone else to use.  If none of them are available, resulting in an "immediate miss", it will not wait for a Redo Copy Latch (thus, the "immediate"), but, instead, hangs on to the Redo Allocation Latch until the change is written.

Oracle keeps statistics for these latches in v$latch, including the number of gets and misses for the Redo Allocation Latch and the number of immediate gets and immediate misses for the Redo Copy Latches, which are cumulative values since instance startup.  If you've got a 100% hit ratio for either of those latch types, that's a good thing.  It just means that all of your transactions were able to grab and use the latch without retrying. It's when you get below a 99% hit ratio that you need to start looking out. The following sql figures the current hit ratios for those latches:

column latch_name format a20
select name latch_name, gets, misses,
     round(decode(gets-misses,0,1,gets-misses)/
     decode(gets,0,1,gets),3) hit_ratio
     from v$latch where name = 'redo allocation';

column latch_name format a20
select name latch_name, immediate_gets, immediate_misses,
     round(decode(immediate_gets-immediate_misses,0,1,
     immediate_gets-immediate_misses)/
     decode(immediate_gets,0,1,immediate_gets),3) hit_ratio
     from v$latch where name = 'redo copy';

If your Redo Copy Latch hit ratio consistently falls below 99%, and if you have a multi-CPU machine, you can raise the value of log_simultaneous_copies in your init.ora file up to twice the number of CPU's to provide more Redo Copy Latches (there is only one Redo Allocation Latch, so it is at a premium).  Remember that you have to shut down your database instance and restart it to reread the new parameter values in the init.ora file ($ORACLE_HOME/dbs/initSID.ora).  The following sql shows the current values for those associated parameters:

column name format a30
column value format a10
select name,value from v$parameter where name in
     ('log_small_entry_max_size','log_simultaneous_copies',
     'cpu_count');

Exit to :  Oracle Hints and Tips