Hi Waleed,
I am not sure what you mean by speculation - the first post I
did with the 1 Mb. (a couple of days back) was before we had a
chance to look up the source. I don't have any access to that,
he does, and he does it in his free time. Today's posting was
done after the source was looked into. There was no
'speculation' in what I said today. It is the truth as he tells
me and I trust his technical capabilities.
I don't think it is even fair to ask someone who is doing all of
us a huge favor (to answer some core questions) to do something
such as 'open up the source on a public list' such as this. I do
hope you were just kidding and pulling my chain.
Cheers,
Gaja
- "Khedr, Waleed" <Waleed.Khedr_at_FMR.COM> wrote:
>
> I do not understand if you have access to the source code then
> why do you
> have to speculate about LGWR behavior?
>
> Also it could be a good idea to ask your friend in Oracle to
> post some of
> the source code here in this list so that we can answer many
> of the
> questions we have.
>
>
> -----Original Message-----
> Sent: Wednesday, December 13, 2000 12:45 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Hello everyone,
>
> A couple of days ago I had posted a response to someone's
> query
> about copy latches and in that discussion I had mentioned that
> the 1/3 full event of the redo log buffer will really not
> 'kick
> in' unless log_buffer is set to at least 1Mb. I must confess
> that the number here is actually 3Mb and not 1Mb as posted
> before. I apologize for that typo.
>
> However, the fact remains that from Oracle8, LGWR will not be
> posted by the 1/3rd full event of the redo log buffer, unless
> there are at least 1 Mb worth of redo entries in the
> log_buffer.
> In my previous posting, I said that for this to occur the
> log_buffer should be sized at least 1 Mb, but that number is
> actually even higher - 3 Mb.
>
> And the rationale behind that stems from the events on which
> LGWR writes to disk. They are as follows:
>
> 1) Every 3 secs (independent of DBWR, yes this has been proven
> to be true by testing and looking up the source code).
> 2) On a Commit.
> 3) When DBWR posts LGWR to write. (This is to make sure that
> the
> redo entires are written before 'dirty' blocks are written to
> disk).
> 4) On checkpoints.
> 5) When the log_buffer is 1/3rd full, but subject to the
> following formula MAX(1 Mb., log_buffer/3), i.e., at least 1
> Mb
> of redo entries need to be there, for the 1/3 event to occur.
>
> Now let's think about this for a minute. Realistically the
> need
> for the 1/3rd full event is not that critical, as events 1-4
> will take care of getting the redo entries down to disk. And
> this in no way will cause more 'log buffer space' waits than
> what the system is already experiencing.
>
> To make doubly sure that I was not 'under the influence', I
> called a very good friend of mine at Oracle, and had him check
> the source code for 8.0.5, and he corroborated my claim. We
> are
> doing some further digging, to determine whether 'all' or
> 'one'
> of the redo copy latches are used to protect the buffer, while
> 'flushing' the entire contents of the log_buffer. There are 2
> references to this (one mentioning 1 copy latch and the other
> mentioning all copy latches) and we will get to the bottom of
> that and I will then post our findings.
>
> End of technical stuff;
>
> ********************************************************
> Begin non-technical stuff;
>
> When I originally posted that the 1/3rd full event has changed
> in functionality in Oracle8, it was termed as a 'ludicrous
> suggestion'. Now, that comment may have gone 'just a bit too
> far' to my personal comfort, as it was directed against me
> 'point blank'. I just could not hit the 'delete key' on that
> one.
>
> In light of all the 'country of origin' and 'ethnic
> background'
> stuff that has gone through our list in the past couple of
> days,
> I humbly urge all of us to exercise some caution in our
> communications. This is an forum where we cannot guage the
> poster's feelings, hence we need to make sure that we are
> sensitive to the reader's feelings.
>
> While it is absolutely OK to question the contents of a
> posting,
> please do it in a manner that is 'amicable'. After all, we are
> human beings first, aside of our ethnic, cultural, religious
> and
> political backgrounds. Let's try to respect thatm core fact.
>
> When I met Jared approx. 3 years ago at an IOUG-A conference,
> we
> talked about creating an Oracle listserv to 'share relevant
> and
> accurate information'. I don't think Jared or any one of us,
> would want this to become 'electronic battleground' for food
> fights or to be a forum to 'force and assert one's technical
> or
> personal ego'.
>
> This list today has a few thousand individuals from all
> corners
> of the world, and all of us contribute to the best of our
> abilities. Let's continue the great technical content exchange
> that we have had and let's do that with 'respect for the
> reader'. Thanks for your patience, tolerance and technical
> prowess.
>
> End non-technical stuff;
>
> ********************************************************
>
> Seasons Greetings,
>
> Gaja
>
>
> =====
> 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).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Khedr, Waleed
> INET: Waleed.Khedr_at_FMR.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.
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"
Received on Wed Dec 13 2000 - 17:11:57 CST
