redo log文件的状态不正常

[复制链接]
查看11 | 回复5 | 2005-10-30 17:05:33 | 显示全部楼层 |阅读模式
我做exp/imp实验后,发现有一组redo log文件状态是stale(在下面文本中用红色做了标志),但经手工切换日志组后,状态变正常了,有谁遇到过这种情况?是什么原因
会造成这种现象,对系统有什么影响呢?
[PHP]SVRMGR> select * from v$log;
GROUP# THREAD#SEQUENCE#BYTESMEMBERSARC STATUS FIRST_CHAN FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ---------- ---------
1
1118 512000
2 YES INACTIVE
253253 20-AUG-04
2
1120 512000
2 YES INACTIVE
256380 06-SEP-04
3
1123 512000
2 YES INACTIVE
276892 08-SEP-04
4
1122 512000
2 YES INACTIVE
276383 06-SEP-04
5
1124 512000
2 NOCURRENT
277240 08-SEP-04
6
1119 62914560
2 YES INACTIVE
253293 20-AUG-04
8
11215242880
2 YES INACTIVE
256381 06-SEP-04
7 rows selected.
SVRMGR> select * from v$logfile;
GROUP# STATUSMEMBER

---------- ------- --------------------------------------------------------------------------------
1 /oracle/J03/oradata/ptest/redo01.log

2 /oracle/J03/oradata/ptest/redo02.log

3 /oracle/J03/oradata/ptest/redo03.log

4 /oracle/J03/oradata/ptest/redo04.log

1 /oracle/J03/oradata/ptest/redo01b.log

2 /oracle/J03/oradata/ptest/redo02b.log

3 /oracle/J03/oradata/ptest/redo03b.log

4 /oracle/J03/oradata/ptest/redo04b.log

5 /oracle/J03/oradata/ptest/redo05.log

5 /oracle/J03/oradata/ptest/redo05b.log

6 /oracle/J03/oradata/ptest/redo06.log

6 /oracle/J03/oradata/ptest/redo06b.log

8 'STALE' /oracle/J03/oradata/ptest/redo08.log

8 'STALE' /oracle/J03/oradata/ptest/redo08b.log

14 rows selected.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> ^Calter system switch logfile;
Statement processed.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> select * from v$log;
GROUP# THREAD#SEQUENCE#BYTESMEMBERSARC STATUS FIRST_CHAN FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ---------- ---------
1
1132 512000
2 YES INACTIVE
277495 08-SEP-04
2
1134 512000
2 NOCURRENT
277497 08-SEP-04
3
1130 512000
2 YES INACTIVE
277493 08-SEP-04
4
1129 512000
2 YES INACTIVE
277492 08-SEP-04
5
1131 512000
2 YES INACTIVE
277494 08-SEP-04
6
1133 62914560
2 YES INACTIVE
277496 08-SEP-04
8
11285242880
2 YES INACTIVE
277491 08-SEP-04
7 rows selected.
SVRMGR> select * from v$logfile;
GROUP# STATUSMEMBER

---------- ------- --------------------------------------------------------------------------------
1 /oracle/J03/oradata/ptest/redo01.log

2 /oracle/J03/oradata/ptest/redo02.log

3 /oracle/J03/oradata/ptest/redo03.log

4 /oracle/J03/oradata/ptest/redo04.log

1 /oracle/J03/oradata/ptest/redo01b.log

2 /oracle/J03/oradata/ptest/redo02b.log

3 /oracle/J03/oradata/ptest/redo03b.log

4 /oracle/J03/oradata/ptest/redo04b.log

5 /oracle/J03/oradata/ptest/redo05.log

5 /oracle/J03/oradata/ptest/redo05b.log

6 /oracle/J03/oradata/ptest/redo06.log

6 /oracle/J03/oradata/ptest/redo06b.log

8 /oracle/J03/oradata/ptest/redo08.log

8 /oracle/J03/oradata/ptest/redo08b.log

14 rows selected.
[/PHP]
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
可能是新添的日志group
stale表示此文件内容不完全
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
不是新添的了,是20天前加的,刚加的时候有类似的情况,后来手工切换后正常了。不知现在为什么又有问题。
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
哪位赐教,这种情况是否属于正常的情形之一?
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
On metalink's note 43746.1 it says:
The STALE status indicates that a member of a logfile group is incomplete in
terms of the redo it contains. Marking a member STALE prevents the user from
being able to drop it before that logfile group is archived. There are 3 ways
(in 7.1 code) whereby a member could become stale:
1) When building the logfile entry in the controlfile after media
recovery and using resetlogs/noresetlogs we set all members to STALE
- to force archiving before any log member can be dropped.
2) When recovering after a crash also we are not sure which member of a
logfile group had the last redo piece written to it, so we must make sure that
ALL log members are archived before they can be dropped.
Marking them STALE achieves this - it indicates that the log
information is not complete in any one member, so all are needed to reconstruct
during archiving.

3) If a write error occurs when writing to a member it is marked stale,
and if the max error count has been exceeded for that file it is closed. This
will alert the archiver to look at the other log members to complete the
logfile.
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
我已经记不很清楚当时的情形了,反正是删了加加了删且各组大小也不一样地乱试一通。最可能是第二条了,因为在发生在此情形前试过shutdown abort了.
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行