当前位置:  数据库>oracle

由drop datafile导致的Oracle bug

    来源: 互联网  发布时间:2017-06-20

    本文导语: 今天碰到了一个dataguard在10gR2的bug,不管怎么样确实是在特定的时间做了特定的操作结果碰到了特定的问题。 这个问题是在10gR2的版本10.2.0.4.0的一个库中出现的,在做巡检的时候发现表空间使用率已经很高了,就准备加一些数据...

今天碰到了一个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无法启动的问题分析和解决
 感兴趣可以参考这个链接
结果自己按照当时的问题思路也进行相似的分析,结果还真发现了问题。
 使用下面的语句查看数据文件。
 在备库查看:
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)

Oracle 11gR2 在VMWare虚拟机中安装步骤

Debian 下 安装 Oracle 11g XE R2

Oracle Data Guard 重要配置参数

基于同一主机配置 Oracle 11g Data Guard

探索Oracle之11g DataGuard

Oracle Data Guard (RAC+DG) 归档删除策略及脚本

Oracle Data Guard 的角色转换

Oracle Data Guard的日志FAL gap问题

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法


    
 
 

您可能感兴趣的文章:

 
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术,将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外,均为转载、整理或搜集自网络。欢迎任何形式的转载,转载请注明出处。












  • 相关文章推荐
  • oracle drop table(表)数据恢复方法
  • java命名空间javax.sound.midi类sequence的类成员方法: smpte_30drop定义及介绍
  • Drop Down Panel script
  • java命名空间java.awt.dnd类droptarget的类成员方法: drop定义及介绍
  • 响应式 jQuery 插件 Tipue drop
  • java命名空间java.awt.dnd接口droptargetlistener的类成员方法: drop定义及介绍
  • jQuery 下拉列表 Custom Drop
  • Mega Drop Down Menus
  • jQuery Drop Line Menu
  • jQuery下拉菜单插件 jQuery Simple Drop Down Menu
  • 浅析删除表的几种方法(delete、drop、truncate)
  • iptables在使用drop的默认规则下,如何打开DNS服务
  • sql中的truncate、delete及drop的区别
  • drop,truncate与delete的区别
  • 详解MySQL中DROP,TRUNCATE 和DELETE的区别实现mysql从零开始
  • sqlserver 日志恢复方法(搞定drop和truncate)
  • 一次 sql server 日志恢复的记录(搞定drop和truncate)
  • 为什么使用iptables -A INPUT -p tcp --dport 7777 -j DROP指令后,只是过滤端口而不是关闭?
  • 浅析drop user与delete from mysql.user的区别
  • 关于iptables -P 如何将IP地址过滤功能的默认处理方式设置为DROP?


  • 站内导航:


    特别声明:169IT网站部分信息来自互联网,如果侵犯您的权利,请及时告知,本站将立即删除!

    ©2012-2021,,E-mail:www_#163.com(请将#改为@)

    浙ICP备11055608号-3