Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: log buffer space
Arup:
Sorry for the delay ;-)
I have not seen this is documented anywhere, other than 'Oracle Performance Tuning' OReilly Peter & Mark Gurry (page 304) where he claims the log writer writes when it is 2/3 full... Here is the Original Text.
<QUOTE>
Log Buffer
The log buffer contains the information showing the changes that have been made to database buffer blocks. When the log buffer reaches one-third full (two-thirds full in Oracle 7.3), a user performs a commit, or a write takes place to the database,......
</UNQUOTE>
I don't have any Oracle 7.3 database, (for that matter no database now as I composing this in Zurich Airport waiting for a connecting flight to Bombay..), So I may not be able to test that. But last time I verified was on an Oracle 8.1 database where the log file writes used to be in the order up to 2/3 full.
You can do a simple test to prove this point. You can use oradebug to trace the log writer process and do a CTAS of any big table (with a big log buffer) and you will be able to see the writes and number of blocks written in a single write.
I am surprised , this is not documented anywhere in the Oracle Documentation or any of the Oracle University course notes.
Best Regards,
K Gopalakrishnan
-----Original Message-----
Sent: Friday, March 14, 2003 11:04 AM
To: Multiple recipients of list ORACLE-L
Dennis,
The 1MB condition was in 8i as well, at least in 8.1.7, as I mentioned in my original post.
I was always under impresssion that the flush is triggered by the buffer being 1/3rd full; but KG mentioned it was 2/3rd, not 1/3rd and I was wondering where he got that information from and if it's documented. It true, that will certainly invalidate most of the what the fine manuals and Oracle Support analysts have said.
Any ideas, anybody?
Arup
> Add one more condition:
> New in Oracle 9i, it will write when 1 meg is reached, so the 1/3
> criteria is never reached if you use a big buffer.
>
> >
> >
>
>
>
>
>
>
> >> > also send the HELP command for other information (like subscribing).
> > Arup:
> >
> > <NO FLAMES>
> > The second condition is not quite true. It is 2/3 full in the current
> > versions.
> > </NO FLAMES>
> >
> > It is very easy to test with the event 10046^8.
> >
> > KG
> >
> >
> > --- Arup Nanda <orarup_at_hotmail.com> wrote:
> > > AK,
> > >
> > > If the log buffer is at least 4MB, then increasing it will not help,
> > > rather it may hurt. The log buffer is flushed when any of the the
> > > follwoing occur
> > > (i) 1 MB is filled up
> > > (2) 1/3rd is filled up
> > > (3) every 3 seconds
> > > (4) when a checkpoint occurs
> > > (5) when a commit occurs.
> > >
> > > Therefore, see if any of these could be the problem. It's easy to
> > > check #s 4 and 3.
> > >
> > > As Kirti suggested, the problem could be due to the redo logs being
> > > on a busy disk, or even a slow one.
> > >
> > > HTH.
> > >
> > > Arup
> > > ----- Original Message -----
> > > From: Deshpande, Kirti
> > > To: Multiple recipients of list ORACLE-L
> > > Sent: Thursday, March 13, 2003 8:13 PM
> > > Subject: RE: log buffer space
> > >
> > >
> > > Increasing log_buffer size is an option, if it is really small.
> > > I would also check if the redo logs are on a busy disk. If so, try
> > > moving those (or other busy data files on the same disk) to other
> > > not-so-busy disks.
> > >
> > > - Kirti
> >
> >
> > =====
> > Have a nice day !!
> > ------------------------------------------------------------
> > Best Regards,
> > K Gopalakrishnan,
> > Bangalore, INDIA.
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: K Gopalakrishnan
> > INET: kaygopal_at_yahoo.com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting services
> > ---------------------------------------------------------------------
> > 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
>> To REMOVE yourself from this mailing list, send an E-Mail message
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
>> To REMOVE yourself from this mailing list, send an E-Mail message
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: orarup_at_hotmail.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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.net -- Author: K Gopalakrishnan INET: kaygopal_at_yahoo.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).Received on Sun Mar 16 2003 - 07:28:36 CST