最近处理了一起由于用户操作错误导致的数据库无法打开的情况。
用户数据库为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 ; NAMECHECKPOINT_CHANGE#——————————————————————–/u01/apps/oracle/oradata/utf8a/system01.dbf1040256/u01/apps/oracle/oradata/utf8a/sysaux01.dbf1040256/u01/apps/oracle/oradata/utf8a/undotbs01.dbf1040256/u01/apps/oracle/oradata/utf8a/users01.dbf1039896sys@UTF8A> select sequence#, group#,first_change#,statusfrom v$log ; SEQUENCE# GROUP# FIRST_CHANGE# STATUS———- ———- —————————–1911040256 CURRENT1721040250 INACTIVE1831040253 INACTIVEsys@UTF8A> recover datafile 4 ;ORA-00279: change 1039896 generated at03/30/2015 09:31:05 needed for thread 1ORA-00289: suggestion :/u01/apps/oracle/product/11.2.0/dbhome_1/dbs/arch1_12_827004096.dbfORA-00280: change 1039896 for thread 1 isin sequence #12Specify log: {<RET>=suggested |filename | AUTO | CANCEL}autoORA-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 statusLinux-x86_64 Error: 2: No such file ordirectoryAdditional information: 3ORA-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 statusLinux-x86_64 Error: 2: No such file ordirectoryAdditional 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版本的下载，见我的博客
这里不再重复赘述。
先关闭数据库并且启动到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 ; NAMECHECKPOINT_CHANGE#——————————————————————–/u01/apps/oracle/oradata/utf8a/system01.dbf1041564/u01/apps/oracle/oradata/utf8a/sysaux01.dbf1041564/u01/apps/oracle/oradata/utf8a/undotbs01.dbf1041564/u01/apps/oracle/oradata/utf8a/users01.dbf1039896
记得修改前先备份所有的数据库文件。
BBED> set file 4FILE#4 BBED> p kcvfhckpstruct kcvfhckp, 36 bytes@484struct kcvcpscn, 8 bytes@484ub4 kscnbas@4840x000fde18ub2 kscnwrp@4880×0000 ub4 kcvcptim@4920×34321859 ub2 kcvcpthr@4960×0001 union u, 12 bytes@500struct kcvcprba, 12 bytes@500ub4 kcrbaseq@5000x0000000cub4 kcrbabno@5040x00000015ub2 kcrbabof@5080×0010 ub1 kcvcpetb[0]@5120×02 ub1 kcvcpetb[1]@5130×00 ub1 kcvcpetb[2]@5140×00 ub1 kcvcpetb[3]@5150×00 ub1 kcvcpetb[4]@5160×00 ub1 kcvcpetb[5]@5170×00 ub1 kcvcpetb[6]@5180×00 ub1 kcvcpetb[7]@5190×00
注意offset 484 ， kscnbas为数据文件现在的scn。
使用计算器计算后0x000fde18，得到的十进制数字为1039896，确认无误，只要修改scn为最新的1041564，即可打开损坏的数据文件。
BBED> d /v dba 4,1 offset 484 count 16 File: /u01/apps/oracle/oradata/utf8a/users01.dbf(4) Block: 1Offsets: 484 to 499 Dba:0x01000001——————————————————- 18de0f00 00000000 59183234 01000000 l ……Y.24…. <16 bytes per line>
因为是这里为linux x64 ，为little endian。
1039896=18de0f00
1041564=9ce40f00
直接修改即可。
BBED> set mode editMODEEdit BBED> m /x 9ce40f dba 4,1 offset 484 File:/u01/apps/oracle/oradata/utf8a/users01.dbf (4) Block: 1Offsets: 484 to 499Dba:0x01000001———————————————————————— 9ce40f00 00000000 59183234 01000000 <32 bytes per line>BBED> m /x 9ce40f dba 4,1 offset 484 File: /u01/apps/oracle/oradata/utf8a/users01.dbf(4) Block: 1Offsets: 484 to 499Dba:0x01000001———————————————————————— 9ce40f00 00000000 59183234 01000000 <32 bytes per line> BBED> sumCheck value for File 4, Block 1:current = 0x5f67, required = 0x65e3 BBED> sum applyCheck value for File 4, Block 1:current = 0x65e3, required = 0x65e3
完成任务
而在于当时的那份心情。可是旅行的彼时那刻我的心情一直是好的吗？
