由drop datafile导致的Oracle bug

今天碰到了一个dataguard在10gR2的bug,不管怎么样确实是在特定的时间做了特定的操作结果碰到了特定的问题。这个问题是在10gR2的版

今天碰到了一个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.