Home » RDBMS Server » Server Administration » redo log buffer using (Oracle / 10G Windows / 2000 server)  () 1 Vote
redo log buffer using [message #509448] Fri, 27 May 2011 16:09 Go to next message
Karlia
Messages: 40
Registered: May 2011
Location: Algiers
Member
Hi every body,

I learnt that logWriter writes in the redo log files when redo log buffer is 1/3 full,
it means that 66 % of redo log buffer are always empty and never used,
am i mistaken ?

if no, isn't a waste of memory (66 % always empty !)

thanks to every body
Re: redo log buffer using [message #509449 is a reply to message #509448] Fri, 27 May 2011 16:25 Go to previous messageGo to next message
John Watson
Messages: 8960
Registered: January 2010
Location: Global Village
Senior Member
You might have a thousand server processes writing to the log buffer, in memory. You have one log writer writing the log buffer to files, on disc. Which is faster, writing to memory or to disc? It is more than likely that at times of high activity you will be generating redo faster than it can be written to disc. That is why log writer starts writing before the buffer is full. If the buffer fills, the entire instance will hang.
Does that help?
Re: redo log buffer using [message #509459 is a reply to message #509449] Sat, 28 May 2011 00:29 Go to previous messageGo to next message
Michel Cadot
Messages: 68718
Registered: March 2007
Location: Saint-Maur, France, https...
Senior Member
Account Moderator
In other words, writing the log buffer is triggered as soon as 1/3 is full which let a filling time lag of 2/3 of the buffer to actually write it and this does not mean this 2/3 part is empty at the time of the writing.

So in time of low activity the buffer is only about 1/3 full when log writer writes it, we can see it as it writes it too often and a waste of resources but as the load is low it does not matter.
And in the time of high activity this let the time for the log writer to write the log buffer onto disk before this latter one becomes full and block database activity.

You can see that in "redo wastage" statistics in v$sysstat and compare it to "redo size" statistics.

Regards
Michel
Re: redo log buffer using [message #509460 is a reply to message #509459] Sat, 28 May 2011 01:04 Go to previous messageGo to next message
Yasir Hashmi
Messages: 304
Registered: April 2006
Senior Member
Similarly,DBWR wakes up after every 3 secs to see if there are any dirty buffers to write to disk.
BUt it is slow than LGWR as DBWR writes blocks and LGWR write bytes.So you might have seen checkpoint not complete message in the alert log due to that reason.
Re: redo log buffer using [message #509520 is a reply to message #509460] Sun, 29 May 2011 03:45 Go to previous messageGo to next message
ramoradba
Messages: 2457
Registered: January 2009
Location: AndhraPradesh,Hyderabad,I...
Senior Member
@ Yasir..
This topic is all about Redo log Buffer Not for Data base Buffer cache (DB buffer).
DBWR will write data into disks in so many situations.
Quote:
it is slow than LGWR as DBWR writes blocks and LGWR write bytes

Oracle Store data in a form of smallest unit are called "Block".DBWR writes the Dirty buffers to disk(i.e. It will insert/Store data or update data On the respected Blocks.It does n`t mean that It will write in a form of Blocks.It wlll read the Dirty buffers From Memory area SGA.Hope You understand what I am talking about.
LGWR writes redo buffer entries before DBWR writes to disks.And DBWR find any redo entry which are not written then DBWR has to signal LGWR to write the Info.You can assign upto 20 DBWR where as LGWR Only One.

As this topic is About Redo entry,If you have anything related to the Op question then You are most welcome.

Sriram Sanka
Re: redo log buffer using [message #509528 is a reply to message #509520] Sun, 29 May 2011 06:06 Go to previous message
Karlia
Messages: 40
Registered: May 2011
Location: Algiers
Member
Thanks to every body,
it's very clear now for me.
Previous Topic: ORA-04021:
Next Topic: Datafile - archivelog destination?
Goto Forum:
  


Current Time: Fri Nov 29 06:42:23 CST 2024