DataGuard - ORA-00261错误

发表于:2007-07-02来源:作者:点击数: 标签:
以下是在作failover时standby端的alertlog内容,情况时拔掉Primary的网线,模拟Primary 数据库 网络 环境突然损坏。 --下行表示standby端的standby redo log已经启用 RFS: Successfully opened standby logfile 4: @#/global/oradata/ctsdb/s td by_redo04.l

以下是在作failover时standby端的alertlog内容,情况时拔掉Primary的网线,模拟Primary数据库网络环境突然损坏。

--下行表示standby端的standby redo log已经启用

RFS: Suclearcase/" target="_blank" >ccessfully opened standby logfile 4: @#/global/oradata/ctsdb/stdby_redo04.log@#
Tue Aug 31 19:54:30 2004
Media Recovery Log /global/oradata/ctsdb/archive/arch1_8389.log
Media Recovery Waiting for thread 1 seq# 8390 (in transit)
Tue Aug 31 19:54:57 2004
Restarting dead background process QMN0
QMN0 started with pid=12
Tue Aug 31 19:55:19 2004

--开始failover,第一步
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Tue Aug 31 19:55:19 2004
Terminal Recovery: request posted
Tue Aug 31 19:55:48 2004

--在SQLPLUS端finish命令没有报错,正常结束,但是下面几行显示standby redo file并没有被正确recover
Warning: log 4 of thread 1 is being archived or modified
MRP0: Background Media Recovery terminated with error 261
Tue Aug 31 19:55:48 2004
Errors in file /export/home/oracle/app/oracle/admin/ctsdb/bdump/ctsdb_mrp0_2201.trc:
ORA-00261: log 4 of thread 1 is being archived or modified
ORA-00312: online log 4 thread 1: @#/global/oradata/ctsdb/stdby_redo04.log@#
Recovery interrupted.
MRP0: Background Media Recovery process shutdown
Tue Aug 31 19:55:48 2004
Terminal Recovery: completion detected
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FI

--failover第二步,执行switchover
Tue Aug 31 19:56:01 2004
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
Tue Aug 31 19:56:01 2004
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
Database not recovered through End-Of-REDO
Database not recovered through End-Of-REDO

--switchover报错,无法将standby转为primary
Switchover: Media recovery required - standby not in limbo
ORA-16139 signalled during: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY...

--尝试使用activate命令,同样报ORA-00261错误
Tue Aug 31 19:57:16 2004
ALTER DATABASE ACTIVATE STANDBY DATABASE
Tue Aug 31 19:57:16 2004
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE
Tue Aug 31 19:57:31 2004
Warning: log 4 of thread 1 is being archived or modified
Activate standby database received error 261
ORA-261 signalled during: ALTER DATABASE ACTIVATE STANDBY DATABASE...
Tue Aug 31 19:58:18 2004
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
Tue Aug 31 19:58:18 2004
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
Database not recovered through End-Of-REDO
Database not recovered through End-Of-REDO
Switchover: Media recovery required - standby not in limbo
ORA-16139 signalled during: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY...

--重新将standby置为管理恢复模式
Tue Aug 31 20:04:18 2004
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
Attempt to start background Managed Standby Recovery process
MRP0 started with pid=12
MRP0: Background Managed Standby Recovery process started
Tue Aug 31 20:04:22 2004
RFS: Possible.network disconnect with primary database
Tue Aug 31 20:04:24 2004
Starting datafile 1 recovery in thread 1 sequence 8390
Datafile 1: @#/global/oradata/ctsdb/system01.dbf@#
Starting datafile 2 recovery in thread 1 sequence 8390
Datafile 2: @#/global/oradata/ctsdb/undotbs01.dbf@#
Starting datafile 3 recovery in thread 1 sequence 8390
Datafile 3: @#/global/oradata/ctsdb/indx01.dbf@#
Starting datafile 4 recovery in thread 1 sequence 8390
Datafile 4: @#/global/oradata/ctsdb/tools01.dbf@#
Starting datafile 5 recovery in thread 1 sequence 8390
Datafile 5: @#/global/oradata/ctsdb/users01.dbf@#
Starting datafile 6 recovery in thread 1 sequence 8390
Datafile 6: @#/global/oradata/ctsdb/perfstat.dbf@#
Starting datafile 7 recovery in thread 1 sequence 8390
Datafile 7: @#/global/oradata/ctsdb/stk_his_data1_01.dbf@#
Starting datafile 8 recovery in thread 1 sequence 8390
Datafile 8: @#/global/oradata/ctsdb/stk_his_data2_01.dbf@#
Starting datafile 9 recovery in thread 1 sequence 8390
Datafile 9: @#/global/oradata/ctsdb/stk_his_data3_01.dbf@#
Starting datafile 10 recovery in thread 1 sequence 8390
Datafile 10: @#/global/oradata/ctsdb/stk_his_data4_01.dbf@#
Starting datafile 11 recovery in thread 1 sequence 8390
Datafile 11: @#/global/oradata/ctsdb/stk_his_ind_ts01.dbf@#
Starting datafile 12 recovery in thread 1 sequence 8390
Datafile 12: @#/global/oradata/ctsdb/stk_his_ind_ts03.dbf@#
Starting datafile 13 recovery in thread 1 sequence 8390
Datafile 13: @#/global/oradata/ctsdb/stk_his_ind_data1_01.dbf@#
Starting datafile 14 recovery in thread 1 sequence 8390
Datafile 14: @#/global/oradata/ctsdb/stk_his_ind_data2_01.dbf@#
Starting datafile 15 recovery in thread 1 sequence 8390
Datafile 15: @#/global/oradata/ctsdb/stk_his_ind_data3_01.dbf@#
Starting datafile 16 recovery in thread 1 sequence 8390
Datafile 16: @#/global/oradata/ctsdb/stk_his_ind_data4_01.dbf@#
Starting datafile 17 recovery in thread 1 sequence 8390
Datafile 17: @#/global/oradata/ctsdb/stk_his_ts01.dbf@#
Starting datafile 18 recovery in thread 1 sequence 8390
Datafile 18: @#/global/oradata/ctsdb/stk_his_ts02.dbf@#
Starting datafile 19 recovery in thread 1 sequence 8390
Datafile 19: @#/global/oradata/ctsdb/stk_inx_ts01.dbf@#
Starting datafile 20 recovery in thread 1 sequence 8390
Datafile 20: @#/global/oradata/ctsdb/stk_inx_ts02.dbf@#
Starting datafile 21 recovery in thread 1 sequence 8390
Datafile 21: @#/global/oradata/ctsdb/stk_ts01.dbf@#
Starting datafile 22 recovery in thread 1 sequence 8390
Datafile 22: @#/global/oradata/ctsdb/stk_ts02.dbf@#
Starting datafile 23 recovery in thread 1 sequence 8390
Datafile 23: @#/global/oradata/ctsdb/logmnrts01.dbf@#
Starting datafile 24 recovery in thread 1 sequence 8390
Datafile 24: @#/global/oradata/ctsdb/ts_test01.dbf@#
Starting datafile 25 recovery in thread 1 sequence 8390
Datafile 25: @#/global/oradata/ctsdb/ts_test02.dbf@#
Starting datafile 26 recovery in thread 1 sequence 8390
Datafile 26: @#/global/oradata/ctsdb/stk_his_ind_ts02.dbf@#
Starting datafile 27 recovery in thread 1 sequence 8390
Datafile 27: @#/global/oradata/ctsdb/stk_ts03.dbf@#
Media Recovery Waiting for thread 1 seq# 8390
Tue Aug 31 20:04:24 2004
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DI

