Redo copy latch and redo allocation latch

Redo copy latch and redo allocation latch

Post by philippe BACKOUCH » Tue, 09 Feb 1999 04:00:00



Could someone explain me the differences between those two and how
LOG_SIMULTANEOUS_COPIES and LOG_SMALLEST_..SIZE influences them ...

Best regards

 
 
 

Redo copy latch and redo allocation latch

Post by Jonathan Lewi » Thu, 11 Feb 1999 04:00:00


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


>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?


 
 
 

Redo copy latch and redo allocation latch

Post by Kevin Bran » Thu, 11 Feb 1999 04:00:00


You can also allocate multiple ( 2xCPU's set by  log_simultaneous_copies )
redo copy latches on multi-processor machines.  Then reduce
redo_small_entry_max_size to a point where you begin to see more use of the
copy latches.  This will increase overall redo performance because you'll
get more concurrency than when your threads ( user-sessions ) try to make
use of the single redo allocation latch.

If you're running 7.3+, the redo_small_entry_max_size has been reduced by
default on multi-processor systems to take advantage of this concurrency.
I've set my small_size to 40 ( half that of the default of 80 ) and my
simul.._copies to 16 on an 8xCPU UNIX platform and seen great improvement
during heavy concurrent redo activity.

-Kevin

--

remove the x for an email reply

>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


>>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?

 
 
 

1. Reducing Redo Copy latch contention in 7.3 NT server

I am running an NT 7.3 server and am only getting a .014 hit
ratio on my Redo copy latch.  I have already increased the
log_simultaneous_copies to 2*cpu's (4).  According to the book,
I should next set log_entry_prebuild_threshold.  Only one problem,
this parameter doesn't seem to exist on my database.  Any suggestions
would be greatly appreciated.

Thanks in advance.

2. Open Problems in Database Theory

3. redo copy latch sleep 80% ??

4. Need to determine Userid from within Powerbuilder

5. redo copy latch bad hit ratio

6. Reading SQL Server 2000 tables from AS400

7. last latch ratio (redo copy) and general performance advice

8. VFP 5 with SQL Server

9. Redo Copy Latch Contention

10. Contention for redo copy latches

11. Redo Copy Latch

12. redo copy latch