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 /u01/app/oracle/product/11.2.0/db_1/bin/dbfsize --查看控制文件块大小 [oracle@ora11g test1212]$ dbfsize control01.ctl Database file: control01.ctl Database file type: file system Database file size: 594 16384 byte blocks --查看redo log文件块大小 [oracle@ora11g test1212]$ dbfsize redo01.log Database file: redo01.log Database file type: file system Database file size: 102400 512 byte blocks --查看system01文件块大小 [oracle@ora11g test1212]$ dbfsize system01.dbf Database file: system01.dbf Database file type: file system Database file size: 87040 8192 byte blocks
可以看到通过dbfsize可以得到system01.dbf这个文件的块信息有2个数据： 87040和8192。
现在我们要通过bbed来做查询得到相应的信息
首先我们用bbed定位到1号文件的0号块，并dump出相应的信息来
BBED> set file 1 FILE# 1 BBED> set block 0 BLOCK# 0 BBED> show all FILE# 1 BLOCK# 0 OFFSET 0 DBA 0x00400000 (4194304 1,0) FILENAME /u01/app/oracle/oradata/test1212/system01.dbf BIFILE bifile.bbd LISTFILE dbfiles.txt BLOCKSIZE 8192 MODE Edit EDIT Unrecoverable IBASE Dec OBASE Dec WIDTH 80 COUNT 512 LOGFILE log.bbd SPOOL No BBED> dump File: /u01/app/oracle/oradata/test1212/system01.dbf (1) Block: 0 Offsets: 0 to 511 Dba:0x00400000 ----------------------------------------------------------------------- 00a20000 0000c0ff 00000000 00000000 67ae0000 00200000 00540100 7d7c7b7a a0810000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
以上就是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 ----------- -------------------------------------------------- ---------------------------- 1 Solaris[tm] OE (32-bit) Big 2 Solaris[tm] OE (64-bit) Big 3 HP-UX (64-bit) Big 4 HP-UX IA (64-bit) Big 5 HP Tru64 UNIX Little 6 AIX-Based Systems (64-bit) Big 7 Microsoft Windows IA (32-bit) Little 8 Microsoft Windows IA (64-bit) Little 9 IBM zSeries Based Linux Big 10 Linux IA (32-bit) Little 11 Linux IA (64-bit) Little 12 Microsoft Windows x86 64-bit Little 13 Linux x86 64-bit Little 15 HP Open VMS Little 16 Apple Mac OS Big 17 Solaris Operating System (x86) Little 18 IBM Power Based Linux Big 19 HP IA Open VMS Little 20 Solaris Operating System (x86-64) Little 21 Apple Mac OS (x86-64) Little
有了上面的补充知识，那么回过来看“00200000”和“00540100”。因为我机器的环境是linux 64位，所以是小端，所以在存储的时候其实是取反了再存的。
我们把“00200000”和“00540100” 取反，再转换成10进制：
因为16进制是2位一个字节，所以以每两位为单位进行取反：（如 12345678 取反==》7856 3412）
00200000 取反==》0000 0020
select to_number('2000','xxxxxx') from dual; 8192
00540100 取反==》00015400
select to_number('15400','xxxxxx') from dual; 87040
如上所示，得到了“00200000”和“00540100”的10进制结果分别是8192和87040，就和之前的dbfsize所得到的结果一致了。
备注：
元数据中：number类型都要进行反，而字符类型不需要取反；而数据库的表里面的number类型也不需要取反
2.查看dbid和sid
通过sql语句查询，我们可以查询到sid和dbid的信息
SQL> select dbid,name from v$database; DBID NAME ---------- --------------- 3488422402 TEST1212
那么怎么通过bbed去验证它呢？
首先，要有一个通过实验总结出来的：每个文件头的1号块都有dbid和sid，dbid的信息存放在块的第28-31个字节，而sid的信息存放在第32-39个字节中
我们在这儿取1号文件的1号块，并dump出来：
BBED> set file 1 FILE# 1 BBED> set block 1 BLOCK# 1 BBED> map File: /u01/app/oracle/oradata/test1212/system01.dbf (1) Block: 1 Dba:0x00400001 ------------------------------------------------------------ Data File Header struct kcvfh, 860 bytes @0 ub4 tailchk @8188 BBED> dump File: /u01/app/oracle/oradata/test1212/system01.dbf (1) Block: 1 Offsets: 0 to 511 Dba:0x00400001 ------------------------------------------------------------------------ 0ba20000 01004000 00000000 00000104 fae40000 00000000 0000200b 021aedcf 54455354 31323132 30050000 00540100 00200000 01000300 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 08024000 07000000 00000000 25316a29 04864d31 38830b00 00000000 00000000 00000000 00000000 00000420 97000000 25f6ff31 96000000 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 06005359 5354454d 00000000 00000000 00000000 00000000 00000000 00000000 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0a000a00 20316a29 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7b281100 000093bf fd660132 0100775b 39000000 02000000 10005d10 <32 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') -------------------------------- 3488422402 --可以很清楚的看到021aedcf取反再转化成10进制数所得到的结果是3488422402，而这个正好和通过sql查询出来的dbid是一样的！
可以很清楚的看到021aedcf取反再转化成10进制数所得到的结果是3488422402，而这个正好和通过sql查询出来的dbid是一样的！
而第32-39个字节的信息:"54455354 31323132"，我们通过一个sql来查询这一串字符到底代表的是什么：
SQL> select chr(to_number((substr(replace('54455354 31323132',' '),rownum*2-1,2)),'xxxxxxxxxxx')) from v$mystat where rownum <9; CH -- T E S T 1 2 1 2
通过结果我们也可以发现"54455354 31323132"原来对应的就是我们的sid。
另外，我们可以通过bbed继续观察：
BBED> map /v File: /u01/app/oracle/oradata/test1212/system01.dbf (1) Block: 1 Dba:0x00400001 ------------------------------------------------------------ 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
我们已经知道dbid的信息存放在块的第28-31个字节，而sid的信息存放在第32-39个字节中，那么我们可以观察到这个信息其实就是放在结构struct kcvfhhdr, 76 bytes @20 中的 （位于@20-@96这2个之间）
再继续查看kcvfhhdr的详细信息：
BBED> print kcvfhhdr struct kcvfhhdr, 76 bytes @20 ub4 kccfhswv @20 0x00000000 ub4 kccfhcvn @24 0x0b200000 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 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 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 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位的想法是不现实的。