数据库System文件1文件头损坏情况的恢复

在进行本次故障重现与恢复工作之前，我们需要首先准备好实验工具，本次实验过程中全程使用sqlplus、bbed以及操作系统命令实现。
在这些所有工具中，我们需要自行编译bbed，该工具并非Oracle自带工具。
在Oracle 10g中，我们可以自行编译BBED工具，而Oracle 11g版本可以使用在10g中编译完成的BBED工具来进行本次实验：
1、编译BBED：
[oracle@db10205 ~]$ cd $ORACLE_HOME/rdbms/lib/ [oracle@db10205 lib]$ make -f ins_rdbms.mk $ORACLE_HOME/rdbms/lib/bbed
Linking BBED utility (bbed)
rm -f /oracle/product/10.2.0/db_1/rdbms/lib/bbed
gcc -o /oracle/product/10.2.0/db_1/rdbms/lib/bbed -L/oracle/product/10.2.0/db_1/rdbms/lib/ -L/oracle/product/10.b

[oracle@db10205 lib]$ mv bbed $ORACLE_HOME/bin [oracle@db10205 lib]$ which bbed
/oracle/product/10.2.0/db_1/bin/bbed

[oracle@db10205 lib]$ bbed help=y
PASSWORD - Required parameter
FILENAME - Database file name
BLOCKSIZE - Database block size
LISTFILE - List file name
MODE - [browse/edit]
SPOOL - Spool to logfile [no/yes]
CMDFILE - BBED command file name
LOGFILE - BBED log file name
PARFILE - Parameter file name
BIFILE - BBED before-image file name
REVERT - Rollback changes from BIFILE [no/yes]
SILENT - Hide banner [no/yes]
HELP - Show all valid parameters [no/yes]

【一、模拟环境说明】
1、现有数据文件
[oracle@db10205 datafile]$ ls -l
total 1001868
-rw-r----- 1 oracle oinstall 167780352 Dec 27 17:09 o1_mf_sysaux_8fno7csh_.dbf
-rw-r----- 1 oracle oinstall 314580992 Dec 27 17:09 o1_mf_system_8fno677y_.dbf --正常的SYSTEM表空间1号文件
-rw-r----- 1 oracle oinstall 314580992 Dec 27 17:14 o1_mf_system_8fno677y_.dbf.bak --正常的SYSTEM表空间1号文件的备份文件
-rw-r----- 1 oracle oinstall 20979712 Dec 27 16:33 o1_mf_temp_8fno7lss_.tmp
-rw-r----- 1 oracle oinstall 209723392 Dec 27 17:09 o1_mf_undotbs1_8fno70q5_.dbf
-rw-r----- 1 oracle oinstall 5251072 Dec 27 17:09 o1_mf_users_8fno8gxr_.dbf

2、BBED文件列表
[oracle@db10205 bbed]$ cat filelist.txt
1 /oracle/oradata/DB/datafile/o1_mf_system_8fno677y_.dbf
2 /oracle/oradata/DB/datafile/o1_mf_sysaux_8fno7csh_.dbf

BBED> copy file 1 block 111 to file 1 block 1
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) Y
File: /oracle/oradata/DB/datafile/o1_mf_system_8fno677y_.dbf (1)
Block: 1 Offsets: 0 to 511 Dba:0x00400001

00a20000 6f000000 00000000 00000105 6fa70000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> sum apply
Check value for File 1, Block 1:
current = 0xa76f, required = 0xa76f

4、损坏后尝试启动数据库
17:21:02 IDLE > startup
ORACLE instance started.

Total System Global Area 268435456 bytes
Fixed Size 2095568 bytes
Variable Size 109053488 bytes
Database Buffers 150994944 bytes
Redo Buffers 6291456 bytes
Database mounted.
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: ‘/oracle/oradata/DB/datafile/o1_mf_system_8fno677y_.dbf’
ORA-01210: data file header is media corrupt

扫描二维码关注公众号，回复： 6481048 查看本文章

5、BBED显示块类型错误
BBED> set file 1 block 1
FILE# 1
BLOCK# 1

BBED> map /v
File: /oracle/oradata/DB/datafile/o1_mf_system_8fno677y_.dbf (1)
Block: 1 Dba:0x00400001

BBED-00400: invalid blocktype (00)

本段总结:
在本段实验中,我们使用File 1 Block 111复写File 1 Block 1,
这样的话,在File 1中,文件头(File Header)就已经被损坏了,而若DBA不知道文件头损坏的事实的话,那么在启动时就会出现ORA-01122错误。

