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).
>
>
> Get more from the Web. FREE MSN Explorer download :
> http://explorer.msn.com
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Anil Sikri
> INET: anil_sikri_at_hotmail.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).
Gaja Krishna Vaidyanatha
Director, Storage Management Products, Quest Software Inc.
Received on Fri Dec 08 2000 - 11:21:19 CST
