dataguard中MRP无法启动的问题分析和解决(r5笔记第82天)

自己手头有一套dataguard环境,因为也有些日子没有用了,结果突然心血来潮准备启动起来学习一下,突然发现在敲了命令 recover managed standby database disconnect from session之后,命令运行正常,但是后台却报了ora错误。 Sat Jun 27 23:16:39 2015 Recovery Slave PR00 previously exited with exception 1157 Errors in file /u02/dg11g/diag/rdbms/dg11g/DG11G/trace/DG11G_mrp0_6514.trc: ORA-01157: cannot identify/lock data file 7 - see DBWR trace file ORA-01110: data file 7: '/u02/dg11g/oradata/DG11G/test_new01.dbf' MRP0: Background Media Recovery process shutdown (DG11G) Sat Jun 27 23:16:39 2015 Completed: ALTER DATABASE RECOVER managed standby database disconnect from session RFS[162]: Opened log for thread 1 sequence 171 dbid 1028247664 branch 880742847 RFS[161]: Opened log for thread 1 sequence 173 dbid 1028247664 branch 880742847 RFS[160]: Opened log for thread 1 sequence 172 dbid 1028247664 branch 880742847 通过上面的日志我们可以看到,MRP进程是在做数据恢复的时候报了ora错误ora-01157 但是RFS还是没有问题,RFS主要是从主库来传输归档文件的,可以看到能够正常从主库中传输归档日志,sequence#号为171,173,172的归档日志都传输到了备库。 本来这个问题没有引起多大的关注,想可能是哪些归档文件没有用到导致的,但是发现MRP压根用不了。所以尽管归档传输完成了,但是数据变更还是应用不到备库。 查看v$archive_gap没有任何记录,说明没有归档日志apply的时候出现问题。 我们来看看这个ora问题的一些明细信息,提示是在7号数据文件的地方报了ora-01157错误。 Errors in file /u02/dg11g/diag/rdbms/dg11g/DG11G/trace/DG11G_mrp0_6514.trc: ORA-01157: cannot identify/lock data file 7 - see DBWR trace file ORA-01110: data file 7: '/u02/dg11g/oradata/DG11G/test_new01.dbf' 从官方对于这个问题的描述来看,似乎是数据文件出了问题。 $ oerr ora 01157 01157, 00000, "cannot identify/lock data file %s - see DBWR trace file" // *Cause: The background process was either unable to find one of the data // files or failed to lock it because the file was already in use. // The database will prohibit access to this file but other files will // be unaffected. However the first instance to open the database will // need to access all online data files. Accompanying error from the // operating system describes why the file could not be identified. // *Action: Have operating system make file available to database. Then either // open the database or do ALTER SYSTEM CHECK DATAFILES. 因为这个环境被折腾了不知道多少遍,反复切换,反复测试,我都不记得是哪些特殊的操作导致了这个问题了。所以这个问题还得从头来分析。 首先查看了一下/u02/dg11g/oradata/DG11G/test_new01.dbf 这个文件,发现在文件系统中竟然不存在。 但是在数据字典信息中却存在,使用的sql语句为,可以返回对应的记录来。 select name,file# from v$datafile where file#=7; 从这个情况来看,可能是在备库端误删除了这个数据文件造成的。对于删除的数据文件我们怎么来评估呢,首先得查看主库,查看主库中的文件情况,但是在主库中这个数据文件和表空间压根不存在。 这样一来这个问题就有些棘手了。 如果能够修复MRP的问题,看似这个问题就引刃而解,如果修复不了,可能这个dataguard就不可用了,可能得考虑重建一个物理备库了。 对此我们采取保守态度,带着一丝尝试看看备库能不能启动到open read only状态。 但是这三个操作的结果让我有些迷茫了。 open不了,说可能需要恢复,恢复的文件竟然是system01.dbf,尝试recover until cancel也未果。

idle> alter database open read only;
alter database open read only
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/u02/dg11g/oradata/DG11G/system01.dbf'

idle> recover database until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

idle> alter database open read only;
alter database open read only
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/u02/dg11g/oradata/DG11G/system01.dbf'

对于这个问题,如果有一个sql语句能够一针见血的解决问题就好了,自己在反复尝试之后发现还是有的,问题的解决思路就是先解决ORA-01157问题,然后dataguard中的MRP问题就能引刃而解。 对于ora-01157这个问题中的数据文件在主库中不存在,但是在备库的数据字典中存在,我们可以直接在备库中把数据字典中的问题先解决了。 idle> alter database datafile '/u02/dg11g/oradata/DG11G/test_new01.dbf' offline drop; Database altered. 然后dataguard的日志中就出现而来转机,在后台会去校验这个文件的问题,只是抛出了一个警告。Warning: Datafile 7 (/u02/ora11g/oradata/TEST11G/test_new01.dbf) is offline during full database recovery and will not be recovered 然后MRP就正常启动了。后台开始使用归档文件做数据恢复了。

alter database datafile '/u02/dg11g/oradata/DG11G/test_new01.dbf' offline drop
Completed: alter database datafile '/u02/dg11g/oradata/DG11G/test_new01.dbf' offline drop
Sat Jun 27 23:24:08 2015
ALTER DATABASE RECOVER  managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (DG11G)
Sat Jun 27 23:24:08 2015
MRP0 started with pid=25, OS id=8431
MRP0: Background Managed Standby Recovery process started (DG11G)
 started logmerger process
