| 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
Hi Gaja,
Thanks for your clarification.
I didn't know that LGWR functionality had changed in Oracle 8.
Please confirm me this (for Oracle 8 realease or above):
If log_buffer < 1MB then Oracle8 LGWR behaves like Oracle7 does. I mean LGWR writes when 1/3 of log buffer fills (background write), and in order to do this, it takes redo copies and redo allocation latch to mark entries in the redo log buffer, etc ... . And, of course, it also writes when a commit takes place (sync write), and when that happens it also takes these latches.
But, if log_buffer >= 1MB then LGWR behaves as you described in your post.
LGWR only flushes entries to disk if log buffer is "full" or when a commit
takes place.
And when "any" one of these events happens, LGWR takes the redo copy latches
and the RAL, it marks what it has to flush to disk, realeases these latches,
then it writes the entries to disk (or the whole log buffer), it takes RAL
again, updates "base disk block" variable and realeses RAL. am I correct?
Please correct me if I'm wrong.
Thanks
> Hi Anil, Diego & the list,
>
> I think I may have a clarification to your disagreement and it
> is related to a functionality change in how LGWR writes the redo
> entries from the log_buffer to disk. It stems from one of the
> "events" that cause LGWR to write - the 1/3rd full event.
>
> Prior to Oracle8, if log_buffer were 'x bytes' in size, when
> there were 'x/3 bytes worth of redo entries' in the log_buffer,
> LGWR wrote the x/3 bytes to disk, allowing other server
> processes to continue writing to the remaining 2x/3 bytes. That
> was the whole point behind it being a 'circular buffer'. This
> occurred without any redo copy latches being taken away or
> frozen.
>
> In Oracle8 that functionality got modified a little. The 1/3
> full event really does not 'kick in' unless log_buffer was sized
> at 1Mb. So if log_buffer is less than 1Mb. in size, LGWR will
> wait for log_buffer to be full and then initiate the write. When
> that happens, it is only normal for the redo copy latches to be
> momentarily frozen or taken away (as the case may be), to
> prevent any writes to log_buffer (because it is already full).
>
> The point I was trying to make in my original posting that LGWR
> itself should not take away any of the redo copy latches for the
> normal process of writing redo entries to disk. The subtle
> difference I am trying to point out is between the 'entire redo
> log buffer' getting flushed to disk vs. redo entries written to
> disk periodically (when 1/3rd full or every 3 secs.).
>
> The need to flush the redo log buffer really will not arise if
> the 1/3rd full event kicks in (as needed). However, this doesn't
> happen if log_buffer is sized < 1Mb. To add a little more
> complexity to the problem, there is also the 'nuance' of the
> 'write ahead' feature of LGWR a.k.a. 'piggy-backed writes' and
> this occurs when multiple commit tokens are written to the
> log_buffer, because multiple transactions committed
> approximately at the same time and posted their tokens to
> log_buffer.
>
> Hope that helps,
>
> Gaja
>
> --- Anil Sikri <anil_sikri_at_hotmail.com> wrote:
> > Hi Gaja ( and the list ),
> > Nice explanation, as always.
> > I do disagree on one point, though. I believe that at least on
> > Oracle 8.0.x, LGWR does take all the redo copy latches when it
> > is in
> > the process of flushing the redo log buffer to write the
> > contents to
> > the appropriate redo log file. This is done to prevent any
> > server process
> > from modifying the contents of log buffer while it is being
> > flushed by the LGWR. All these server processes contending for
> > the
> > log buffer have to wait on a log file sync event which can be
> > seen in
> > V$SESSION_WAIT ( This is the same event for which DBWR waits
> > so that
> > LGWR can flush the log buffer first ).
> >
> > I think this ( LGWR taking all the redo copy latches ) has
> > changed on
> > Oracle8i.
> >
> > Regards,
> > Anil Sikri
> >
> >
> >
> > >From: Gaja Krishna Vaidyanatha <gajav_at_yahoo.com>
> > >Reply-To: ORACLE-L_at_fatcity.com
> > >To: Multiple recipients of list ORACLE-L
> > <ORACLE-L_at_fatcity.com>
> > >Subject: RE: Redo Copy Latch
> > >Date: Wed, 06 Dec 2000 19:01:15 -0800
> > >
> > >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
> > >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).
> >
> >
>
 |
 |