oracle 日志状态为stale

SQLDBA> SELECT * FROM V$LOGFILE;

GROUP# STATUS MEMBER
---------- ------- ------------------------------
1 STALE /oracle/7.3.4/dbs/log1P734.dbf

2 /oracle/7.3.4/dbs/log2P734.dbf

3 /oracle/7.3.4/dbs/log3P734.dbf

解决方法总结：

1，千万不要在发生stale的情况下强制关闭数据库。

2，多查询几次日志状态，看stale状态是否会消失。

3，如果再数次查询无效后，可以切换日志。

4，切换日志过户，可以执行强制检查点操作。

5，不断切换日志，强制检查点，查询，直至stale状态消失。

WARNING:

DO NOT ISSUE A SHUTDOWN ABORT BEFORE GOING THROUGH STEPS1 AND 2 BELOW.

Solution Description:
=====================

In general, the stale status of a redo log member should not be acause for
great concern, unless you observe that this happens frequentlyor
systematically. Keep in mind that a stale log is not necessarily aninvalid
log, but more of an "in-doubt" one. Once the corresponding redogroup becomes
the current one again, the stale status will go away byitself.

Here is the recommended procedure to deal with a stale redolog:

1. Issue the following query:

SELECT V2.GROUP#, MEMBER, V2.STATUS MEMBER_STATUS,
V1.STATUS GROUP_STATUS
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# AND V2.STATUS = 'STALE';

This will show you the group status for all stale log files.

2. For each stale log file,

2.a) If the GROUP_STATUS is 'INACTIVE', do nothing. Thatimplies
Oracle has already checkpointed past that redo group, andthus
its contents are no longer needed for instance recovery.
Once the redo group becomes current again, the stale statusof
the log file will go away by itself.

2.b) If the GROUP_STATUS is 'ACTIVE', go back to Step 1 andrepeat
the query a few more times. This status usually means that
the log group is no longer the current one, but thecorresponding
checkpoint has not completed yet. Unless there is a problem,
the log group should become inactive shortly.

2.c) If the GROUP_STATUS is 'CURRENT', force a log switchnow.

ALTER SYSTEM SWITCH LOGFILE;

This will also force a checkpoint. If the checkpoint
completes successfully, the contents of the redo group
are no longer needed for instance recovery. Go back to
Step 1 and repeat the query a few more times until the
log group becomes inactive.

IMPORTANT: If the stale logfile belongs to an active group
or the current group (cases 2.b and 2.c above), DO NOT ISSUE
A SHUTDOWN ABORT UNTIL THE GROUP BECOMES INACTIVE.

3. Investigate the extent of the problem.

Examine the alert.log file for this instance and the LGWR
trace file, if one can be found in your background_dump_dest.
See if there is any pattern to the problem. Do you see any
recent errors, such as ORA-312, referencing that particularlog
file? If so, there may be some corruption problem with thefile
or a problem with the I/O subsystem (disk, controllers, etc.).
If you are running any other Oracle version on any otherplatform
If there is no pattern to the problem, it is more likely an
isolated incident.

4. If you are archiving, make sure the log has been correctlyarchived.

Before archiving a redo log group, the ARCH process actually
verifies that its contents are valid. If that is not thecase,
it issues an error such as ORA-255 ("error archiving log %s
of thread %s, sequence # %s"。Therefore, if the log group to
which the stale member belongs has been successfullyarchived,
it means the redo contents of the group are good, and that
archived log can be safely used for recovery. ARCH errors, if
any, will be reported in your alert.log file and in an ARCH
trace file.

Explanation:
============

A stale redo log file is one that Oracle believes might beincomplete for some
reason. This typically happens when a temporary error prevents theLGWR
background process from writing to a redo log group member. IfOracle cannot
write to a redo log file at any one time, that log file can nolonger be
trusted, and Oracle marks it as "STALE". This indicates that thelog file
cannot be relied upon to provide all the data written to thelog.