如何用BBED使Offline的数据文件Online
我们首先回顾事件：
经了解，目前此数据库的容量为6T，ASM磁盘组空间几乎用尽，在向磁盘组增加磁盘时，由于种种原因最终导致2个数据文件offline（一个bigfile，一个smallfile）。由于数据库比较大，数据库没有备份，可怜的是，归档日志是定期清除的，当发现这个问题时，所需的归档日志已被清除，想通过常规手段使文件online已不可能，幸运的时，通过BBED最终使文件online成功，虽然后续还要一些问题，最终得以解决。
查看alert日志内容
恢复思路：
A.安装BBED(由于是10.2.0.4的库，自身就有bbed编译所需的文件)
B.找出2个Offline文件在磁盘上的位置
C.通过dd生成备份/恢复这两个数据文件头的命令
D.正常关闭数据库
E.用dd复制出2个正常的数据文件头部和2个Offline的数据文件头部
注意：这2个offline的文件头部备份2份，因为后面要修改。复制出2个正常的数据文件头部用作参考。
F.用bbed查看正常文件的头部在偏移量484到512的数值
G.用bbed修改2个offline文件头部在偏移量484到512的数值，确保Offline文件和正常文件头部的数值是一致的
H.用sqlplus连接其中一节点并启动数据库到mount
I.恢复数据文件recover datafile 67;
recover datafile 11;
J.已只读模式打开数据库
alter database open read only;
alter database datafile 11 online;
alter database datafile 67 online;
select distinct status from v$datafile;
select * from v$recover_file;
K.关闭数据库，以正常模式打开数据库
shutdown immediate
startup
L.经过一段时间观察，没有出现ora-600等异常情况
M.关闭数据库，用srvctl start database
注意：在操作前，注意备份system表空间，offline的文件，当前的控制文件，在线日志文件
备份数据文件头部
dd if=/dev/rhdisk5 of=/home/oracle/backup/1_1_264.FH bs=1048576 skip=283 count=1dd if=/dev/rhdisk8 of=/home/oracle/backup/1_2_262.FH bs=1048576 skip=116 count=1dd if=/dev/rhdisk17 of=/home/oracle/backup/2_8_261.FH bs=1048576 skip=53055 count=1dd if=/dev/rhdisk12 of=/home/oracle/backup/2_2_264.FH bs=1048576 skip=3616 count=1
BBED（通过比较发现坏的文件）
为了方便查看，后面部分省略
为了方便查看，后面部分省略
为了方便查看，后面部分省略
为了方便查看，后面部分省略
从上面我们可以看到，文件1,2头部是一样的，这2个文件是正常的，后面2个文件是Offline的文件，我们需要做的就是修改checkpoint的信息以及RBA的信息
BBED（查看Checkpoint、RBA的信息）
注意：AIX是大端，修改时顺序无需调换
先查看偏移量484到508的相信信息
修改Checkpoint、RBA的信息
修改文件3,4在偏移量484到508的相关信息，修改完成后，确认1,2,3,4偏移量在484到508的信息是一致的
用dd还原修改后的数据文件头部
dd if=/home/oracle/backup/2_8_261.FH of=/dev/rhdisk17 bs=1048576 seek=53055 count=1 conv=notrunc
dd if=/home/oracle/backup/2_2_264.FH of=/dev/rhdisk12 bs=1048576 seek=3616 count=1 conv=notrunc
查看正常打开后数据库alert日志
ALTER DATABASE RECOVER datafile 11
Tue Jul 5 23:03:43 2016
Media Recovery Start
Tue Jul 5 23:03:43 2016
SUCCESS: diskgroup ASM_DG02 was mounted
Tue Jul 5 23:03:45 2016
parallel recovery started with 15 processes
Tue Jul 5 23:03:45 2016
Media Recovery Complete (abdd1)
Tue Jul 5 23:03:45 2016
SUCCESS: diskgroup ASM_DG02 was dismounted
Tue Jul 5 23:03:45 2016
Completed: ALTER DATABASE RECOVER datafile 11
Tue Jul 5 23:03:54 2016
ALTER DATABASE RECOVER datafile 67
Media Recovery Start
Tue Jul 5 23:03:54 2016
SUCCESS: diskgroup ASM_DG02 was mounted
Tue Jul 5 23:03:54 2016
parallel recovery started with 15 processes
Tue Jul 5 23:03:54 2016
Media Recovery Complete (abdd1)
Tue Jul 5 23:03:54 2016
SUCCESS: diskgroup ASM_DG02 was dismounted
Tue Jul 5 23:03:54 2016
Completed: ALTER DATABASE RECOVER datafile 67
Tue Jul 5 23:04:16 2016
alter database open read only
Tue Jul 5 23:04:16 2016
This instance was first to open
Tue Jul 5 23:04:16 2016
SUCCESS: diskgroup ASM_DG02 was mounted
Tue Jul 5 23:04:24 2016
Picked broadcast on commit scheme to generate SCNs
Tue Jul 5 23:04:32 2016
SMON: enabling cache recovery
Tue Jul 5 23:04:32 2016
Database Characterset is ZHS16GBK
Opening with internal Resource Manager plan
where NUMA PG = 1, CPUs = 16
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: alter database open read only
Tue Jul 5 23:04:34 2016
Errors in file /u01/oracle/admin/abdd/udump/abdd1_ora_5571420.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-16000: database open for read-only access
ORA-06512: at line 2
alter database datafile 11 online
Tue Jul 5 23:08:05 2016
Starting control autobackup
Control autobackup written to DISK device
handle '+ASM_DG01/abdd/autobackup/2016_07_05/s_916434663.16892.916441687'
Completed: alter database datafile 11 online
Tue Jul 5 23:08:17 2016
alter database datafile 67 online
解决后续错误
ORA-00600: internal error code, arguments: [ktsplbfmb-sync], [], [], [], [], [], [], []
通过dbv校验数据文件，发现之前有坏块，根据file id,block id可以查到，坏块涉及的对象有2个：一个为Lob Index(一个块)，一个为Lob Segment(多个块)
尝试通过expdp导出这2个表，Lob Index损坏的表可以正常导出，然后通过move table，应用程序端出现的错误消失，Lob Segment损坏的表，无法通过expdp导出。最终通过找到损坏的表的rowid，忍痛割爱通过empty_blob()重新初始化，好在损坏的行不多，只有2行，至此问题圆满解决。
小结
在数据库上不论做什么操作，都要认真去分析调查，小心无大错。
如何修改RBA的值是关键，需要停库，参考正常的数据文件RBA信息，然后去修改Offline文件的RBA信息，确保他们都是一致的。
使用BBED时一定要注意大端小端的问题，本文仅供参考
