一个Oracle bug的手工修复(r6笔记第59天)

在上周五的时候,本来一个例行巡检,想扩充一些表空间,结果弄巧成拙,因为一个drop datafile的操作直接导致了一主两备的两个备库MRP直接抛出了ORA-600错误。 在尝试了一些方法和查看了MOS之后,除了重建备库,暂时还没有找到其它相对更快捷的方法。 因为是10.2.0.4.0的环境,为了先修复问题,自己先使用rman在主库做了备份,然后在备库直接做duplicate操作还原恢复。先搭好了一个备库,另外一个备库则先留下来,观察一下,看看有没有其它的方法,如果还是没有找到,就继续重新搭建备库。 结果在这种试试看的时候,竟然还是找到了一线希望,也非常感谢微信群内的好友都出谋划策,还是找到了一种可行的方案。 初始的问题,可以参见http://blog.itpub.net/23718752/viewspace-1797653/ 修复的思路是因为在主库中数据文件的配置是没有问题的,直接在主库生成备份控制文件,然后在备库做还原,这个时候还原成功后,如果尝试启动MRP肯定会报错,会有一个文件存在不一致的情况,这个时候我们就需要让dataguard端知道这个不一致,直接使用alter database drop datafile的操作就会把原来不一致的文件从数据字典级进行了更新。 这个过程有点类似于alter tablespace xxx drop datafile的过程,因为alter tablespace drop datafile需要在数据open阶段完成,所以我们通过这种方式也能达到同样的效果。 尝试的步骤如下: 把备库启动到nomount阶段,开始controlfile的还原。

$ rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Mon Sep 14 17:43:03 2015
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
connected to target database (not started)
RMAN> startup nomount
RMAN> restore controlfile from '/U01/backup_stage/ctl_oaqgu616_1_1';
Starting restore at 14-SEP-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=2984 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output filename=/U01/app/oracle/oradata/test/control01.ctl
output filename=/U01/app/oracle/oradata/test/control02.ctl
output filename=/U01/app/oracle/oradata/test/control03.ctl
Finished restore at 14-SEP-15

还原之后,启动到mount阶段。 RMAN> alter database mount; database mounted released channel: ORA_DISK_1 RMAN> exit 这个时候开始尝试应用日志,即MRP开始唤醒MRP开始工作。 可以看到alert日志中的内容变化:

ALTER DATABASE RECOVER  managed standby database disconnect from session  
Mon Sep 14 17:45:04 2015
Attempt to start background Managed Standby Recovery process (p)
MRP0 started with pid=16, OS id=27255
Mon Sep 14 17:45:04 2015
MRP0: Background Managed Standby Recovery process started (peak)
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery terminated with error 1110
Mon Sep 14 17:45:09 2015
Errors in file /U01/app/oracle/admin/peak/bdump/test_mrp0_27255.trc:
ORA-01110: data file 21: '/U01/app/oracle/oradata/test/test_new_index04.dbf'
ORA-01122: database file 21 failed verification check
ORA-01110: data file 21: '/U01/app/oracle/oradata/test/test_new_index04.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN
Mon Sep 14 17:45:09 2015
Errors in file /U01/app/oracle/admin/peak/bdump/test_mrp0_27255.trc:
ORA-01110: data file 21: '/U01/app/oracle/oradata/test/test_new_index04.dbf'
ORA-01122: database file 21 failed verification check
ORA-01110: data file 21: '/U01/app/oracle/oradata/test/test_new_index04.dbf'
ORA-01203: wrong incarnation of this file - wrong creation SCN
Mon Sep 14 17:45:09 2015
MRP0: Background Media Recovery process shutdown (test)
Mon Sep 14 17:45:10 2015
Completed: ALTER DATABASE RECOVER  managed standby database disconnect from session  
Mon Sep 14 17:46:21 2015

这个时候还是会和预想的差不多,MRP依旧会失败,但是不同的是,这个时候错误已经不是ORA-600的错误了。 既然这个文件存在不一致的情况,而且我们确实知道这个文件是需要手工删除的。我们就可以直接删除数据文件。 idle> alter database datafile '/U01/app/oracle/oradata/peak/peak_new_index04.dbf' offline drop; Database altered. 尝试取消日志应用 idle> recover managed standby database cancel; ORA-16136: Managed Standby Recovery not active 可见刚刚的MRP启动是失败的。 再次启动MRP idle> ALTER DATABASE RECOVER managed standby database disconnect from session ; Database altered. 再次启动MRP的时候回发现日志中出现了转机,这个时候备库这边和主库基本一致了,但是还是存在归档GAP.

alter database datafile '/U01/app/oracle/oradata/test/test_new_index04.dbf' offline drop
Mon Sep 14 17:46:21 2015
Completed: alter database datafile '/U01/app/oracle/oradata/test/test_new_index04.dbf' offline drop
Mon Sep 14 17:46:48 2015
ALTER DATABASE RECOVER  managed standby database cancel  
Mon Sep 14 17:46:48 2015
ORA-16136 signalled during: ALTER DATABASE RECOVER  managed standby database cancel  ...
Mon Sep 14 17:47:01 2015
ALTER DATABASE RECOVER  managed standby database disconnect from session 
Mon Sep 14 17:47:01 2015
Attempt to start background Managed Standby Recovery process (test)
MRP0 started with pid=16, OS id=27547
Mon Sep 14 17:47:01 2015
MRP0: Background Managed Standby Recovery process started (test)
Managed Standby Recovery not using Real Time Apply
 parallel recovery started with 15 processes
