[20220223]bbed讀取資料塊mssm與assm 2.txt
[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部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2857826/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [20210318]bbed讀取資料塊2.txt
- [20210318]bbed讀取資料塊.txt
- [20210906]bbed讀取資料塊(bbed-wrap.sh).txt
- [20210831]bbed讀取資料塊6.txt
- [20210323]bbed讀取資料塊5.txt
- [20210319]bbed讀取資料塊3.txt
- [20210930]bbed讀取資料塊7 fffext.sh.txt
- [20210401]使用bbed讀取資料塊恢復注意6.txt
- [20220223]bbed ktbbh.ktbbhict.txt
- [20190124]bbed恢復資料遇到延遲塊清除的問題2.txt
- [20210223]bbed itl ktbitflg 2.txt
- netty讀取大塊的有分界資料Netty
- [20180306]資料塊檢查和2.txt
- [20230427]bbed sum apply問題2.txtAPP
- 讀取JSON資料JSON
- 讀取CSV資料
- Pytorch資料讀取與預處理實現與探索PyTorch
- Spark讀取MongoDB資料的方法與優化SparkMongoDB優化
- [20190124]bbed恢復資料遇到延遲塊清除的問題.txt
- Hadoop3.2.1 【 HDFS 】原始碼分析 : DataXceiver: 讀取資料塊 解析 [二]Hadoop原始碼
- [20190125]MSSM表空間塊ITL的LCK.txtSSM
- Jsp讀取MySQL資料JSMySql
- python讀取MySQL資料PythonMySql
- Spark讀取MySQL資料SparkMySql
- sqlserver讀取oracle資料庫資料SQLServerOracle資料庫
- 利用反射讀取資料庫資料反射資料庫
- Oracle 之利用BBED修改資料塊SCN----沒有備份資料檔案的資料恢復Oracle資料恢復
- spark學習筆記--資料讀取與儲存Spark筆記
- Spark(16) -- 資料讀取與儲存的主要方式Spark
- [20210316]MSSM表空間塊ITL的LCK 3.txtSSM
- [20190104]bbed手工插入資料.txt
- eazyexcel 讀取excel資料插入資料庫Excel資料庫
- spark讀取hbase的資料Spark
- Python讀取YAML配置資料PythonYAML
- 讀取JSON資料存入表格JSON
- python讀取串列埠 資料Python串列埠
- 建造者模式讀取資料模式
- 讀取資料夾檔案