--用skip standby logfile选项作failover
Tue Aug 31 20:04:40 2004
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH SKIP STANDBY LOGFILE
Tue Aug 31 20:04:40 2004
Database not recovered through End-Of-REDO
Terminal Incomplete Recovery: request posted
Tue Aug 31 20:04:54 2004
Terminal Incomplete Recovery: UNTIL CHANGE 3592753
Terminal Incomplete Recovery: End-Of-Redo log allocation
Terminal Incomplete Recovery: log 4 reserved for thread 1 seq# 8390
TERMINAL RECOVERY changing datafile format version from 8.0.0.0.0 to 9.0.0.0.0
Switching logfile format version from 8.0.0.0.0 to 9.0.0.0.0
Terminal Incomplete Recovery: clearing standby redo logs.
Terminal Incomplete Recovery: thread 1 seq# 8390 redo required
Terminal Incomplete Recovery: End-Of-Redo log /global/oradata/ctsdb/stdby_redo04.log
Identified end-of-REDO for thread 1 sequence 8390
Terminal Incomplete Recovery: end checkpoint SCN 3592754
MRP0: Media Recovery Complete
Switching logfile format version from 9.0.0.0.0 to 8.0.0.0.0
Terminal Incomplete Recovery: successful completion
Begin: Wait for standby logfiles to be archived
Tue Aug 31 20:04:55 2004
ARC0: Evaluating archive   log 4 thread 1 sequence 8390
ARC0: Beginning to archive log 4 thread 1 sequence 8390
Tue Aug 31 20:04:55 2004
ARC1: Evaluating archive   log 4 thread 1 sequence 8390
Tue Aug 31 20:04:55 2004
Creating archive destination LOG_ARCHIVE_DEST_1: @#/global/oradata/ctsdb/archive/arch1_8390.log@#
Tue Aug 31 20:04:55 2004
ARC1: Unable to archive log 4 thread 1 sequence 8390
      Log actively being archived by another process
Tue Aug 31 20:04:55 2004
ARC0: Completed archiving  log 4 thread 1 sequence 8390
Tue Aug 31 20:05:10 2004
End: All standby logfiles have been archived
Resetting standby activation ID 4038461969 (0xf0b60a11)
MRP0: Background Media Recovery process shutdown
Tue Aug 31 20:05:10 2004
Terminal Incomplete Recovery: completion detected
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FI

--failover成功,但是可以看到数据库作了resetlogs,这并不是我们希望的,而且由于skip了当前的standby redo log,所以肯定有相当的数据损失。
Tue Aug 31 20:05:12 2004
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
RESETLOGS after incomplete recovery UNTIL CHANGE 3592754
Resetting resetlogs activation ID 0 (0x0)
Online log 3 of thread 1 was previously cleared
Online log 5 of thread 0 was previously cleared
Online log 6 of thread 0 was previously cleared
Online log 7 of thread 0 was previously cleared
RESETLOGS changing datafile format version from 9.0.0.0.0 to 8.0.0.0.0
Switchover: Complete - Database shutdown required
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY

查metalink,只说这种情况是可能因为standby redo log没有被启用而引起的,但是我这里的情况明显是已经被启用了。

原文转自:http://www.ltesting.net