最近处理了一起由于用户操作错误导致的数据库无法打开的情况。

用户数据库为windows 64bit，数据库版本为11.2.0.1，非归档模式。由于异常断电，数据库无法正常打开，而且经过用户的判断使用了错误的offline drop操作。导致数据库打开后，日志文件切换过多，无法使用recover命令。

因为中间没有做其他操作，所以接到case后，这里将受损的几个数据文件copy到linux下使用bbed进行修改，再copy回windows，成功跳过recover，打开了offline drop的数据文件。

情景还原：

sys@UTF8A> select name ,checkpoint_change# from v$datafile ;
 
NAME                                              CHECKPOINT_CHANGE#
--------------------------------------------------------------------
/u01/apps/oracle/oradata/utf8a/system01.dbf                   1040256
/u01/apps/oracle/oradata/utf8a/sysaux01.dbf                   1040256
/u01/apps/oracle/oradata/utf8a/undotbs01.dbf                  1040256
/u01/apps/oracle/oradata/utf8a/users01.dbf                    1039896
 
 
sys@UTF8A> select sequence#, group#,first_change#,statusfrom v$log ;
 
 SEQUENCE#    GROUP# FIRST_CHANGE# STATUS
---------- ---------- -----------------------------
       19          1       1040256 CURRENT
       17          2       1040250 INACTIVE
       18          3       1040253 INACTIVE
 
 
sys@UTF8A> recover datafile 4  ;
ORA-00279: change 1039896 generated at03/30/2015 09:31:05 needed for thread 1
ORA-00289: suggestion :/u01/apps/oracle/product/11.2.0/dbhome_1/dbs/arch1_12_827004096.dbf
ORA-00280: change 1039896 for thread 1 isin sequence #12
 
 
Specify log: {=suggested |filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log'/u01/apps/oracle/product/11.2.0/dbhome_1/dbs/arch1_12_827004096.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file ordirectory
Additional information: 3
 
 
ORA-00308: cannot open archived log'/u01/apps/oracle/product/11.2.0/dbhome_1/dbs/arch1_12_827004096.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file ordirectory
Additional information: 3

sequence已经过去，无法执行恢复，所以这里只能使用bbed修改文件头了。归档以及备份真的很重要。

block为8192。

flist：

1/u01/apps/oracle/oradata/utf8a/system01.dbf 754974720

2/u01/apps/oracle/oradata/utf8a/sysaux01.dbf 566231040

3/u01/apps/oracle/oradata/utf8a/undotbs01.dbf 83886080

4/u01/apps/oracle/oradata/utf8a/users01.dbf 9175040

如何初始化bbed环境，以及各种bbed版本的下载，见我的博客

http://blog.csdn.net/renfengjun/article/details/7944629

这里不再重复赘述。

先关闭数据库并且启动到mount状态。

sys@UTF8A> selectfile#,change#,online_status from v$recover_file ;
 
    FILE#    CHANGE# ONLINE_
---------- ---------- -------
        4    1039896 OFFLINE
 
sys@UTF8A> select name ,checkpoint_change# from v$datafile ;
 
NAME                                              CHECKPOINT_CHANGE#
--------------------------------------------------------------------
/u01/apps/oracle/oradata/utf8a/system01.dbf                   1041564
/u01/apps/oracle/oradata/utf8a/sysaux01.dbf                   1041564
/u01/apps/oracle/oradata/utf8a/undotbs01.dbf                  1041564
/u01/apps/oracle/oradata/utf8a/users01.dbf                    1039896

记得修改前先备份所有的数据库文件。

BBED> set file 4
       FILE#           4
 
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484    
  struct kcvcpscn, 8 bytes                @484    
      ub4 kscnbas                           @484      0x000fde18
     ub2 kscnwrp                          @488      0x0000
  ub4 kcvcptim                            @492      0x34321859
  ub2 kcvcpthr                            @496      0x0001
  union u, 12 bytes                       @500    
     struct kcvcprba, 12 bytes            @500    
        ub4 kcrbaseq                      @500      0x0000000c
        ub4 kcrbabno                      @504      0x00000015
        ub2 kcrbabof                      @508      0x0010
  ub1 kcvcpetb[0]                          @512      0x02
  ub1 kcvcpetb[1]                         @513      0x00
  ub1 kcvcpetb[2]                         @514      0x00
  ub1 kcvcpetb[3]                         @515      0x00
  ub1 kcvcpetb[4]                         @516      0x00
  ub1 kcvcpetb[5]                         @517      0x00
  ub1 kcvcpetb[6]                         @518      0x00
  ub1 kcvcpetb[7]                         @519      0x00
 

注意offset 484 ， kscnbas为数据文件现在的scn。