这个问题是在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.