Mladen,
Thanks for info. So all the dirty blocks need to be written to disk after each checkpoint. After that is done the status becomes 'INACTIVE'. Just that sometimes this is very unpredictable.
My question : If a log switch always causes a implicit checkpoint then what is the need for this explicit checkpoint to be given? Thank you.
Mladen Gogala <mladen@wangtrading.com> wrote:
On 01/30/2004 01:24:26 PM, A Joshi wrote:
> Hi,
> In view v$log there is a column status. This changes from current
> (if the redo log is in use) to atcive then to inactive. Documentation
> says :
>
>
> ACTIVE: The log is active but is not the current log. It is needed
> for
> crash recovery. It may be in use for block recovery. It might or
> might
> not be archived.
>
> INACTIVE: The log is no longer needed for instance recovery. It may
> be
> in use for media recovery. It might or might not be archived.
>
> So if it is in 'ACTIVE' status : it means it is needed for
> crash/instance recovery? So what does it mean? That changes in this
> log are still not written to data files? What else? Is this related
> to
> delayed block cleanout etc or no
connection?
>
> What factor affects how long it will be in ACTIVE state before going
> to INACTIVE? What can be changed to control how long it takes. Any
> trade off?
>
> Any detailed explanation on this will be greatly appreciated. You can
> mail me direct or to the list. Thank you.
>
Status of active means that log has been switched, but not all of the
changes are written to the disk. It is, essentially, saying that DBWR
has some more work to do to catch up. The only log that is open by the
instance is the one marked "CURRENT". Here is an example:
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 CURRENT
2 INACTIVE
3 INACTIVE
SQL> alter system switch logfile;
System altered.
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 ACTIVE
2 CURRENT
3 INACTIVE
So, after the check!
point,
the CKPT has updated log file headers,
corresponding markers and termination records are written to the file,
data file headers have been updated and so has been the control file.
DBWR still has some work to do because there are still unwritten
blocks modified by transactions whose log records are in the "ACTIVE"
file. DBWR will take its time to write them down.
The only log file open by the instance is redo02:
[root@tux925 root]# fuser /data/db/OraHome1/oradata/compldb/*.log
/data/db/OraHome1/oradata/compldb/redo02.log: 6019
[root@tux925 root]#
After another checkpoint, everyhing is back to normal:
SQL> alter system checkpoint
2 /
System altered.
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 CURRENT
3 INACTIVE
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mladen Gogala
INET:
mladen@wangtrading.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@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).
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool.
Try it!
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: A Joshi
INET: ajoshi977_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 Fri Jan 30 2004 - 14:44:29 CST