恢复思路：
我们知道数据文件头（File Header）有其独有的数据结构，对于File Header结构，我们可以修改其中的数据，但是对于其数据结构，我们很难手动构造，故此：在恢复过程中，我们使用从SYSAUX文件，也就是File 3中拷贝过来的File Header，并修改其中的的部分数据，使其满足File 1的文件头内容要求。

【二、构造头块结构】
复制File 3(SYSAUX)的File Header,用于构造File 1的File Header。
BBED> copy file 2 block 1 to file 1 block 1
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) Y
File: /oracle/oradata/DB/datafile/o1_mf_system_8fno677y_.dbf (1)
Block: 1 Offsets: 0 to 511 Dba:0x00400001

0ba20000 0100c000 00000000 00000104 47420000 00000000 0005200a b043645d
44420000 00000000 f1000000 00500000 00200000 03000300 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 12150000 00000000 6d5cdd2f 305cdd2f 01000000 00000000 00000000
00000000 00000000 00000000 28000000 9315df2f 27000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 02000000 06005359 53415558 00000000 00000000
00000000 00000000 00000000 00000000 03000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 75300500 00004506 e717df2f 01004506 12000000 14ab0000 10000000

<32 bytes per line>

BBED> sum apply
Check value for File 1, Block 1:
current = 0x4247, required = 0x4247

我们可以查看复制过来的File Header结构
BBED> map /v
File: /oracle/oradata/DB/datafile/o1_mf_system_8fno677y_.dbf (1)
Block: 1 Dba:0x00400001

Data File Header

struct kcvfh, 676 bytes @0
struct kcvfhbfh, 20 bytes @0
struct kcvfhhdr, 76 bytes @20
ub4 kcvfhrdb @96
struct kcvfhcrs, 8 bytes @100
ub4 kcvfhcrt @108
ub4 kcvfhrlc @112
struct kcvfhrls, 8 bytes @116
ub4 kcvfhbti @124
struct kcvfhbsc, 8 bytes @128
ub2 kcvfhbth @136
ub2 kcvfhsta @138
struct kcvfhckp, 36 bytes @484
ub4 kcvfhcpc @140
ub4 kcvfhrts @144
ub4 kcvfhccc @148
struct kcvfhbcp, 36 bytes @152
ub4 kcvfhbhz @312
struct kcvfhxcd, 16 bytes @316
word kcvfhtsn @332
ub2 kcvfhtln @336
text kcvfhtnm[30] @338
ub4 kcvfhrfn @368
struct kcvfhrfs, 8 bytes @372
ub4 kcvfhrft @380
struct kcvfhafs, 8 bytes @384
ub4 kcvfhbbc @392
ub4 kcvfhncb @396
ub4 kcvfhmcb @400
ub4 kcvfhlcb @404
ub4 kcvfhbcs @408
ub2 kcvfhofb @412
ub2 kcvfhnfb @414
ub4 kcvfhprc @416
struct kcvfhprs, 8 bytes @420
struct kcvfhprfs, 8 bytes @428
ub4 kcvfhtrt @444

ub4 tailchk @8188

