ORACLE11GDATAGUARD日志中断处理方案.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
ORACLE11GDATAGUARD日志中断处理方案

ORACLE 11G DATAGUARD 日志中断处理方案 /459544/269325 标签:ORACLE DATAGUARD 日志中断 版权声明:原创作品,谢绝转载!否则将追究法律责任。 1.现象: 今天在检查数据库时发现使用dataguard后,由于一些原因,出现了备用库日志中断的情况,检查主库与备用库时日志序列分别如下: 主库90.137(1323以后日志均未应用重做): select sequence#,applied from v$archived_log order by sequence#; 备用库90.138(因为1324-1384日志出现中断,1385序列后日志正常传送过来却无法应用重做) select sequence#,applied,name from v$archived_log order by sequence#; 2.分析: 经过查找发现由于90.138这台机器在前几天晚上三点的时候自动做了系统更新然后重启,而数据库服务没有及时开起来,导致中间一段日志出现丢失. 3.解决方法: a.从主库将中断的日志复制至从库: 因为出现了日志中断,最直接的原因是主库的日志文件没有传送过来,因此首先想到的是把主库137没有传送过来的日志复制过来,在主库的归档日志目录下将1_1324_705238277.dbf--1_1584_705238277.dbf复制到从库138的e:\log目录下 b:查看从库归档日志序列是否有变化: 此时通过select sequence#,applied,name from v$archived_log order by sequence#;查询发现在从库的日志列表中并没有出现刚才所复制的归档日志. c:将复制过来的归档日志进行注册: oracle并不会主动去扫描日志目录下多了哪些日志文件,所以需要我们手工将这些复制过来的归档日志进行注册 执行alter database register logfile ‘e:\log\1_1324DBF’; 一直到e:\log\1_1584DBF d.重新应用重做 等所有归档日志都注册成功后,再运行 alter database recover managed standby database disconnect from session; 从新复制过来的日志开始应用重做,几分钟之后,所有日志全部应用成功,data guard又开始恢复正常. 从库90.138: 至此data guard日志中断问题得以解决.

文档评论(0)

qwd513620855 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档