1.得到文件的块大小和数据块个数
在Linux和Unix上,oracle提供了一个小工具dbfsize用于查看文件块大小
(可以参看[ID：360032.1]How to detect and fix a corruption in the datafile OS header - ORA-27047)
[oracle@ora11g test1212]$ which dbfsize /db_1/bin/dbfsize --查看控制文件块大小 [oracle@ora11g test1212]$ dbfsize control01.ctl Database file: control01.ctl Database file type: file system byte blocks --查看redo log文件块大小 [oracle@ora11g test1212]$ dbfsize redo01.log Database file: redo01.log Database file type: file system byte blocks --查看system01文件块大小 [oracle@ora11g test1212]$ dbfsize system01.dbf Database file: system01.dbf Database file type: file system byte blocks
可以看到通过dbfsize可以得到system01.dbf这个文件的块信息有2个数据： 87040和8192。
现在我们要通过bbed来做查询得到相应的信息
首先我们用bbed定位到1号文件的0号块，并dump出相应的信息来
BBED
BBED
BLOCK#
BBED> show all
BLOCK#
OFFSET
DBA ,)
FILENAME /u01/app/oracle/oradata/test1212/system01.dbf
BIFILE bifile.bbd
LISTFILE dbfiles.txt
BLOCKSIZE
MODE Edit
EDIT Unrecoverable
IBASE Dec
OBASE Dec
WIDTH
LOGFILE log.bbd
SPOOL No
BBED> dump
)
Block: Dba:0x00400000
-----------------------------------------------------------------------
00a20000 0000c0ff 67ae0000 7d7c7b7a
a0810000
以上就是1号文件0号块dump出来的信息。经查询资料，我们先有一个通过实验总结出来的结论：
第20-23个字节，存放了数据块的大小；第24-27个字节，存放了数据文件的大小。
对比上面的信息可以得到：第20-23个字节是 “00200000”，第24-27个字节是“00540100”
那么我们怎么得到“00200000”和“00540100”这2个对应的十进制数是多少呢？
在这里，我们先要了解操作系统的一个有关cpu的知识----字节顺序 在几乎所有的机器上，多字节对象都被存储为连续的字节序列，对象的地址为所有使用字节中最小的地址。 假设一个类型为int的变量x的地址为0x100,也就是说，地址表达式&x的值 为0x100。 那么x的4个字节将被存储在存储器的0x100、0x101 、0x102、 x103位置。 某些机器选择在存储器中按照从最低有效字节到高位有效字节的顺序存储对象，而另一些机器则按照从最高有效字节到最低有效字节的顺序存储。 前一种规则：最低有效字节在最前面的方式，称为小端法(little endian)。 后一种规则：最高有效字节在最前面的方式，称为大端法(big endian)。
oracle给我们提供了一个字典表来查询系统是大端还是小端：
SQL> select * from V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_ID;
PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT
----------- -------------------------------------------------- ----------------------------
Solaris-bit) Big
Solaris-bit) Big
HP-bit) Big
HP-bit) Big
HP Tru64 UNIX Little
AIX-bit) Big
Microsoft Windows IA (-bit) Little
Microsoft Windows IA (-bit) Little
IBM zSeries Based Linux Big
Linux IA (-bit) Little
Linux IA (-bit) Little
Microsoft Windows x86 -bit Little
Linux x86 -bit Little
HP Open VMS Little
Apple Mac OS Big
Solaris Operating System (x86) Little
IBM Power Based Linux Big
HP IA Open VMS Little
Solaris Operating System (x86) Little
Apple Mac OS (x86) Little
有了上面的补充知识，那么回过来看“00200000”和“00540100”。因为我机器的环境是linux 64位，所以是小端，所以在存储的时候其实是取反了再存的。
我们把“00200000”和“00540100” 取反，再转换成10进制：
因为16进制是2位一个字节，所以以每两位为单位进行取反：（如 12345678 取反==》7856 3412）
取反 ','xxxxxx') from dual; 8192 取反
如上所示，得到了“00200000”和“00540100”的10进制结果分别是8192和87040，就和之前的dbfsize所得到的结果一致了。
备注：
元数据中：number类型都要进行反，而字符类型不需要取反；而数据库的表里面的number类型也不需要取反
2.查看dbid和sid
通过sql语句查询，我们可以查询到sid和dbid的信息
SQL> select dbid,name from v$database;
DBID NAME
---------- ---------------
TEST1212
那么怎么通过bbed去验证它呢？
首先，要有一个通过实验总结出来的：每个文件头的1号块都有dbid和sid，dbid的信息存放在块的第28-31个字节，而sid的信息存放在第32-39个字节中
我们在这儿取1号文件的1号块，并dump出来：
BBED
BBED
BLOCK#
BBED> map
)
Block: Dba:0x00400001
------------------------------------------------------------
Data File Header
struct kcvfh, bytes @0
ub4 tailchk @8188
BBED> dump
)
Block: Dba:0x00400001
------------------------------------------------------------------------
0ba20000 fae40000 0000200b 021aedcf
25316a29 04864d31 38830b00
25f6ff31
5354454d
0a000a00
20316a29
7b281100 000093bf fd660132 0100775b 10005d10
bytes per line>
BBED>
根据实验总结出来的结论为向导，找到第28-31个字节和第32-39个字节的信息:
第28-31个字节:"021aedcf"，根据之前提到的字节顺序存放的知识，我们做如下的操作：
021aedcf 取反==》 0xcfed1a02
SQL> select to_number('cfed1a02','xxxxxxxx') from dual;
TO_NUMBER('CFED1A02','XXXXXXXX')
--------------------------------
--可以很清楚的看到021aedcf取反再转化成10进制数所得到的结果是3488422402，而这个正好和通过sql查询出来的dbid是一样的！
可以很清楚的看到021aedcf取反再转化成10进制数所得到的结果是3488422402，而这个正好和通过sql查询出来的dbid是一样的！
而第32-39个字节的信息:"54455354 31323132"，我们通过一个sql来查询这一串字符到底代表的是什么：
SQL,)),; CH -- T E S T
通过结果我们也可以发现"54455354 31323132"原来对应的就是我们的sid。
另外，我们可以通过bbed继续观察：
BBED> map /v
)
Block: Dba:0x00400001
------------------------------------------------------------
Data File Header
struct kcvfh, bytes @0
struct kcvfhbfh, bytes @0
struct kcvfhhdr, bytes @20
ub4 kcvfhrdb @96
struct kcvfhcrs, bytes @100
ub4 kcvfhcrt @108
ub4 kcvfhrlc @112
struct kcvfhrls, bytes @116
ub4 kcvfhbti @124
struct kcvfhbsc, bytes @128
ub2 kcvfhbth @136
ub2 kcvfhsta @138
struct kcvfhckp, bytes @484
ub4 kcvfhcpc @140
ub4 kcvfhrts @144
ub4 kcvfhccc @148
struct kcvfhbcp, bytes @152
ub4 kcvfhbhz @312
struct kcvfhxcd, bytes @316
sword kcvfhtsn @332
ub2 kcvfhtln @336
] @338
ub4 kcvfhrfn @368
struct kcvfhrfs, bytes @372
ub4 kcvfhrft @380
struct kcvfhafs, 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, bytes @420
struct kcvfhprfs, bytes @428
ub4 kcvfhtrt @444
ub4 tailchk @8188
我们已经知道dbid的信息存放在块的第28-31个字节，而sid的信息存放在第32-39个字节中，那么我们可以观察到这个信息其实就是放在结构struct kcvfhhdr, 76 bytes @20 中的 （位于@20-@96这2个之间）
再继续查看kcvfhhdr的详细信息：
BBED> print kcvfhhdr struct kcvfhhdr, bytes @20 ub4 kccfhswv @20 0x00000000 ub4 kccfhcvn @24 0x0b200000 ub4 kccfhdbi @28 0xcfed1a02 ] @32 T ] @33 E ] @34 S ] @35 T ub4 kccfhcsq @40 0x00000530 ub4 kccfhfsz @44 0x00015400 s_blkz kccfhbsz @48 0x00 ub2 kccfhfno @52 0x0001 ub2 kccfhtyp @54 0x0003 ub4 kccfhacid @56 0x00000000 ub4 kccfhcks @60 0x00000000 ] @64 ] @65 ] @66 ] @67 ] @68 ] @69 ] @70 ] @71 ] @72 ] @73 ] @74 ] @75 ] @76 ] @77 ] @78 ] @79 ] @80 ] @81 ] @82 ] @83 ] @84 ] @85 ] @86 ] @87 ] @88 ] @89 ] @90 ] @91 ] @92 ] @93 ] @94 ] @95 BBED>
这下更能清楚的看到：
ub4 kccfhdbi @28 0xcfed1a02 text kccfhdbn[0] @32 T text kccfhdbn[1] @33 E text kccfhdbn[2] @34 S text kccfhdbn[3] @35 T text kccfhdbn[4] @36 1 text kccfhdbn[5] @37 2 text kccfhdbn[6] @38 1 text kccfhdbn[7] @39 2
第28到31的是“0xcfed1a02”，也就是我们之前已经算出来的dbid的十六进制结果；
而第32到39更能直观的看到sid的显示。也间接的告诉了我们，sid只有8个bit来存放，这些都是块格式中规定好了的，所以有些想把sid的长度定义超过8位的想法是不现实的。