BBED> print kcvfh
struct kcvfh, 676 bytes @0
struct kcvfhbfh, 20 bytes @0
ub1 type_kcbh @0 0x0b
ub1 frmt_kcbh @1 0xa2
ub1 spare1_kcbh @2 0x00
ub1 spare2_kcbh @3 0x00
ub4 rdba_kcbh @4 0x00c00001
ub4 bas_kcbh @8 0x00000000
ub2 wrp_kcbh @12 0x0000
ub1 seq_kcbh @14 0x01
ub1 flg_kcbh @15 0x04 (KCBHFCKV)
ub2 chkval_kcbh @16 0x4247
ub2 spare3_kcbh @18 0x0000
struct kcvfhhdr, 76 bytes @20
ub4 kccfhswv @20 0x00000000
ub4 kccfhcvn @24 0x0a200500
ub4 kccfhdbi @28 0x5d6443b0
text kccfhdbn[0] @32 D
text kccfhdbn[1] @33 B
text kccfhdbn[2] @34
text kccfhdbn[3] @35
text kccfhdbn[4] @36
text kccfhdbn[5] @37
text kccfhdbn[6] @38
text kccfhdbn[7] @39
ub4 kccfhcsq @40 0x000000f1
ub4 kccfhfsz @44 0x00005000
s_blkz kccfhbsz @48 0x00
ub2 kccfhfno @52 0x0003
ub2 kccfhtyp @54 0x0003
ub4 kccfhacid @56 0x00000000
ub4 kccfhcks @60 0x00000000
text kccfhtag[0] @64
text kccfhtag[1] @65
text kccfhtag[2] @66
text kccfhtag[3] @67
text kccfhtag[4] @68
text kccfhtag[5] @69
text kccfhtag[6] @70
text kccfhtag[7] @71
text kccfhtag[8] @72
text kccfhtag[9] @73
text kccfhtag[10] @74
text kccfhtag[11] @75
text kccfhtag[12] @76
text kccfhtag[13] @77
text kccfhtag[14] @78
text kccfhtag[15] @79
text kccfhtag[16] @80
text kccfhtag[17] @81
text kccfhtag[18] @82
text kccfhtag[19] @83
text kccfhtag[20] @84
text kccfhtag[21] @85
text kccfhtag[22] @86
text kccfhtag[23] @87
text kccfhtag[24] @88
text kccfhtag[25] @89
text kccfhtag[26] @90
text kccfhtag[27] @91
text kccfhtag[28] @92
text kccfhtag[29] @93
text kccfhtag[30] @94
text kccfhtag[31] @95
ub4 kcvfhrdb @96 0x00000000
struct kcvfhcrs, 8 bytes @100
ub4 kscnbas @100 0x00001512
ub2 kscnwrp @104 0x0000
ub4 kcvfhcrt @108 0x2fdd5c6d
ub4 kcvfhrlc @112 0x2fdd5c30
struct kcvfhrls, 8 bytes @116
ub4 kscnbas @116 0x00000001
ub2 kscnwrp @120 0x0000
ub4 kcvfhbti @124 0x00000000
struct kcvfhbsc, 8 bytes @128
ub4 kscnbas @128 0x00000000
ub2 kscnwrp @132 0x0000
ub2 kcvfhbth @136 0x0000
ub2 kcvfhsta @138 0x0000 (NONE)
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x00053075
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x2fdf17e7
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000012
ub4 kcrbabno @504 0x0000ab14
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
ub4 kcvfhcpc @140 0x00000028
ub4 kcvfhrts @144 0x2fdf1593
ub4 kcvfhccc @148 0x00000027
struct kcvfhbcp, 36 bytes @152
struct kcvcpscn, 8 bytes @152
ub4 kscnbas @152 0x00000000
ub2 kscnwrp @156 0x0000
ub4 kcvcptim @160 0x00000000
ub2 kcvcpthr @164 0x0000
union u, 12 bytes @168
struct kcvcprba, 12 bytes @168
ub4 kcrbaseq @168 0x00000000
ub4 kcrbabno @172 0x00000000
ub2 kcrbabof @176 0x0000
ub1 kcvcpetb[0] @180 0x00
ub1 kcvcpetb[1] @181 0x00
ub1 kcvcpetb[2] @182 0x00
ub1 kcvcpetb[3] @183 0x00
ub1 kcvcpetb[4] @184 0x00
ub1 kcvcpetb[5] @185 0x00
ub1 kcvcpetb[6] @186 0x00
ub1 kcvcpetb[7] @187 0x00
ub4 kcvfhbhz @312 0x00000000
struct kcvfhxcd, 16 bytes @316
ub4 space_kcvmxcd[0] @316 0x00000000
ub4 space_kcvmxcd[1] @320 0x00000000
ub4 space_kcvmxcd[2] @324 0x00000000
ub4 space_kcvmxcd[3] @328 0x00000000
word kcvfhtsn @332 2
ub2 kcvfhtln @336 0x0006
text kcvfhtnm[0] @338 S
text kcvfhtnm[1] @339 Y
text kcvfhtnm[2] @340 S
text kcvfhtnm[3] @341 A
text kcvfhtnm[4] @342 U
text kcvfhtnm[5] @343 X
text kcvfhtnm[6] @344
text kcvfhtnm[7] @345
text kcvfhtnm[8] @346
text kcvfhtnm[9] @347
text kcvfhtnm[10] @348
text kcvfhtnm[11] @349
text kcvfhtnm[12] @350
text kcvfhtnm[13] @351
text kcvfhtnm[14] @352
text kcvfhtnm[15] @353
text kcvfhtnm[16] @354
text kcvfhtnm[17] @355
text kcvfhtnm[18] @356
text kcvfhtnm[19] @357
text kcvfhtnm[20] @358
text kcvfhtnm[21] @359
text kcvfhtnm[22] @360
text kcvfhtnm[23] @361
text kcvfhtnm[24] @362
text kcvfhtnm[25] @363
text kcvfhtnm[26] @364
text kcvfhtnm[27] @365
text kcvfhtnm[28] @366
text kcvfhtnm[29] @367
ub4 kcvfhrfn @368 0x00000003
struct kcvfhrfs, 8 bytes @372
ub4 kscnbas @372 0x00000000
ub2 kscnwrp @376 0x0000
ub4 kcvfhrft @380 0x00000000
struct kcvfhafs, 8 bytes @384
ub4 kscnbas @384 0x00000000
ub2 kscnwrp @388 0x0000
ub4 kcvfhbbc @392 0x00000000
ub4 kcvfhncb @396 0x00000000
ub4 kcvfhmcb @400 0x00000000
ub4 kcvfhlcb @404 0x00000000
ub4 kcvfhbcs @408 0x00000000
ub2 kcvfhofb @412 0x0000
ub2 kcvfhnfb @414 0x0000
ub4 kcvfhprc @416 0x00000000
struct kcvfhprs, 8 bytes @420
ub4 kscnbas @420 0x00000000
ub2 kscnwrp @424 0x0000
struct kcvfhprfs, 8 bytes @428
ub4 kscnbas @428 0x00000000
ub2 kscnwrp @432 0x0000
ub4 kcvfhtrt @444 0x00000000

