某客户给sysaux表空间添加了数据文件，但有在操作系统层rm 删除了数据文件，更悲催的的是之前归档所在的磁盘损坏，恢复所需要的归档那是没指望了，也一年多没进行过数据库备份了，
现记录恢复过程如下：（虚拟机上重新模拟该恢复过程）
1 数据文件状态如下
sql> select file#,name,status from v$datafile;
file# name status
---------- ---------------------------------------- -------
1 /oracle/crm/zbcrm/system01.dbf system
2 /oracle/crm/zbcrm/sysaux01.dbf online
3 /oracle/crm/zbcrm/undotbs01.dbf online
4 /oracle/crm/zbcrm/users01.dbf online
5 /oracle/crm/zbcrm/sysaux02.dbf recover
2 重新生成操作系统层删除的数据文件
sql> alter database create datafile '/oracle/crm/zbcrm/sysaux02.dbf';
database altered.
注意，香港服务器，当我们用 alter database create datafile 创建数据文件时，数据文件头部scn以及rba.seq号均取自于该数据文件创建时控制文件中记录的scn和rba.seq号.
3 此刻数据文件头部信息如下：
sql> select hxfil,fhscn,fhrba_seq from x$kcvfh;
hxfil fhscn fhrba_seq
---------- ---------------- ----------
1 1047892 18
2 1047892 18
3 1047892 18
4 1047892 18
5 1026926 1
这里可以明确看出5号数据文件恢复需要从seq号为1的归档开始恢复，香港空间，但实际上seq#=1及其之后的归档已经不存在了，虚拟主机，所以如下恢复失败：
sql> recover datafile 5;
ora-00283: recovery session canceled due to errors
ora-01110: data file 5: '/oracle/crm/zbcrm/sysaux02.dbf'
ora-01157: cannot identify/lock data file 5 - see dbwr trace file
ora-01110: data file 5: '/oracle/crm/zbcrm/sysaux02.dbf'
4 用bbed调整5号数据文件如下几个偏移量
ub4 kcvfhcpc @140 ------检查点计数
ub4 kcvfhccc @148 ------总是比检查点计数少1
ub4 kcvcptim @492 ------检查点时间
ub4 kscnbas @484 ------scn的低位
ub2 kscnwrp @488 ------scn的高位
[oracle@oracle ~]$ bbed parfile=bbed.par
password:
bbed: release 2.0.0.0.0 - limited production on thu jul 25 14:26:45 2013
copyright (c) 1982, 2009, oracle and/or its affiliates. all rights reserved.
************* !!! for oracle internal use only !!! ***************