Mon Sep 14 17:47:06 2015
Waiting for all non-current ORLs to be archived...
Media Recovery Waiting for thread 1 sequence 7414
Fetching gap sequence in thread 1, gap sequence 7414-7416
Mon Sep 14 17:47:07 2015
Completed: ALTER DATABASE RECOVER  managed standby database disconnect from session 
Mon Sep 14 17:48:06 2015
FAL[client]: Failed to request gap sequence 
 GAP - thread 1 sequence 7414-7416
 DBID 1731005384 branch 680697352

这个时候发现了GAP,但是还没有开始从上次ORA-600错误的日志开始应用日志。
直接开启broker的验证会事半功倍。
DGMGRL>add database stest2 as
 connect identifier is stest2
 maintained as physical;
DGMGRL>enable database stest;
 这个时候日志中就开始忙碌起来了,关键的就是从上次失败的归档开始开启RFS接受日志了。
 Mon Sep 14 17:53:19 2015
RFS[1]: Archived Log: '/U01/app/oracle/flash_recovery_area/STEST2/archivelog/2015_09_14/o1_mf_1_7414_bzf68cq2_.arc'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 28706
RFS[2]: Identified database type as 'physical standby'
RFS[2]: Archived Log: '/U01/app/oracle/flash_recovery_area/STEST2/archivelog/2015_09_14/o1_mf_1_7415_bzf68h9y_.arc'
RFS[2]: Archived Log: '/U01/app/oracle/flash_recovery_area/STEST2/archivelog/2015_09_14/o1_mf_1_7416_bzf68hgr_.arc'
RFS[2]: Archived Log: '/U01/app/oracle/flash_recovery_area/STEST2/archivelog/2015_09_14/o1_mf_1_7426_bzf68jt8_.arc'
.....
RFS[2]: Archived Log: '/U01/app/oracle/flash_recovery_area/STEST2/archivelog/2015_09_14/o1_mf_1_7420_bzf69g71_.arc'
Mon Sep 14 17:53:51 2015
Managed Standby Recovery not using Real Time Apply
 parallel recovery started with 15 processes
Mon Sep 14 17:53:51 2015
Waiting for all non-current ORLs to be archived...
Media Recovery Log /U01/app/oracle/flash_recovery_area/STEST2/archivelog/2015_09_14/o1_mf_1_7414_bzf68cq2_.arc
Mon Sep 14 17:53:52 2015
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  NODELAY
Mon Sep 14 17:53:52 2015

MRP也可以继续应用日志了,从上次失败的地方开始。 这个时候使用DG broker来做一个简单验证。

DGMGRL> show configuration;
Configuration
  Name:                test
  Enabled:             YES
  Protection Mode:     MaxPerformance
  Fast-Start Failover: DISABLED
  Databases:
    test   - Primary database
    stest4 - Physical standby database
    stest2 - Physical standby database
Current status for "peak":
SUCCESS 

当然了问题修复了,来看看数据文件的情况,这个时候就没有问题了。

idle> select file#,df.name,df.ts#,ts.name,df.RFILE# from v$datafile df,v$tablespace ts where df.ts#=ts.ts#;
        20 /U01/app/oracle/oradata/test/test_new_data04.dbf                      9 TEST_NEW_DATA                                                        20
        21 /U01/app/oracle/oradata/test/test_new_index04.dbf                    10 TEST_NEW_INDEX                                                       21

所以通过这个案例我们可以看到,在某些情况下踩雷的时候,还是不要气馁,在不影响全局的情况下,可以根据自己的分析大胆假设,小心求证,没准还真能有所发现。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2015-09-14

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏钱塘大数据

理工男图解零维到十维空间,烧脑已过度,受不了啦!

让我们从一个点开始,和我们几何意义上的点一样,它没有大小、没有维度。它只是被想象出来的、作为标志一个位置的点。它什么也没有,空间、时间通通不存在,这就是零维度。

33430
来自专栏腾讯高校合作

【倒计时7天】2018教育部-腾讯公司产学合作协同育人项目申请即将截止!

15720
来自专栏钱塘大数据

中国互联网协会发布:《2018中国互联网发展报告》

在2018中国互联网大会闭幕论坛上,中国互联网协会正式发布《中国互联网发展报告2018》(以下简称《报告》)。《中国互联网发展报告》是由中国互联网协会与中国互联...

13550
来自专栏怀英的自我修炼

考研英语-1-导学

英二图表作文要重视。总体而言,英语一会比英语二难点。不过就写作而言,英语二会比英语一有难度,毕竟图表作文并不好写。

11910
来自专栏前端桃园

知识体系解决迷茫的你

最近在星球里群里都有小伙伴说道自己对未来的路比较迷茫,一旦闲下来就不知道自己改干啥,今天我这篇文章就是让你觉得一天给你 25 个小时你都不够用,觉得睡觉都是浪费...

21640
来自专栏Ken的杂谈

【系统设置】CentOS 修改机器名

18130
来自专栏haifeiWu与他朋友们的专栏

复杂业务下向Mysql导入30万条数据代码优化的踩坑记录

从毕业到现在第一次接触到超过30万条数据导入MySQL的场景(有点low),就是在顺丰公司接入我司EMM产品时需要将AD中的员工数据导入MySQL中,因此楼主负...

29740
来自专栏微信公众号:小白课代表

不只是软件,在线也可以免费下载百度文库了。

不管是学生,还是职场员工,下载各种文档几乎是不可避免的,各种XXX.docx,XXX.pptx更是家常便饭,人们最常用的就是百度文库,豆丁文库,道客巴巴这些下载...

44630
来自专栏FSociety

SQL中GROUP BY用法示例

GROUP BY我们可以先从字面上来理解,GROUP表示分组,BY后面写字段名,就表示根据哪个字段进行分组,如果有用Excel比较多的话,GROUP BY比较类...

5.2K20
来自专栏腾讯社交用户体验设计

ISUX Xcube智能一键生成H5

51220

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励