Welcome 微信登录

首页 / 数据库 / MySQL / 由drop datafile导致的Oracle bug

今天碰到了一个dataguard在10gR2的bug,不管怎么样确实是在特定的时间做了特定的操作结果碰到了特定的问题。这个问题是在10gR2的版本10.2.0.4.0的一个库中出现的,在做巡检的时候发现表空间使用率已经很高了,就准备加一些数据文件把这个问题给修复了,按理说这也是一个常规操作,没有什么可圈圈点点的地方。但是添加完数据文件之后,过了一会,就收到报警说备库出了点问题,自己还纳闷到底是什么原因导致的,带着疑问使用dgmgrl来查看了一下。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 "test":
 Warning: ORA-16607: one or more databases have failed通过这个,确实发现备库出了些问题,赶快连接到备库中,结果查看数据日志就发现原来MRP进程给停掉了。
Fri Sep 11 17:58:53 2015
 Errors in file /U01/app/Oracle/admin/test/bdump/test_mrp0_10953.trc:
 ORA-00600: internal error code, arguments: [3689], [21], [], [], [], [], [], []
 Errors with log /U01/app/oracle/flash_recovery_area/STEST4/archivelog/2015_09_11/o1_mf_1_7414_bz598mqc_.arc
 MRP0: Background Media Recovery terminated with error 600
 Fri Sep 11 17:58:55 2015
 Errors in file /U01/app/oracle/admin/test/bdump/test_mrp0_10953.trc:
 ORA-00600: internal error code, arguments: [3689], [21], [], [], [], [], [], []
 Fri Sep 11 17:59:04 2015
 Some recovered datafiles maybe left media fuzzy
 Media recovery may continue but open resetlogs may fail
 Fri Sep 11 17:59:04 2015看到这个错误,发现问题似乎还是有些奇怪,因为关联的ora错误是ora-600
带着这个疑问,首先想到的就是自己之前碰到过MRP无法启动的问题,dataguard中MRP无法启动的问题分析和解决
 感兴趣可以参考这个链接 http://www.linuxidc.com/Linux/2015-09/123006.htm
结果自己按照当时的问题思路也进行相似的分析,结果还真发现了问题。
 使用下面的语句查看数据文件。
 在备库查看:
select file#,df.name,df.ts#,ts.name,df.RFILE# from v$datafile df,v$tablespace ts
   where df.ts#=ts.ts#;
   FILE# NAME                                                                TS#                  NAME   
---------- ------------------------------------------------------------ ---------- --------------------
       20 /U01/app/oracle/oradata/test/test_new_data04.dbf                      9 TEST_NEW_DATA     
       21 /U01/app/oracle/oradata/test/test_new_index04.dbf                   9 TEST_NEW_DATA     
主库查看   FILE# NAME                                                                TS#                  NAME
---------- ------------------------------------------------------------ ---------- --------------------   
       20 /U01/app/oracle/oradata/test/test_new_data04.dbf                     9 TEST_NEW_DATA 
       21 /U01/app/oracle/oradata/test/test_new_index04.dbf                   10 TEST_NEW_INDEX
通过这个可以发现表空间的数据文件在两个库中不一致。
 这个时候联系起来ora600其实在错误里面已经暗示出了21的含义ORA-00600: internal error code, arguments: [3689], [21], [], [], [], [], [], []这个时候自己就恍然大悟了,自己在给表空间TEST_NEW_DATA添加数据文件的时候,不小心添加成了test_new_index04.dbf,结果创建好之后发现了这个问题,
 就使用alter tablespace test_new_data drop datafile "xxxxx"的方式删除了,然后又创建了一个新的数据文件test_new_data04.dbf
这么一个操作也没有什么非议之处,但是在10gR2 10.2.0.4.0里就是不行,因为有一个bug
 Bug 5623467 - Corrupt redo from ALTER TABLESPACE DROP DATAFILE (文档 ID 5623467.8)
这个bug,oracle也没有给出其它可行的意见,除了升级打补丁外,建议就是不要使用drop datafile的命令,但是我已经运行了,你说怎么办,只能重建备库了。
 当然在重建备库这个繁重的工作之外我还想做一些尝试。
 既然数据字典中不同步,对于drop的操作不支持,我就直接使用alter database  datafile ‘xxxxxx" offline drop来搞定这个问题,上次的MRP的问题在11g中就可以这么解决。
SQL> alter database datafile "/U01/app/oracle/oradata/test/test_new_index04.dbf" offline drop;
 Database altered.命令运行成功了,但是查看datafile还是没有发生变化。
   FILE# NAME                                                                TS#                  NAME   
---------- ------------------------------------------------------------ ---------- --------------------
       20 /U01/app/oracle/oradata/test/test_new_data04.dbf                      9 TEST_NEW_DATA     
       21 /U01/app/oracle/oradata/test/test_new_index04.dbf                   9 TEST_NEW_DATA     
再次尝试recover managed standby database disconnect from session发现问题依旧,还是ora-600的错误。
 这个时候想把database 启动到read only时也出问题。
SQL> alter database open read only;
 alter database open read only
 *
 ERROR at line 1:
 ORA-16004: backup database requires recovery
 ORA-01196: file 1 is inconsistent due to a failed media recovery session
 ORA-01110: data file 1: "/U01/app/oracle/oradata/test/system01.dbf"所以没有办法了,重建备库了,真是让人无奈的选择。在CentOS 6.4下安装Oracle 11gR2(x64) http://www.linuxidc.com/Linux/2014-02/97374.htmOracle 11gR2 在VMWare虚拟机中安装步骤 http://www.linuxidc.com/Linux/2013-09/89579p2.htmDebian 下 安装 Oracle 11g XE R2 http://www.linuxidc.com/Linux/2014-03/98881.htmOracle Data Guard 重要配置参数 http://www.linuxidc.com/Linux/2013-08/88784.htm基于同一主机配置 Oracle 11g Data Guard http://www.linuxidc.com/Linux/2013-08/88848.htm探索Oracle之11g DataGuard http://www.linuxidc.com/Linux/2013-08/88692.htmOracle Data Guard (RAC+DG) 归档删除策略及脚本 http://www.linuxidc.com/Linux/2013-07/87782.htmOracle Data Guard 的角色转换 http://www.linuxidc.com/Linux/2013-06/86190.htmOracle Data Guard的日志FAL gap问题 http://www.linuxidc.com/Linux/2013-04/82561.htmOracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法 http://www.linuxidc.com/Linux/2013-03/82009.htm更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12本文永久更新链接地址