一、准备工作
1.环境介绍
数据库版本：Oracle 11.2.0.4
工具：bbed
2.数据库创建测试环境
create tablespace test_tbs datafile '/u01/app/oracle/oradata/ora11g/test_tbs01.dbf' size 10M autoextend on;
create user louis identified by 123 default tablespace test_tbs;
grant connect,dba to louis;
conn louis/123;
create table t1 as select * from dba_tables;
create table t2 (id number,name varchar2(20));
insert into t2 values(1,'aaa');
insert into t2 values(2,'bbb');
insert into t2 values(3,'ccc');
insert into t2 values(4,'ddd');
insert into t2 values(5,'eee');
insert into t2 values(6,'fff');
insert into t2 values(7,'ggg');
commit;
3.编译bbed
在9i/10g中连接生成bbed:
cd $ORACLE_HOME/rdbms/lib
make-f ins_rdbms.mk $ORACLE_HOME/rdbms/lib/bbed
OracleDatabase 11g中缺省的未提供BBED库文件，但是可以用10g的文件编译出来，需要先从10g中复制如下文件到相应目录，然后再执行上述连接命令，参考如下步骤：
（1）复制Oracle 10g文件
Copy $ORA10g_HOME/rdbms/lib/ssbbded.o to$ORA11g_HOME/rdbms/lib
Copy $ORA10g_HOME/rdbms/lib/sbbdpt.o to $ORA11g_HOME/rdbms/lib
Copy $ORA10g_HOME/rdbms/mesg/bbedus.msb to $ORA11g_HOME/rdbms/mesg
Copy $ORA10g_HOME/rdbms/mesg/bbedus.msg to $ORA11g_HOME/rdbms/mesg
Copy $ORA10g_HOME/rdbms/mesg/bbedar.msb to $ORA11g_HOME/rdbms/mesg --木有这个文件了。
（2）编译
make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk BBED=$ORACLE_HOME/bin/bbed $ORACLE_HOME/bin/bbed
二、分析数据文件
1.查看数据字典
查看新建的两个表的区块分布：
SQL> select extent_id,file_id,block_id,blocks from dba_extents where segment_name='T1' and owner='LOUIS' order by extent_id;
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
--------- ------- -------- ------
0 9 128 8
1 9 136 8
2 9 144 8
3 9 152 8
4 9 160 8
5 9 168 8
6 9 176 8
7 9 184 8
8 9 192 8
9 9 200 8
10 9 208 8
11 9 216 8
12 9 224 8
13 9 232 8
SQL> select extent_id,file_id,block_id,blocks from dba_extents where segment_name='T2' and owner='LOUIS' order by extent_id;
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 9 240 8
总结：新建的表空间数据文件id号为9，T1表有14个extent，t2表只有1个extent。每个区大小为8个块（8*8192），第一个表是从9号文件第128个块开始存储的。也就是说一个数据文件的前128个块（0-127），是数据文件头，保留，存放系统信息的。
2 使用bbed查看数据文件
编辑filelist
set pages 200
select file#||' '||name||' '||bytes from v$datafile;
[oracle@test2 bbed]$ vi filelist.txt
1 /u01/app/oracle/oradata/ora11g/system01.dbf 796917760
2 /u01/app/oracle/oradata/ora11g/sysaux01.dbf 671088640
3 /u01/app/oracle/oradata/ora11g/undotbs01.dbf 78643200
4 /u01/app/oracle/oradata/ora11g/users01.dbf 5242880
5 /u01/app/oracle/oradata/ora11g/tbs11_01.dbf 104857600
6 /u01/app/oracle/oradata/ora11g/test01.dbf 104857600
7 /u01/app/oracle/oradata/ora11g/test1_01.dbf 104857600
8 /u01/app/oracle/oradata/ora11g/tbs11_02.dbf 104857600
9 /u01/app/oracle/oradata/ora11g/test_tbs01.dbf 10485760
编辑bbed参数文件
[oracle@test2 bbed]$ vi bbed.par
blocksize=8192
listfile=/home/oracle/bbed/filelist.txt
mode=edit
查看9号文件的 第一个块
BBED> set file 10 block 1
FILE# 10
BLOCK# 1
BBED> d
File: /u01/app/oracle/oradata/ora11g/test_tbs01.dbf (10)
Block: 1 Offsets: 0 to 511 Dba:0x02800001
------------------------------------------------------------------------
0ba20000 01004002 00000000 00000104 d8730000 00000000 0004200b d2287c0c
4f524131 31470000 28320000 00050000 00200000 09000300 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 420e0602 00000000 24f5d043 e6d48a36 97c9fa01 00000000 00000000
00000000 00000000 00000400 02000000 00000000 01000000 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 0c000000 08005445 53545f54 42530000 00000000
00000000 00000000 00000000 00000000 09000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
c80d8836 18c0f901 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 450e0602 00000000 24f5d043 01000000 62000000 89000000 10000000
<32 bytes per line>
BBED> map /v
File: /u01/app/oracle/oradata/ora11g/test_tbs01.dbf (10)
Block: 1 Dba:0x02800001
------------------------------------------------------------
Data File Header
struct kcvfh, 860 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
sword 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> set block 2
BLOCK# 2
BBED> map /v
File: /u01/app/oracle/oradata/ora11g/test_tbs01.dbf (10)
Block: 2 Dba:0x02800002
------------------------------------------------------------
BBED-00400: invalid blocktype (29)
一直到第130个块都是invalid blocktype
BBED> set block 130
BLOCK# 130
BBED> map /v
File: /u01/app/oracle/oradata/ora11g/test_tbs01.dbf (10)
Block: 130 Dba:0x02800082
------------------------------------------------------------
BBED-00400: invalid blocktype (35)
第131个块
BBED> set block 131
BLOCK# 131
BBED> map /v
File: /u01/app/oracle/oradata/ora11g/test_tbs01.dbf (10)
Block: 131 Dba:0x02800083
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
ub1 type_kcbh @0
ub1 frmt_kcbh @1
ub1 spare1_kcbh @2
ub1 spare2_kcbh @3
ub4 rdba_kcbh @4
ub4 bas_kcbh @8
ub2 wrp_kcbh @12
ub1 seq_kcbh @14
ub1 flg_kcbh @15
ub2 chkval_kcbh @16
ub2 spare3_kcbh @18
struct ktbbh, 96 bytes @20
ub1 ktbbhtyp @20
union ktbbhsid, 4 bytes @24
struct ktbbhcsc, 8 bytes @28
sb2 ktbbhict @36
ub1 ktbbhflg @38
ub1 ktbbhfsl @39
ub4 ktbbhfnx @40
struct ktbbhitl[3], 72 bytes @44
struct kdbh, 14 bytes @124
ub1 kdbhflag @124
sb1 kdbhntab @125
sb2 kdbhnrow @126
sb2 kdbhfrre @128
sb2 kdbhfsbo @130
sb2 kdbhfseo @132
sb2 kdbhavsp @134
sb2 kdbhtosp @136
struct kdbt[1], 4 bytes @138
sb2 kdbtoffs @138
sb2 kdbtnrow @140
sb2 kdbr[28] @142
ub1 freespace[1058] @198
ub1 rowdata[6932] @1256
ub4 tailchk @8188
如果说0-127个块是系统保留块，而系统只使用了第1个块，其他127个块不用，很好理解，但是从129个快应该是标准的数据块，而且Oracle视图也显示表T1的区是从第128个块开始分配的，为什么第129和130块不能使用bbed读取呢？
我们可以使用Oracle的system DUMP来分别看下9号数据文件的第1、129、130、131块分别存放了什么数据，有什么不同。
SQL> alter session set tracefile_identifier='block_dump';
SQL> alter system dump datafile 9 block 1;
SQL> alter system dump datafile 9 block 2;
SQL> alter system dump datafile 9 block 129;
SQL> alter system dump datafile 9 block 130;
SQL> alter system dump datafile 9 block 131;
cd /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/
more ora11g_ora_3337_block_dump.trc
9号文件数据块数据类型
1号块：file header 文件头块
2-127 号块：0x1d=KTFB Bitmapped File Space Header 保留，但里面数据不空，不知道存储的啥信息
128号块：0x20=FIRST LEVEL BITMAP BLOCK L1 位图信息
129号块：0x21=SECOND LEVEL BITMAP BLOCK L2 位图信息
130号块：0x23=PAGETABLE SEGMENT HEADER 段头信息
131号块以后： 0x06=trans data 数据块
可以通过数据库字典验证
SQL> select header_file,header_block from dba_segments where segment_name='T1' and owner='LOUIS';
HEADER_FILE HEADER_BLOCK
----------- ------------
9 130
SQL> select dbms_rowid.rowid_relative_fno(rowid) fno,
2 dbms_rowid.rowid_block_number(rowid) block_id,
3 dbms_rowid.rowid_row_number(rowid) row_id
4 from louis.t1 where rownum=1;
FNO BLOCK_ID ROW_ID
---------- ---------- ----------
9 131 0
SQL>
确定数据文件各个块的类型分布，下面就分析下1号块（file header）存储的信息了。
1号块有很多结构体，我们逐一分析
结构体：kcvfhbfh ：数据块信息
BBED> p kcvfhbfh
ub1 type_kcbh @0 0x0b
ub1 frmt_kcbh @1 0xa2
ub1 spare1_kcbh @2 0x00
ub1 spare2_kcbh @3 0x00
ub4 rdba_kcbh @4 0x02400001
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 0x73d8
ub2 spare3_kcbh @18 0x0000
type_kcbh ：块类型
frmt_kcbh ：块格式 a1 为oracle 7 a2为Oralce 8i+
spare1_kcbh :保留
spare2_kcbh ：保留
rdba_kcbh ：数据块地址
bas_kcbh ：SCN Base
wrp_kcbh ：SCN Wrap
seq_kcbh ：Sequence number, incremented for every change made to the block at the same SCN
flg_kcbh ：0x01 New Block
0x02 Delayed Logging Change advanced SCN/seq 0x04 Check value saved - block XOR‘s to zero
0x08 Temporary block
chkval_kcbh ：Optional block checksum (if DB_BLOCK_CHECKSUM=TRUE)
spare3_kcbh ：Transaction Fixed Header Structure
结构体 kcvfhhdr :数据库信息
BBED> p kcvfhhdr
struct kcvfhhdr, 76 bytes @20
ub4 kccfhswv @20 0x00000000
ub4 kccfhcvn @24 0x0b200400
ub4 kccfhdbi @28 0x0c7c28d2
text kccfhdbn[0] @32 O
text kccfhdbn[1] @33 R
text kccfhdbn[2] @34 A
text kccfhdbn[3] @35 1
text kccfhdbn[4] @36 1
text kccfhdbn[5] @37 G
text kccfhdbn[6] @38
text kccfhdbn[7] @39
ub4 kccfhcsq @40 0x00003228
ub4 kccfhfsz @44 0x00000500
s_blkz kccfhbsz @48 0x00
ub2 kccfhfno @52 0x0009
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
kccfhdbi :DBID
结构体：kcvfhckp
为了方便观看，我们按十进制输出
BBED> p /d kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 33951301
ub2 kscnwrp @488 0
ub4 kcvcptim @492 1137767716
ub2 kcvcpthr @496 1
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 98
ub4 kcrbabno @504 137
ub2 kcrbabof @508 16
ub1 kcvcpetb[0] @512 2
ub1 kcvcpetb[1] @513 0
ub1 kcvcpetb[2] @514 0
ub1 kcvcpetb[3] @515 0
ub1 kcvcpetb[4] @516 0
ub1 kcvcpetb[5] @517 0
ub1 kcvcpetb[6] @518 0
ub1 kcvcpetb[7] @519 0
kscnbas：数据文件的 SCN号
kcvcptim：时间，在服务器器内存储时间的方式就是一段长数字，
kcvcpthr：线程
kcrbaseq:sequence#
三、应用实践
我们知道了一个数据文件存放的各个数据块类型，和文件头块存放的信息后，就可以使用bbed来修改内容了。
一般情况下不建议手动修改文件内容的，很容易造成数据块不一致，导致数据库无法正常启动。
但是下面这些场景可以使用bbed来援救数据：
- SYSTEM表空间启动区产生坏块
- UNDO表空间坏块
- 缺少归档，恢复出来的数据文件头SCN号与控制文件SCN号不一致
一般我们很少使用bbed修改数据信息，大部分是修改元数据和系统信息，保证数据库能正常OPEN。
1、数据库全备
backup database;
2、使用BBED修改数据文件头SCN号
SQL> conn louis/123;
Connected.
SQL> select * from t2;
ID NAME
---------- --------------------
1 aaa
2 bbb
3 ccc
4 ddd
5 eee
6 fff
7 ggg
7 rows selected.
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL>
假如9号数据文件丢失，需要进行恢复，或者后来对T1有误操作，需要异机恢复到一个其他的时间点，但是没有归档。
启动数据库到mount状态：
SQL> startup mount
ORACLE instance started.
Total System Global Area 1586708480 bytes
Fixed Size 2253624 bytes
Variable Size 1023413448 bytes
Database Buffers 553648128 bytes
Redo Buffers 7393280 bytes
Database mounted.
SQL>
转储9号数据文件
RMAN> restore datafile 9;
尝试打开数据库
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 9 needs media recovery
ORA-01110: data file 9: '/u01/app/oracle/oradata/ora11g/test_tbs01.dbf'
9号数据文件需要介质恢复，尝试恢复9号数据文件
RMAN> recover datafile 9;
Starting recover at 26-MAY-23
using channel ORA_DISK_1
starting media recovery
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/26/2023 00:12:58
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 102 and starting SCN of 33967922 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 101 and starting SCN of 33967917 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 100 and starting SCN of 33967850 found to restore
提示缺少归档日志，现在只能异常恢复。
我们知道数据库控制文件有一个SCN号，或者称为系统SCN号，可以通过下面sql查询：
SQL> select file#,status,CHECKPOINT_CHANGE# from v$datafile;
FILE# STATUS CHECKPOINT_CHANGE#
-------------------- ------- --------------------
1 SYSTEM 33967917
2 ONLINE 33967917
3 ONLINE 33967917
4 ONLINE 33967917
5 ONLINE 33967917
6 ONLINE 33967917
7 ONLINE 33967917
8 ONLINE 33967917
9 ONLINE 33967917
数据文件的文件头存储每个数据文件的scn号，可以通过下面sql查询：
SQL> set line 400
SQL> set num 20
SQL> select file#,recover,checkpoint_change# from v$datafile_header;
FILE# REC CHECKPOINT_CHANGE#
-------------------- --- --------------------
1 NO 33967917
2 NO 33967917
3 NO 33967917
4 NO 33967917
5 NO 33967917
6 NO 33967917
7 NO 33967917
8 NO 33967917
9 YES 33967866
可以看到9号数据文件比其他数据文件落后，需要恢复
使用bbed查看9号文件头块
BBED> set file 9 block 1
FILE# 9
BLOCK# 1
BBED> p /d kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 33967866
ub2 kscnwrp @488 0
ub4 kcvcptim @492 1137801890
ub2 kcvcpthr @496 1
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 100
ub4 kcrbabno @504 2
ub2 kcrbabof @508 16
ub1 kcvcpetb[0] @512 2
ub1 kcvcpetb[1] @513 0
ub1 kcvcpetb[2] @514 0
ub1 kcvcpetb[3] @515 0
ub1 kcvcpetb[4] @516 0
ub1 kcvcpetb[5] @517 0
ub1 kcvcpetb[6] @518 0
ub1 kcvcpetb[7] @519 0
查看其他一致的数据文件头块
BBED> set file 8 block 1
FILE# 8
BLOCK# 1
BBED> p /d kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 33967917
ub2 kscnwrp @488 0
ub4 kcvcptim @492 1137801980
ub2 kcvcpthr @496 1
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 101
ub4 kcrbabno @504 2
ub2 kcrbabof @508 16
ub1 kcvcpetb[0] @512 2
ub1 kcvcpetb[1] @513 0
ub1 kcvcpetb[2] @514 0
ub1 kcvcpetb[3] @515 0
ub1 kcvcpetb[4] @516 0
ub1 kcvcpetb[5] @517 0
ub1 kcvcpetb[6] @518 0
ub1 kcvcpetb[7] @519 0
和8号文件不一致的有三处，kscnbas（offset 484）、kcvcptim（offset 492）、kcvcptim（offset 500）。
当然可以只改一处kscnbas，然后修改隐含参数_allow_resetlogs_corruption也可以强制open resetlogs。
下面来修改
BBED> d /v dba 9,1 offset 484 count 64
File: /u01/app/oracle/oradata/ora11g/test_tbs01.dbf (9)
Block: 1 Offsets: 484 to 547 Dba:0x02400001
-------------------------------------------------------
fa4e0602 00000000 a27ad143 01000000 l ........
64000000 02000000 10000000 02000000 l d...............
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
<16 bytes per line>
这里第一行第一列fa4e0602，对应的就是kscnbas，由于是Linux操作系统，所以是反序的，AIX是正序的。
BBED> p kcvfhckp dba 9,1
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x02064efa
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x43d17aa2
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000064
ub4 kcrbabno @504 0x00000002
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
BBED> p kcvfhckp dba 8,1
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x02064f2d
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x43d17afc
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000065
ub4 kcrbabno @504 0x00000002
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
按照8号数据文件的内容替换这三处就可以
BBED> modify /x 2d4f0602 dba 9,1 offset 484
File: /u01/app/oracle/oradata/ora11g/test_tbs01.dbf (9)
Block: 1 Offsets: 484 to 547 Dba:0x02400001
------------------------------------------------------------------------
2d4f0602 00000000 43d17afc 01000000 00000065 02000000 10000000 02000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BBED> modify /x fc7ad143 dba 9,1 offset 492
File: /u01/app/oracle/oradata/ora11g/test_tbs01.dbf (9)
Block: 1 Offsets: 492 to 555 Dba:0x02400001
------------------------------------------------------------------------
fc7ad143 01000000 64000000 02000000 10000000 02000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>
BBED> modify /x 65000000 dba 9,1 offset 500
File: /u01/app/oracle/oradata/ora11g/test_tbs01.dbf (9)
Block: 1 Offsets: 500 to 563 Dba:0x02400001
------------------------------------------------------------------------
65000000 02000000 10000000 02000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>
再次对比8号文件和9号文件的头
BBED> p kcvfhckp dba 9,1
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x02064f2d
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x43d17afc
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000065
ub4 kcrbabno @504 0x00000002
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
BBED> p kcvfhckp dba 8,1
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x02064f2d
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x43d17afc
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000065
ub4 kcrbabno @504 0x00000002
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
BBED>
一致，然后查看数据库视图
SQL> select file#,recover,checkpoint_change# from v$datafile_header;
FILE# REC CHECKPOINT_CHANGE#
-------------------- --- --------------------
1 NO 33967917
2 NO 33967917
3 NO 33967917
4 NO 33967917
5 NO 33967917
6 NO 33967917
7 NO 33967917
8 NO 33967917
9 YES 33967917
9 rows selected.
尝试打开数据库
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 9 needs media recovery
ORA-01110: data file 9: '/u01/app/oracle/oradata/ora11g/test_tbs01.dbf'
需要介质恢复 ，sqlplus下进行介质恢复
SQL> recover datafile 9;
Media recovery complete.
再次查看数据库视图，发现9号文件的rec变为NO
SQL> select file#,recover,checkpoint_change# from v$datafile_header;
FILE# REC CHECKPOINT_CHANGE#
-------------------- --- --------------------
1 NO 33967917
2 NO 33967917
3 NO 33967917
4 NO 33967917
5 NO 33967917
6 NO 33967917
7 NO 33967917
8 NO 33967917
9 NO 33988019
9 rows selected.
再次尝试打开数据库
SQL> alter database open;
Database altered.
验证数据。
SQL> select * from louis.t2;
ID NAME
-------------------- --------------------
1 aaa
2 bbb
3 ccc
4 ddd
5 eee
6 fff
7 ggg
7 rows selected.
SQL>
重要：
1）使用BBED前一定要确定次数据文件有备份，或者停库对此数据文件cp一份做下冷备。如果修改错误可以使用
undo来回滚最后一次操作，也可以使用revert是恢复自bbed 启动以来的所有修改。
2）如果使用open resetlogs启动数据库，则一定做一次数据全备，因为之前的所有备份已经不能用了。
3、使用BBED恢复SYSTEM表空间的引导区
SYSTEM的引导区为bootstrap$，Oralce启动OPEN时第一次读取的内容就是system表空间的引导区，里面内容都是一样的（在同一个大版本内），所以如果引导区的块损坏后，我们可以从测试环境的system表空间或者其他同版本的数据库的system表空间进行拷贝。
11g之前位于system表空间1号文件的378、379、380这三个块，11g位于521、522、523块上。下面语句可以 验证：
SQL> select dbms_rowid.rowid_relative_fno(rowid) fno,
2 dbms_rowid.rowid_block_number(rowid) block_id,
3 count(1)
4 from sys.bootstrap$
5 group by dbms_rowid.rowid_relative_fno(rowid),dbms_rowid.rowid_block_number(rowid) ;
FNO BLOCK_ID COUNT(1)
-------------------- -------------------- --------------------
1 521 24
1 523 15
1 522 21
SQL>
冷备system表空间
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
[oracle@test2 ora11g]$ cp system01.dbf system01_bak.dbf
模拟bootstrap$坏块
BBED> copy file 1 block 222 to file 1 block 521
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) Y
BBED> copy file 1 block 222 to file 1 block 522
BBED> copy file 1 block 222 to file 1 block 523
BBED> sum apply
Check value for File 1, Block 523:
current = 0xa79e, required = 0xa79e
尝试启动数据库
SQL> startup
ORACLE instance started.
Total System Global Area 1586708480 bytes
Fixed Size 2253624 bytes
Variable Size 1023413448 bytes
Database Buffers 553648128 bytes
Redo Buffers 7393280 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 521)
ORA-01110: data file 1: '/u01/app/oracle/oradata/ora11g/system01.dbf'
Process ID: 24827
Session ID: 1 Serial number: 5
bootstrap存在坏块，无法启动
如果此时没有备份，就可以使用其他的system表空间恢复
[oracle@test2 bbed]$ vi filelist.txt
1 /u01/app/oracle/oradata/ora11g/system01.dbf 796917760
2 /u01/app/oracle/oradata/ora11g/sysaux01.dbf 671088640
3 /u01/app/oracle/oradata/ora11g/undotbs01.dbf 78643200
4 /u01/app/oracle/oradata/ora11g/users01.dbf 5242880
5 /u01/app/oracle/oradata/ora11g/tbs11_01.dbf 104857600
6 /u01/app/oracle/oradata/ora11g/test01.dbf 104857600
7 /u01/app/oracle/oradata/ora11g/test1_01.dbf 104857600
8 /u01/app/oracle/oradata/ora11g/tbs11_02.dbf 104857600
9 /u01/app/oracle/oradata/ora11g/test_tbs01.dbf 10485760
10 /u01/app/oracle/oradata/ora11g/system01_bak.dbf 796917760 --加入system的备份文件到filelsit
BBED> copy file 10 block 521 to file 1 block 521
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) Y
BBED> copy file 10 block 522 to file 1 block 522
BBED> copy file 10 block 523 to file 1 block 523
BBED> sum apply
Check value for File 1, Block 523:
current = 0x7e7b, required = 0x7e7b
再次尝试启动数据库
[oracle@test2 ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Fri May 26 01:20:33 2023
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 1586708480 bytes
Fixed Size 2253624 bytes
Variable Size 1023413448 bytes
Database Buffers 553648128 bytes
Redo Buffers 7393280 bytes
Database mounted.
Database opened.
SQL>
启动成功！
注意：这里恢复用到system是来自之前的备份，所以filelist.txt里面的system的大小和之前一致。如果system来自其他环境的system，则需要从其他环境查询数据字典确定system大小。
4、使用bbed恢复system文件头
system表空间的文件头和其他数据文件一样，都位于数据文件的1号块（假设块号从1开始计数），而且SYSTEM的文件头不存储数据信息，就是系统信息，所以完全可以通过其他表空间的文件头来恢复（在没有备份的情况下），所以就可以将SYSAUX表空间的1号块复制到SYSTEM表空间的1号块，来进行恢复，具体步骤和上面雷同，这里就不再赘述。
5、总结
上述的三个场景一般很少出现，而且随着现代存储设备的质量提高和价格降低，一般也不会存在没有备份或者产生坏块的情景。可能使用的场景也就第一种情况，没有对归档进行备份或者归档不连续无法进行不完全恢复。
真正使用到BBED时，可能真到了穷途末路了，而且对于一些对Oracle 理解不深刻或者小白来说，手动修改数据文件也存在很大风险。 所以在生产或重要系统上，一定要有备份！另外 对生产保持敬畏之心，删除和更新操作一定慎重！！
参考：https://blog.csdn.net/tianlesoftware/article/details/5006580#
标签：分析,ub4,数据文件,kcvcpetb,00000000,text,bytes,Oracle,ub1 From： https://blog.csdn.net/qq_29431123/article/details/141244118