Sat Jun 27 23:24:13 2015
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 2 slaves
Warning: Datafile 7 (/u02/ora11g/oradata/TEST11G/test_new01.dbf) is offline during full database recovery and will not be recovered
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_121_880742847.dbf
Completed: ALTER DATABASE RECOVER  managed standby database disconnect from session
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_122_880742847.dbf
Sat Jun 27 23:24:31 2015
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_123_880742847.dbf
Recovery deleting file #7:'/u02/dg11g/oradata/DG11G/test_new01.dbf' from controlfile.
Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
Recovery dropped tablespace 'TEST_NEW'
Recovery created file /u02/dg11g/oradata/DG11G/test_new01.dbf
Successfully added datafile 7 to media recovery
Datafile #7: '/u02/dg11g/oradata/DG11G/test_new01.dbf'
Recovery deleting file #7:'/u02/dg11g/oradata/DG11G/test_new01.dbf' from controlfile.
Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
Recovery dropped tablespace 'TEST_NEW'
Recovery deleting file #7:'/u02/dg11g/oradata/DG11G/test_new01.dbf' from controlfile.
Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
Recovery dropped tablespace 'TEST_NEW'
Recovery deleting file #7:'/u02/dg11g/oradata/DG11G/test_new01.dbf' from controlfile.
Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
Recovery dropped tablespace 'TEST_NEW'
Media Recovery Log /u02/dg11g/switchover/DG11G/archivelog/1_124_880742847.dbf
Media Recovery Log /u02/dg11g/switchover/DG11G/archivelog/1_125_880742847.dbf
Recovery deleting file #7:'/u02/dg11g/oradata/DG11G/test_new01.dbf' from controlfile.
Deleted file /u02/dg11g/oradata/DG11G/test_new01.dbf
Recovery dropped tablespace 'TEST_NEW'
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_126_880742847.dbf
Sat Jun 27 23:24:49 2015
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_127_880742847.dbf
Sat Jun 27 23:25:01 2015
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_128_880742847.dbf
Sat Jun 27 23:25:17 2015
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_129_880742847.dbf
Sat Jun 27 23:25:29 2015

比较有意思的是查看日志可以看到,数据文件被反复创建删除了很多次。最后还是以drop终止。 然后就开始使用一大堆的归档文件做数据恢复了。

Sat Jun 27 23:28:30 2015
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_172_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_173_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_174_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_175_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_176_880742847.dbf
Sat Jun 27 23:28:40 2015
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_177_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_178_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_179_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_180_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_181_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_182_880742847.dbf
Sat Jun 27 23:28:52 2015
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_183_880742847.dbf
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_184_880742847.dbf

在主库中查看,redo的序列号185,备库中的序列号是184。

sys@TEST11G> select sequence#,status from v$log;
 SEQUENCE# STATUS
---------- ----------------
       184 INACTIVE
       185 CURRENT
       183 INACTIVE

在备库中查看后台进程的情况,可以看到MRP已经记录在册了。

idle> select process,status,sequence# from v$managed_standby;
PROCESS   STATUS        SEQUENCE#
--------- ------------ ----------
ARCH      CONNECTED             0
ARCH      CONNECTED             0
ARCH      CONNECTED             0
ARCH      CONNECTED             0
MRP0      WAIT_FOR_LOG        186

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-06-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏生信技能树

可以试用一下这个号称能取代GATK best practice的工具套件

逛biostar的时候无意发现了这个神器,至于为什么我会逛biostar论坛了,明天你们就知道了。

18820
来自专栏工科狗和生物喵

C++初入门,写个弱智银行卡系统

写在前面: 自从课程设计之后,我们就开始了生产实习,我们老师找的是河南卫华集团的技术部实习,经过一阵子的不适应(比如说河南这边的基本没味道的伙食,我们现在两个人...

488110
来自专栏Samego开发资源

解决Docker中ubuntu镜像安装MySQL

23040
来自专栏ThoughtWorks

TW洞见 | 敏捷回顾7步法

Paulo和TC一直在收集整理关于敏捷回顾的任何想法和活动。在这篇内容里面,他们分享了7步法来帮助你组织你的下一次回顾。 Agenda structure: 1...

40380
来自专栏蘑菇先生的技术笔记

SOA相关资料整理分享

28560
来自专栏静晴轩

Windows下效率必备软件

工欲善其事,必先利其器! 工欲善其事,必先利其器! 工欲善其事,必先利其器!重而说三。 AutoHotKey: 神器!神器!神器!当然也得看使用者咯(^__^)...

43980
来自专栏Web 开发

暑假完了,又该找时间升级老Y了

嗯,上个暑假在电脑城,两个星期赚了千把块,就给老Y小小升级了一下,买了一条三星2G DDR3 1333内存和一块日立7K500硬盘

10800
来自专栏架构师之路

一分钟理解负载LoadAverage

一、什么是Load Average? 系统负载(System Load)是系统CPU繁忙程度的度量,即有多少进程在等待被CPU调度(进程等待队列的长度)。 平均...

45680
来自专栏码神联盟

碎片化 | 第四阶段-44-struts2注解使用-视频

如清晰度低,可转PC网页观看高清版本: http://v.qq.com/x/page/u056793mnko.html 版权声明:本视频、课件属本公众号作者所...

35360
来自专栏SAP梦心的SAP分享

公司消费一卡通“变法”记

一卡通在每家公司都存在,不仅含考勤机,还会有门禁,订餐,食堂消费等。我们公司采用的是厦门舒特科技的一卡通系统,前后用了好几年了。 在我之前,一卡通的功能主要启用...

21590

扫码关注云+社区

领取腾讯云代金券