数据库

本类阅读TOP10

·SQL语句导入导出大全
·SQL Server日期计算
·SQL语句导入导出大全
·SQL to Excel 的应用
·Oracle中password file的作用及说明
·MS SQLServer OLEDB分布式事务无法启动的一般解决方案
·sqlserver2000数据库置疑的解决方法
·一个比较实用的大数据量分页存储过程
·如何在正运行 SQL Server 7.0 的服务器之间传输登录和密码
·SQL中两台服务器间使用连接服务器

分类导航
VC语言Delphi
VB语言ASP
PerlJava
Script数据库
其他语言游戏开发
文件格式网站制作
软件工程.NET开发
DataGuard - ORA-00261错误

作者:未知 来源:月光软件站 加入时间:2005-2-28 月光软件站

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

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

RFS: Successfully 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没有被启用而引起的,但是我这里的情况明显是已经被启用了。




相关文章

相关软件