Re: Redo copy latch and redo allocation latch

David,
A minor detail on your explanation -

In a multiple CPU system the redo allocation latch is used by all processes to get their ration of the redo buffer very quickly; the redo allocation latch is then released and the redo copy latch is taken to do the actual copying into the allocated area.

The copy latches are necessary to ensure that when a log buffer write takes place, LGWR does not write out a section of the log that has been allocated but not yet filled LGWR has to be able to grab all the redo copy latches before it is allowed to write.

In answer to your question below - (and this is purely guesswork; I'll make a completely different guess if you decide that you described it the wrong way round) -

On a single CPU system, there is no point in waiting for an allocation latch - if someone else has got it it is not going to come free whilst you spin, so you might as well give up immediately and release the CPU - this is not true, of course, on a multiple CPU system but maybe the code layer has not been modified.

If you are using copy latches at all, you are on a multiple CPU system, and there is a reasonable chance that a latch will become free if wait a bit - it is cheaper therefore to waste a bit of CPU spinning rather than releasing your CPU and finding that you migrate to a different CPU when you wake-up again.

Jonathan Lewis
Yet another Oracle-related web site: www.jlcomp.demon.co.uk

David Sisk wrote in message ...
>
>I have a box (NT) with 4 - 400Mhz Pentium Xeon processes (lots of extra
>juice!), so I'm trying to shift more log buffer locking to use the redo
copy
>latches (by lowering the LOG_SMALL_ENTRY_MAX_SIZE parm). I'm seeing that
>almost all Willing-to-wait latches are using a copy latch, while all
>immediate latches are using an allocation latch. (Hmmmm, or do I have this
>backwards?)
>
>Any thoughts on this one?
Received on Wed Feb 10 1999 - 02:59:02 CST