| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Redo Copy Latch
Kamal/Gaja,
Gaja thanks for your answer.
Please someone correct me if I'm wrong but, as far as I know, when LGWR is posted to flush entries to the redo log files, it acquires all REDO COPY LATCHES first and then the REDO ALLOCATION LATCH (in that order to avoid possible deadlocks). This is done in order to establish what entries it has to copy to disk. Once LGWR is holding all these latches , it is complete sure that no other foreground process is modifying what it is about to mark. Then LGWR marks the entries it has to flush, releases the latches (that allows other processes to continue generating redo entries in the log buffer) and flushes these entries to disk. Once it has completed the operation, it takes the RAL again to update the SGA variable that contains the log buffer base disk block.
regards,
Diego.
> Diego/Kamal,
>
> From Oracle 7.3 onwards the redo copy latch is procured "first"
> and then the allocation latch is procured to reserve the space
> in the redo log buffer. This is to prevent the redo allocation
> latch from becoming a bottleneck (as it is used purely for
> reserving space and not for writing).
>
> Prior to 7.3, the allocation latch was observed to become a
> bottleneck, when people when crazy increasing the value of
> log_small_entry_max_size. Which means, for all practical
> reasons, from Oracle 7.3 and up the value of
> log_small_entry_max_size is a moot point. This parameter is
> obsolete in Oracle8i. If you are working on versions prior to
> Oracle 8i, you should just leave it at its default value.
>
> Different versions of Oracle support different number of redo
> copy latches (configured by log_simultaneous_copies). I have
> seen it up to (8 * # of CPUs) on Oracle 7.3.4 and up, and in my
> experience of configuring this on many production systems, I
> have found no measureable overhead of setting it to its allowed
> maximum. BTW, log_simultaneous_copies is also obsolete in
> Oracle8i and is automatically configured.
>
> One more thing, it is my understanding that the redo allocation
> and copy latches are acquired by server processes to write redo
> entries into the redo log buffer, when transactions modify data.
> LGWR just writes the redo log buffer to disk in a circular
> fashion and I don't think LGWR requires the redo copy and
> allocation latches to write the contents of the redo log buffer
> to disk.
>
> Cheers,
>
> Gaja
>
> --- Diego Cutrone <dcutrone_at_afip.gov.ar> wrote:
> > Hi Kamal:
> > Forgive my poor english.
> > When Oracle needs to copy the redo entries in the log
> > buffer, it needs
> > to acquire the
> > "redo allocation latch" in order to establish the area within
> > the log buffer
> > where its going to copy this entry.
> > After that, if the size of the redo entry is smaller than the
> > setting of
> > "log_small_entry_max_size" it copies the entry
> > directly to the log buffer without taking any "redo copy
> > latch", just
> > holding the redo allocation latch. (This applies
> > only to Oracle 7, not Oracle 8).
> > If the redo entry is bigger than the setting of
> > "log_small_entry_max_size" (Oracle 7), or if you're under
> > Oracle 8,
> > the process realeses the redo allocation latch and it requests
> > the "redo
> > copy latch". Once it gets this latch, then the process
> > copies the redo entry info into the log buffer (within the
> > area it had
> > reserved before).
> > It's normal to see redo copy latch misses, because of the
> > behavior of
> > the LGWR. When LGWR writes entries to disk (redo log files) it
> > has to take
> > and hold the redo copies latch first and then the redo
> > allocation latch as
> > well, in order to establish what entries it has to copy to
> > disk. While this
> > procedure takes place, you may see "redo copy latch misses",
> > thats because
> > LGWR is holding all the redo copies latch and there are some
> > other processes
> > requesting them too.
> >
> > Hope it helps
> > Diego.
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > To: Multiple recipients of list ORACLE-L
> > <ORACLE-L_at_fatcity.com>
> > Sent: Tuesday, December 05, 2000 8:00 AM
> >
> >
> > > Hi Gurus
> > >
> > > As per my understanding, when Oracle needs to copy the
> > changes to the redo
> > > log buffer it needs to acquire the latch and there are two
> > types of
> > latches
> > > 'redo allocation' and 'redo copy'. And which type of latch
> > need to be
> > > acquired is based on the size of change and the parameter
> > > 'log_small_entry_max_size' (in multiple CPU only). If the
> > change is bigger
> > > than log_small_entry_max_size then the oracle will acquire
> > 'redo
> > > allocation' latch else 'redo copy'. If I am missing
> > something then please
> > > correct me.
> > >
> > > We are having 28 CPUs and set the log_small_entry_max_size
> > to 0. So I
> > should
> > > not see anything in the redo copy latch gets but I am
> > getting the figures
> > in
> > > redo copy latch as well. Can anyone explain me the reason
> > why, please ?
> > >
> > > Thanks & regards,
> > >
> > > Kamal Sood
> > >
> > > --
> > > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > > --
> > > Author: Sood, Kamal
> > > INET: Kamal.Sood_at_gbr.xerox.com
> > >
> > > Fat City Network Services -- (858) 538-5051 FAX: (858)
> > 538-5051
> > > San Diego, California -- Public Internet access /
> > Mailing Lists
> > >
> >
> --------------------------------------------------------------------
> > > To REMOVE yourself from this mailing list, send an E-Mail
> > message
> > > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
> > and in
> > > the message BODY, include a line containing: UNSUB ORACLE-L
> > > (or the name of mailing list you want to be removed from).
> > You may
> > > also send the HELP command for other information (like
> > subscribing).
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Diego Cutrone
> > INET: dcutrone_at_afip.gov.ar
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858)
> > 538-5051
> > San Diego, California -- Public Internet access /
> > Mailing Lists
> >
> --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail
> > message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
> > and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from).
> > You may
> > also send the HELP command for other information (like
> subscribing).
>
>
> =====
> Gaja Krishna Vaidyanatha
> Director, Storage Management Products, Quest Software Inc.
> Office : (972)-304-1170, E-mail : gaja_at_quest.com
>
> Author:Oracle Performance Tuning 101 by Osborne McGraw-Hill
> "Opinions and views expressed are my own and not of Quest"
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Gaja Krishna Vaidyanatha
> INET: gajav_at_yahoo.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
Received on Thu Dec 07 2000 - 10:40:51 CST
 |
 |