Home » RDBMS Server » Server Administration » LGWR - sequence
LGWR - sequence [message #526456] Tue, 11 October 2011 03:20 Go to next message
hanner
Messages: 90
Registered: August 2011
Location: at HOME
Member
Hi guys,

not too sure is this the correct understanding of how this processer work.

When there is a change vector, the LGWR will write the changes to the log buffer and also in a real time, flushes it from the log buffer to the current online redo log group (which is in the disk).

When the current online redo log group, members are full (all of them), a log switch happen(done by the LGWR) which will first, if archive log mode is on, will archived that particular 'full' online redo log group(current) to the place you have specify in your archive log dest. The 2nd online redo log group will kick in to become the current group and the cycle continue... .so on and so forth.

Am i right on the above?
Re: LGWR - sequence [message #526466 is a reply to message #526456] Tue, 11 October 2011 03:58 Go to previous messageGo to next message
Michel Cadot
Messages: 58933
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
Quote:
When there is a change vector, the LGWR will write the changes to the log buffer and also in a real time, flushes it from the log buffer to the current online redo log group (which is in the disk).

Not exactly. The flush happens only at end of transaction or on some events like the buffer is somewhat full, it is long enough since it has not been flushed...

Quote:
When the current online redo log group, members are full (all of them), a log switch happen(done by the LGWR) which will first, if archive log mode is on, will archived that particular 'full' online redo log group(current) to the place you have specify in your archive log dest.

Not exactly, archiving is asynchroneous with the log switch.
When there is a log switch, the archiver process (ARC) is awaken to archive the log. Log writer (LGWR) does not wait for the archiver to go to the next log group.

Regards
Michel
Re: LGWR - sequence [message #526478 is a reply to message #526466] Tue, 11 October 2011 04:32 Go to previous messageGo to next message
hanner
Messages: 90
Registered: August 2011
Location: at HOME
Member
Quote:
When there is a log switch, the archiver process (ARC) is awaken to archive the log. Log writer (LGWR) does not wait for the archiver to go to the next log group.


so while the ARC is doing the archiving, the LGWR will move on to the 2nd online redo log group ( or available online redo log group ).
Re: LGWR - sequence [message #526481 is a reply to message #526478] Tue, 11 October 2011 04:34 Go to previous messageGo to next message
hanner
Messages: 90
Registered: August 2011
Location: at HOME
Member
Quote:
archiving is asynchroneous with the log switch.


Quote:
the archiver process (ARC) is awaken to archive the log


i guess i am right .
Re: LGWR - sequence [message #526486 is a reply to message #526456] Tue, 11 October 2011 04:54 Go to previous messageGo to next message
John Watson
Messages: 4514
Registered: January 2010
Location: Global Village
Senior Member
Quote:
When there is a change vector, the LGWR will write the changes to the log buffer and also in a real time, flushes it from the log buffer to the current online redo log group
No, this is wrong. Firstly, it is your server process that writes change vectors to the log buffer, not the LGWR. Secondly, LGWR writes the buffer to disc in real time when you issue a COMMIT but in all other circumstances, the write is not in real time: it is delayed until one of a number of other triggers causes LGWER to write.
Re: LGWR - sequence [message #526488 is a reply to message #526481] Tue, 11 October 2011 04:56 Go to previous messageGo to next message
Michel Cadot
Messages: 58933
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
hanner wrote on Tue, 11 October 2011 11:34
i guess i am right .


Yes.

Regards
Michel

Re: LGWR - sequence [message #526523 is a reply to message #526486] Tue, 11 October 2011 08:10 Go to previous messageGo to next message
hanner
Messages: 90
Registered: August 2011
Location: at HOME
Member
Quote:

Firstly, it is your server process that writes change vectors to the log buffer, not the LGWR.


So when comes to DBWR, this process write dirty buffer to disk. So does the server process writes, the changes to the dirty buffer too?

Quote:

it is delayed until one of a number of other triggers causes LGWER to write.


not too sure what you mean by triggers. But this is what i got:

When will LGWR flush the log buffer to disk?
- On COMMIT;
- when the buffer is one-third full
- just before DBWn writes.
Re: LGWR - sequence [message #526524 is a reply to message #526523] Tue, 11 October 2011 08:15 Go to previous messageGo to next message
hanner
Messages: 90
Registered: August 2011
Location: at HOME
Member
Quote:

Firstly, it is your server process that writes change vectors to the log buffer, not the LGWR.


Is there a way to identify the process name?

from v$process ?
from v$sessions?

Re: LGWR - sequence [message #526531 is a reply to message #526523] Tue, 11 October 2011 08:35 Go to previous message
Michel Cadot
Messages: 58933
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
Quote:
So when comes to DBWR, this process write dirty buffer to disk. So does the server process writes, the changes to the dirty buffer too?

Server process writes the dirty buffers into memory, DBWR write the dirty buffers from memory to disk.

Quote:
When will LGWR flush the log buffer to disk?

There are many reasons, no need to know exactly which ones they are as they may change from version to version.
Often listed: buffer 1/3 full, buffer 1M full, every 3 seconds, on commit...

Quote:
Is there a way to identify the process name?

The process has no name, its id can be found in v$process.

Regards
Michel


Previous Topic: segment - programmer (merged 2)
Next Topic: SYSTEM, sysdba, sysoper
Goto Forum:
  


Current Time: Thu Aug 28 18:50:11 CDT 2014

Total time taken to generate the page: 0.11545 seconds