Kamus' Oracle World

面朝大海, 春暖花开

张乐奕ID:Kamus
567052次访问,排名67好友0人,关注者1
面朝大海,春暖花开
Kamus的文章
原创 277 篇
翻译 0 篇
转载 6 篇
评论 653 篇
Kamus的公告
如果这个blog以后变成我自己的垃圾站,请不要介意:)






Subscribe in Bloglines
最近评论
cqg1220:机柜
fbirdzp:thanks from clo
zhouxz1026:写得真是太好了,水平真的很高,佩服啊!赞一个!学习了!
蜂胶
蜂蜜
Kamus:当操作系统的keepalive较大,比如10分钟,那么当网络出现问题之后,standby端在短时间内无法意识到primary端已经down掉了,因此stadnby端的standby redolog并没有正常close,此时做standby的recover时就会报ORA-00332。只有在alertlog中看到RFS进程意识到primary端已经断开了,才表示standby redolog正常……
fbirdzp:能否详细解释一下问题1:ORA-00332呢?谢谢!
文章分类
收藏
    相册
    我的下载
    我在博客中国的家
    My Favorites
    AskTom
    CNOUG
    DBA-Oracle
    ITPub.net
    Ixora
    Jeff Hunter
    Jonathan Lewis
    Oracle在线文档
    My Friends
    Biti的专栏(RSS)
    Chanel [K](RSS)
    coolyl's field(RSS)
    eygle的站点
    Fenng的blog(RSS)
    Fenng的站点
    lunar的专栏(RSS)
    Oldwain的专栏(RSS)
    Piner的专栏(RSS)
    vilen的照相本
    yangtingkun's blog(RSS)
    南半球的猫(RSS)
    猫泽西的幸福生活(RSS)
    简朴生活(RSS)
    雪狼窝
    存档
    软件项目交易
    订阅我的博客
    XML聚合  FeedSky
    订阅到鲜果
    订阅到Google
    订阅到抓虾
    订阅到BlogLines
    订阅到Yahoo
    订阅到GouGou
    订阅到飞鸽
    订阅到Rojo
    订阅到newsgator
    订阅到netvibes

    原创 DataGuard - ORA-00261错误的提出收藏

    新一篇: DataGuard - ORA-00261错误及解决方法 | 旧一篇: DataGuard - MSN教程

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

    发表于 @ 2004年08月31日 20:40:00|评论(loading...)|编辑

    新一篇: DataGuard - ORA-00261错误及解决方法 | 旧一篇: DataGuard - MSN教程

    评论:没有评论。

    发表评论  


    当前用户设置只有注册用户才能发表评论。如果你没有登录,请点击登录
    Csdn Blog version 3.1a
    Copyright © Kamus