本段总结：
在本段实验中,我们从File 3(SYSAUX)中拷贝了File Header,用于覆盖File 1的File Header,而从复写后的File 1 Block 1中,我们可以看到SYSAUX的字样,这也正是File 3的表空间名称,这也是后续需要修改的内容之一。

以下部分将详细描述需要修改的内容，以及修改的过程及命令：

【三、修复头块数据】
1、Relative Data Block Address(相对文件块地址)
[ ub4 rdba_kcbh @4 0x00c00001 ]
此部分表示相对文件块地址,即本块(File 1 Block 1)的地址。共32位,前10位为文件号，后22位为块号。
原数据：00c00001，而本次模拟环境是Linux，是小字节序平台，我们需要做字节调换，调换后的数据为0100c000，而这部分内容也可以在dump过程中显示出来，转化为二进制就是0000 0000 11 00 0000 0000 0000 0000 0001，前10位为文件号，即3，后22号为块号，即1。
新数据：通过反向推理，File 1 Block 1，即为0000 0000 01 00 0000 0000 0000 0000 0001，转化为16进制为00400001，调换字节序之后为01004000。
BBED Command :
set file 1 block 1 offset 4
dump
modify /x 01004000
sum apply

2、File Size(文件大小)
[ ub4 kccfhfsz @44 0x00005000 ]
此部分修改文件大小，此部分可以从v$datafile.blocks查询出来，下面提出令一种方法，从系统文件大小推算出Oracle文件大小
原数据：5000，转化为10进制即为20480，这也是File 3的Block Number，而当前数据库Block Size为8192，故此可以计算出Oracle文件大小为20480*8192=167772160，而在操作系统中，可以看到sysaux文件的大小为167780352，167780352-167772160=8192，刚还相差一个Block，也就是说，在Oracle计算文件大小的时候，是不包括File Header的，这也就是为什么Oracle的File Size比系统中的File Size少一个Block Size的原因。
新数据，同样通过反向推理，我们从系统中的File 1文件的大小推导出其数据库文件大小，进一步推导出其调换字节序之后的16进制数据位9600。
BBED Command :
set file 1 block 1 offset 44
dump
modify /x 00960000
sum apply

3、File Number(绝对文件号)
[ ub2 kccfhfno @52 0x0003 ]
0003表示3号文件，即SYSAUX文件号为3，而SYSTEM文件号为1，故此改为0001
BBED Command :
set file 1 block 1 offset 52
dump
modify /x 0100
sum apply

4、Root Data Block(Root块地址)
[ ub4 kcvfhrdb @96 0x00000000 ]
Root块地址也就是Oracle数据库中bootstrap $对象的地址，在10g环境中，BootStrap$ 对象位于1号文件377块上，这是一个固定的位置。
00000000 全0表示0号文件0号块，也就说该文件上不存在BootStrap$对象
File 1 Block 377参照第一步中的地址结构，我们可以得到其调换字节序之后的16进制数据位79014000。
BBED Command :
set file 1 block 1 offset 96
dump
modify /x 79014000
sum apply

