Hi Gaja,
OK, I did read it as MIN. I retract my previous comment.
Nevertheless, although I don't have access to the source code, I am fairly sure
that it is a MIN, not a MAX.
- My testing demonstrates that under intensive redo generation without commits,
the average LGWR write is just larger than 1/3 of the log buffer certainly for
normal log buffer sizes. I have yet to repeat the test with a log buffer larger
than 3M.
- Also, the unsolicited email that I got yesterday from the Oracle insider that
I mentioned said: "I do have access to the source code and it tells LGWR to
write every 3 seconds, 1/3 full or 1M which ever is less."
Maybe you could ask your friend to check again.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/
@ http://www.christianity.net.au/
-----Original Message-----
From: Gaja Krishna Vaidyanatha [mailto:gajav_at_yahoo.com]
Sent: Thursday, 14 December 2000 5:35
To: Steve Adams; Multiple recipients of list ORACLE-L
Subject: RE: LGWR's Writing Habits
Hello Steve,
I don't think it has the opposite effect. The function is MAX
not MIN. The condition for the 1/3rd full event that forces LGWR
to write is when MAX(1 Mb., log_buffer/3) is true.
Here are some examples:
If log_buffer is 512K,
then
MAX(1 Mb, 170.6K) = 1 Mb.
-- The 1/3rd full event will not kick in as log_buffer is 512K
end if;
If log_buffer = 1Mb,
then
MAX(1 Mb, 333.33K) = 1 Mb.
-- The 1/3rd full event will not kick in as log_buffer is 1 Mb.
end if;
If log_buffer = 3 Mb.
then
MAX(1 Mb, 1 Mb.) = 1 Mb.
-- The 1/3rd full event will kick in as 1/3rd of 3 Mb. is 1 Mb.
end if;
If log_buffer = 6 Mb.
then
MAX(1 Mb, 2 Mb.) = 2 Mb.
-- The 1/3rd full event will kick in as 1/3rd of 6 Mb. is 2 Mb.
end if;
Hope that helps,
Gaja
- Steve Adams <steve.adams_at_ixora.com.au> wrote:
> Hi Gaja,
>
> Have another look at that MAX, and you'll see that it has the
> opposite effect to
> what you claim. That is, the 1/3 threshold is effective
> *below* that threshold,
> not *above* it.
>
> @ Regards,
> @ Steve Adams
> @ http://www.ixora.com.au/
> @ http://www.christianity.net.au/
>
>
> -----Original Message-----
> From: Gaja Krishna Vaidyanatha [mailto:gajav_at_yahoo.com]
> Sent: Thursday, 14 December 2000 3:45
> To: Multiple recipients of list ORACLE-L
> Subject: LGWR's Writing Habits
>
>
> 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).
>
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
Received on Wed Dec 13 2000 - 15:12:03 CST
