[20220223]bbed读取数据块mssm与assm 2.txt
--//别人问的问题,oracle使用bbed读取数据块,如何知道数据文件是mssm以及assm的.
--//通过观察一个数据文件来分析看看：
1.环境:
SCOTT@book> @ ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
2.测试:
SCOTT@book> create table empx tablespace users as select * from emp;
Table created.
--//注:这样建立的表使用3个ITL槽.users表空间的数据文件是assm的。
SCOTT@book> select rowid from empx where rownum=1;
ROWID
------------------
AABQ8VAAEAAABNbAAA
SCOTT@book> @ rowid AABQ8VAAEAAABNbAAA
OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT
---------- ---------- ---------- ---------- -------------------- -------------------- ----------------------------------------
331541 4 4955 0 0x100135B 4,4955 alter system dump datafile 4 block 4955
SYS@book> alter system checkpoint ;
System altered.
3.bbed观察:
BBED> set dba 4,4955
DBA 0x0100135b (16782171 4,4955)
BBED> map
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 4955 Dba:0x0100135b
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
struct ktbbh, 96 bytes @20
struct kdbh, 14 bytes @124
struct kdbt[1], 4 bytes @138
sb2 kdbr[14] @142
ub1 freespace[7451] @170
ub1 rowdata[567] @7621
ub4 tailchk @8188
--//注意一个细节：struct ktbbh 开始偏移是20字节，长度96,20+96 = 116,而struct kdbh的开始偏移是124字节，这样存在8个字节的
--//"空洞".
BBED> dump /v offset 116 count 8
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 4955 Offsets: 116 to 123 Dba:0x0100135b
-------------------------------------------------------
00000000 00000000 l ........
<16 bytes per line>
--//全是0，没有任何信息。
BBED> p ktbbh
struct ktbbh, 96 bytes @20
ub1 ktbbhtyp @20 0x01 (KDDBTDATA)
union ktbbhsid, 4 bytes @24
ub4 ktbbhsg1 @24 0x00050f15
ub4 ktbbhod1 @24 0x00050f15
struct ktbbhcsc, 8 bytes @28
ub4 kscnbas @28 0x1edd0a27
ub2 kscnwrp @32 0x0003
sb2 ktbbhict @36 3
ub1 ktbbhflg @38 0x32 (NONE)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ub1 ktbbhfsl @39 0x00
ub4 ktbbhfnx @40 0x01001358
--//注意下划线部分。修改如下：
BBED> assign ktbbh.ktbbhflg=0x02
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
ub1 ktbbhflg @38 0x02 (NONE)
BBED> sum apply
Check value for File 4, Block 4955:
current = 0xfb10, required = 0xfb10
BBED> map
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 4955 Dba:0x0100135b
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
struct ktbbh, 96 bytes @20
struct kdbh, 14 bytes @116
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
struct kdbt[0], 0 bytes @130
sb2 kdbr[0] @130
ub1 freespace[256] @130
ub1 rowdata[7816] @386
ub4 tailchk @8188
--//注意看下划线现在的开始偏移是116，可以大致确定bbed是通过读取ktbbh.ktbbhflg位置相关信息，来确定数据文件是assm还是mssm
--//类型的。当然我这样修改该块的对应的信息就发生错位，完全不对了。原来的
sb2 kdbr[14] @142
--//现在变成了
sb2 kdbr[0] @130
BBED> verify
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/users01.dbf
BLOCK = 4955
Block Checking: DBA = 16782171, Block Type = KTB-managed data block
data header at 0x7fca77c13274
kdbchk: tosp bad (-1)
Block 4955 failed with check code 6127
--//整个数据块的结构信息完全破坏了。修改别的信息呢。
BBED> assign ktbbh.ktbbhflg=0x12
ub1 ktbbhflg @38 0x12 (NONE)
BBED> sum apply
Check value for File 4, Block 4955:
current = 0xfb00, required = 0xfb00
BBED> map
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 4955 Dba:0x0100135b
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
struct ktbbh, 96 bytes @20
struct kdbh, 14 bytes @124
struct kdbt[1], 4 bytes @138
sb2 kdbr[14] @142
ub1 freespace[7451] @170
ub1 rowdata[567] @7621
ub4 tailchk @8188
--//注我的测试只要ktbbh.ktbbhflg>=0x10,读取的块相关结构没有错误，也就是存在8个字节的"空洞".
BBED> verify
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/users01.dbf
BLOCK = 4955
Block Checking: DBA = 16782171, Block Type = KTB-managed data block
data header at 0x16bfe7c
kdbchk: ktbbhflg corrupted - BSEG w/o EXTHD
Block 4955 failed with check code 6150
--//assign ktbbh.ktbbhflg=0x12,但是执行verify时报错.继续测试:
BBED> assign ktbbh.ktbbhflg=0x42
ub1 ktbbhflg @38 0x42 (NONE)
BBED> sum apply
Check value for File 4, Block 4955:
current = 0xfb50, required = 0xfb50
BBED> verify
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/users01.dbf
BLOCK = 4955
Block Checking: DBA = 16782171, Block Type = KTB-managed data block
data header at 0x1726a74
kdbchk: tosp bad (-1)
Block 4955 failed with check code 6127
--//不行.错误不同。
--//data header at 0x1726a74 什么意思不明白，我也在块中没有找到对应信息。
--//换dba ＝4,151的块看看，该块是emp的表段。
BBED> set dba 4,15
DBA 0x0100135b (16782171 4,4955)
BBED> assign ktbbh.ktbbhflg=0x33
ub1 ktbbhflg @38 0x33 (KTBFONFL)
BBED> sum apply
Check value for File 4, Block 151:
current = 0x332f, required = 0x332f
BBED> map
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 151 Dba:0x01000097
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
struct ktbbh, 72 bytes @20
struct kdbh, 14 bytes @100
struct kdbt[1], 4 bytes @114
sb2 kdbr[14] @118
ub1 freespace[7475] @146
ub1 rowdata[567] @7621
ub4 tailchk @8188
BBED> verify
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/users01.dbf
BLOCK = 151
Block Checking: DBA = 16777367, Block Type = KTB-managed data block
data header at 0x1729864
kdbchk: block on freelist and in bitmapped segment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Block 151 failed with check code 6147
--//感觉对于assm,ktbbh.ktbbhflg只能等于0x32,对于数据段,没有仔细测试.
4.mssm呢?
CREATE TABLESPACE MSSM DATAFILE
'/mnt/ramdisk/book/mssm01.dbf' SIZE 40M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT MANUAL
FLASHBACK ON;
SCOTT@book> create table empy tablespace mssm as select * from emp;
Table created.
SCOTT@book> select rowid from empy where rownum=1;
ROWID
------------------
AABQ8XAAHAAAACBAAA
SCOTT@book> @ rowid AABQ8XAAHAAAACBAAA
OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT
---------- ---------- ---------- ---------- -------------------- -------------------- ----------------------------------------
331543 7 129 0 0x1C00081 7,129 alter system dump datafile 7 block 129 ;
SCOTT@book> alter system checkpoint ;
System altered.
--//bbed观察:
BBED> set dba 7,129
DBA 0x01c00081 (29360257 7,129)
BBED> map
File: /mnt/ramdisk/book/mssm01.dbf (7)
Block: 129 Dba:0x01c00081
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
struct ktbbh, 96 bytes @20
struct kdbh, 14 bytes @116
struct kdbt[1], 4 bytes @130
sb2 kdbr[14] @134
ub1 freespace[7459] @162
ub1 rowdata[567] @7621
ub4 tailchk @8188
--//没有前面梯提到的8字节"空洞". 20+96 = 116.
BBED> p ktbbh
struct ktbbh, 96 bytes @20
ub1 ktbbhtyp @20 0x01 (KDDBTDATA)
union ktbbhsid, 4 bytes @24
ub4 ktbbhsg1 @24 0x00050f17
ub4 ktbbhod1 @24 0x00050f17
struct ktbbhcsc, 8 bytes @28
ub4 kscnbas @28 0x1edd1524
ub2 kscnwrp @32 0x0003
sb2 ktbbhict @36 3
ub1 ktbbhflg @38 0x02 (NONE)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ub1 ktbbhfsl @39 0x00
ub4 ktbbhfnx @40 0x00000000
--//注意看下划线,不是0x32.如果dml后对于mssm数据文件,freespace空间大于pctused的情况,修改ktbbhflg=0x03.
--//ktbbhfsl指向对于ITL槽.ITL槽多记录1个操作.
--//另外mssm视乎不使用后面的ktbbhfnx(下一个空闲块的地址 dba(DBA of next block on the freelist))
--//一些细节可以参考:http://blog.itpub.net/267265/viewspace-2763184/->[20210316]MSSM表空间块ITL的LCK 3.txt
5.总结:
--//可以基本判断oracle是通过ktbbh.ktbbhflg的值基本判定读取的块是mssm还是assm的.
6.补充观察:
--//数据文件4对应users.dbf,assm格式.
$ seq 129 1 51200 | xargs -IQ echo "p /x dba 4,Q ktbbh.ktbbhflg" | rlbbed > /tmp/bb.txt
$ grep ktbbhflg /tmp/bb.txt | sort|uniq -c
49994 BBED> ub1 ktbbhflg @38 0x32 (NONE)
--//可以对于assm全部都是0x32.
--//数据文件1对应system.dbf,mssm格式.
$ ls -l /mnt/ramdisk/book/system01.dbf
-rw-r----- 1 oracle oinstall 817897472 2022-02-25 15:02:47 /mnt/ramdisk/book/system01.dbf
--//817897472/8192 = 99841
$ seq 129 1 99841 | xargs -IQ echo "p /x dba 1,Q ktbbh.ktbbhflg" | rlbbed > /tmp/cc.txt
$ grep ktbbhflg /tmp/cc.txt | sort|uniq -c
1647 BBED> BBED-00207: invalid offset specifier (ktbbh.ktbbhflg)
76911 BBED> ub1 ktbbhflg @38 0x02 (NONE)
3053 BBED> ub1 ktbbhflg @38 0x03 (KTBFONFL)
--//可以对于mssm仅仅出现0x02,0x03.
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/267265/viewspace-2857826/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- [20261008]验证Shared Memory Segments key以及Semaphore Arrays Key(11g).txt
- [20261008]gdb引入结构体是否可行.txt
- [20261008]bpftrace定义结构体例子.txt
- [20261007]关于oracle sskgph2函数.txt
- [20261007]oracle Semaphore Arrays Key值的冲突.txt
- [20261004]oracle sskgph2函数等价c以及python脚本.txt
- [20261004]bpftrace查看oracle函数调用堆栈问题.txt
- [20261002]验证sskgphpjw函数参与运算的字符串是否存在规律.txt
- [20261002]oracle Semaphore Arrays Key值的计算2.txt
- [20261001]oracle Semaphore Arrays Key值的计算.txt