5、File Create SCN(文件创建SCN)
[ struct kcvfhcrs, 8 bytes @100 ]
[ ub4 kscnbas @100 0x00001512 ]
[ ub2 kscnwrp @104 0x0000 ]
从v $KaTeX parse error: Expected 'EOF', got '#' at position 53: \dotsA66 SELECT FILE#̲,NAME,CREATION_\dots$ DATAFILE;
其中1512转换成10进制为5394，即为SYSAUX File3的Create SCN。而SYSTEM File1的Create SCN为11，即B，前面补0，即0000 000B，转换字节序，即0B00 0000。
BBED Command :
set file 1 block 1 offset 100
dump
modify /x 0b00
sum apply

6、File Create Time(文件创建时间)
[ ub4 kcvfhcrt @108 0x2fdd5c6d ]
从v $KaTeX parse error: Expected 'EOF', got '#' at position 53: \dotsA66 SELECT FILE#̲,NAME,TO_CHAR(C\dots$ DATAFILE;
2fdd5c6d 转换为10进制为 803036269，也即SYSAUX File3的Create Time的数值表示。SYSTEM File1的Create Time为803036246，转化为16进制为2FDD5C56，转换字节序之后为565CDD2F。
BBED Command :
set file 1 block 1 offset 108
dump
modify /x 565cdd2f
sum apply

7、File Header Status(文件头状态标志)
[ ub2 kcvfhsta @138 0x0000 (NONE) ]
此处状态0000，表明数据库处于正常关闭状态，对于File1文件来说，该状态的值为8192，转为16进制为2000，转换字节序为0020
BBED Command :
set file 1 block 1 offset 138
dump
modify /x 0020
sum apply

8、Tablespace Number(表空间号)
[ word kcvfhtsn @332 2 ]
查询得出SYSAUX的表空间号为2，而SYSTEM表空间号为0，故此修改为0
BBED Command :
set file 1 block 1 offset 332
dump
modify /x 00
sum apply
郑州妇科医院哪家好:https://yyk.familydoctor.com.cn/21521/
9、Tablespace Name(表空间名称)
[ xt kcvfhtnm[0] @338 S ]
[ xt kcvfhtnm[1] @339 Y ]
[ xt kcvfhtnm[2] @340 S ]
[ xt kcvfhtnm[3] @341 A ]
[ xt kcvfhtnm[4] @342 U ]
[ xt kcvfhtnm[5] @343 X ]
此处需要修改AUX三个字符，修改为TEM，从314偏移位置开始的3个字节为415558，从ASCII码表查看，得出AUX，希望修改目标为TEM，其ASCII码表值为54454D
BBED Command :
set file 1 block 1 offset 341
dump
modify /x 54454d
sum apply
或者还有更为简单的修改方式,直接修改如下:
BBED Command :
set file 1 block 1 offset 341
dump
modify /c TEM
sum apply

10、Relative File Number（相对文件号）
[ ub4 kcvfhrfn @368 0x00000003 ]
3号文件为SYSAUX File3，修改为SYSTEM FIle1，即1号文件
BBED Command :
set file 1 block 1 offset 368
dump
modify /x 01
sum apply

本段总结:
本段实验过程中,我们分10个步骤一步一步的修改完了虚假文件头中的虚假数据,这些数据也是数据库启动过程中的验证数据,通过这10步的修改,数据库一般就可以回归正常状态。

目前File1的File Header已经基本恢复正常了，但是由于我们无法获取正确的File 1的on disk rba，故此在启动过程中可能需要恢复数据库或者文件，以下我们会描述修改完成之后，如何启动数据库。

【四、启动数据库】

全部修改完毕之后，尝试启动数据库：
18:35:36 IDLE > alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery if it was restored from backup, or END BACKUP if it was not
ORA-01110: data file 1: ‘/oracle/oradata/DB/datafile/o1_mf_system_8fno677y_.dbf’

报错ORA-01113: file 1 needs media recovery，报该错误，基本就已经回归正途了，由于我们已经无法得知SYSTEM File1正真的恢复起点，故此可直接recover后open数据库

18:35:42 IDLE > recover datafile 1;
Media recovery complete.
18:35:59 IDLE > alter database open;

Database altered.

自此：数据库正常启动，且后台告警日志未出现任何类似ORA-600、7445等内部错误，恢复完成！