Oracle block 格式

資訊參考:  http://www.ixora.com.au/
特別感謝 overtime 大哥對我的無私的協助和對我一直鼓勵支援我的網友
這些資料是沒得到oracle 支援的 所以不能保證資訊的正確性 請謹慎使用
科技無限 隨便轉載

oracle 8.1.7         8k block          windows xp   
create table t(n number);
insert into t values(1);   --- 從 dbms_rowid 中看出table t 的資料在datafile 4 的第3個 block 上

select dbms_rowid.ROWID_RELATIVE_FNO(rowid) as file#,dbms_rowid.ROWID_BLOCK_NUMBER(rowid) as block# from t;

alter system dump datafile 4 block 3;
下面是 dump 的檔案的資訊
還可以用下面的語句然後再用上面的 dump 語句看記憶體中 block 的2進位儲存格式
但這記憶體中的2進位格式和datafile中block資料表示的順序會略有不同可能是記憶體定址的緣故吧
ALTER SESSION SET EVENTS '10289 trace name context forever, level 1';
ALTER SESSION SET EVENTS '10289 trace name context off';
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     下面的是 udump 目錄下面 dump 檔案的資訊

-----------------------  第一部分

buffer tsn: 7 rdba: 0x01000003 (4/3)
scn: 0x0000.000802a5 seq: 0x01 flg: 0x02 tail: 0x02a50601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data

--- buffer tsn:         資料檔案對應的 tablespace 的 number   這隻是dump檔案中記錄的資料而已
---                                               block 中是沒有記錄 tablespace 的 number 的
--- rdba:    4 bytes    datafile 中 block 的地址  標示的第幾個 block
--- scn:     6 bytes    system change number
--- seq:     1 byte     A sequence number incremented for each change to a block at the same SCN
---                        A new SCN is allocated if the sequence number wraps.
---                        同一個SCN影響這個block中的行數大於 254 行就會為這個事務分配一個新的SCN
---                        如下面的操作就可能引起同一個SCN但影響的同一個block 中的行超過254行
---                        "delete from table_name" 
---                        影響的行數(最大254) 是用從 0x01 到 0xfe 表示的
---                        當這個byte 的資料為 0xff 的時候標誌這個 block 壞調了---> ora-01578
--- flg:     1 byte     1 = virgin block
---                     2 = last change to the block was for a cleanout operation
---                     4 = checksum value is set
---                     8 = temporary data
---                     這是一個可以組合的值 也就是說有為 6 的時候是 2,4 兩種情況的組合
--- tail:    4 bytes    這是記錄在 block 的最後面的 4 bytes 的資料
---                         dump檔案中只是把他寫在了前面而已
--- frmt:    1 byte     oracle 8 以後看見的都是 0x02
--- chkval:  2 bytes    在 init 檔案中設定了 db_block_checksum=true 才有值
--- type:    1 byte     這個 block 的類型 這裡主要看 0x06 這種 因為這種是用來存使用者資料的
---                         其他的類型可以參考http://www.ixora.com.au/notes/cache_block_types.htm

-----------------------  第二部分
Block header dump:  0x01000003
 Object id on Block? Y
 seg/obj: 0x614a  csc: 0x00.802a3  itc: 1  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01
     
--- seg/obj: 4 bytes    這裡是16進位的 對應 sys.obj$.obj# 資料字典的資料
--- csc:     6 bytes    The SCN at which the last full cleanout was performed on the block
--- itc:     1 byte     下面的Itl事務條的個數 8.1.7的文檔上面說可以使用 INITRANS 在建表的時候
---                       限制這個值的大小(max 255超過會報ORA-02207) 但要考慮block 的空間是否夠
---                       表在8i中 INITRANS default為1 ,  9.2.0中 INITRANS default為2
---                       Yong Huang 說有些時候發生ORA-00060可以把表的 INITRANS 設定大點
---                       ixora 上說當block的空間不夠建立一個ITL的時候一樣可能引起ORA-00054
--- flg:     2 bytes    0 indicates that the block is on a freelist. Otherwise the flag is -
---                       9i 的ASSM 的情況下這個值為 E
---                       ixora 上說他佔用 2 bytes 但我下面的實驗和他的結果有一定的出入
---                       我觀察到的情況是 :
---                               Object id on Block? Y
---                               flg: O
---                               ver: 0x01
---                            上面的3項是用同一個 byte 來表示的
--- typ:     1 byte     1 為 table ; 2 為 index.  oracle進行查詢的時候是根據 obj$表中的情況來
---                       判斷對象的類型的,不是根據這個typ。也就是說如果有一個表但改變表中block
---                       的這個標誌位，一樣可以查詢出資料來,但dump block 時會出錯,如下面的ora
---                       ORA-00600: 內部錯誤碼，自變數: [4555], [0], [], [], [], [], [], []
---                       錯誤中的 [0] 就是typ對應的資料
--- fsl:     1 byte     Index to the first slot on the ITL freelist.  ITL TX freelist slot
--- fnx:     4 bytes    自由列表中下一塊的地址 Null if this block is not on a freelist
---                       有資料例如: fnx: 0x1000029
--- ver:     1 byte     format (version) 這個資料沒有看到相關的文檔介紹 從ixora上說是佔用1byte
---                       但我從下面的2進位檔案中看到的有不同 下面有介紹
--- unused:  4 bytes    在這裡還有4 bytes 的閒置空間 但在上面的 dump 檔案上是沒顯示出來的
---                        這個unused 的4 bytes是 ixora 上面的說法
---     9i 的 ASSM 的 " fsl: 0  fnx: 0x0 ver: 0x01 "這一段資料的情況已經改變了

-----------------------  第三部分
 Itl           Xid                  Uba                      Flag  Lck        Scn/Fsc
0x01   xid:  0x0003.045.000000b4    uba: 0x0080170a.00c7.36  --U-    1  fsc 0x0000.000802a5

--- 這是 oracle 用來記錄事務資訊的部分  這裡顯示的只有一個ITL條 有多少個ITL條是可以動態增加的
--- 只要 block 中的空間足夠  可以定義初始化的 ITL 條的個數 用 INITRANS 這storage 參數
--- 這裡有多少個 ITL 可以從上面 "第二部分" 的 "itc:" 看出來
--- 這部分牽扯 rollback segment 或 undo tablespace
--- Itl                 itl 的序號
--- xid:     8 bytes    值可以用select XIDUSN, XIDSLOT,XIDSQN from v$transaction;查到
---                     This is comprised of the rollback segment number (2 bytes), the slot number
---                     in the transaction table of that rollback segment (2 bytes), and the number
---                     of times use of that transaction table has wrapped (4 bytes). 
--- Uba:     8 bytes    The location of the undo for the most recent change to this block by this
---                     transaction. This is comprised of the DBA of the rollback segment block (4
---                     bytes), the sequence number (2 bytes), and the record number for the change
---                     in that undo block (1 byte), plus 1 unused byte. 
--- flag     1 nibble   ---- = transaction is active, or committed pending cleanout
---                     C--- = transaction has been committed and locks cleaned out
---                     -B-- = this undo record contains the undo for this ITL entry
---                     --U- = transaction committed (maybe long ago); SCN is an upper bound
---                     ---T = transaction was still active at block cleanout SCN
--- Lck      3 nibbles  The number of row-level locks held in the block by this transaction. 
--- Scn/Fsc  6 bytes    If the transaction has been cleaned out, this is the commit SCN or an upper
---                     bound thereof. Otherwise the leading two bytes contain the free space credit
---                     for the transaction - that is, the number of bytes freed in the block by the
---                     transaction
---         參考http://www.ixora.com.au/q+a/datablock.htm#end
---

-----------------------  第四部分
data_block_dump
===============
tsiz: 0x1fb8
hsiz: 0x14
pbl: 0x02476c44
bdba: 0x01000003
flag=-----------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1fb2
avsp=0x1f9b
tosp=0x1f9b
0xe:pti[0] nrow=1 offs=0
0x12:pri[0] offs=0x1fb2

---       tsiz:    hsiz:   pbl:   bdba: 在資料檔案都是沒有儲存的
--- tsiz:        除了上面的3部分和block尾部的4個位元組剩下的空間 0x1fb8就是8120位元組  8k的block:
---              8192-20(block head)-24(Transaction Header)-24(一個事務條)-4(block tail)=8120
--- hsiz:        資料區塊頭20個位元組+資料區塊尾4個位元組=24位元組(0x14)
--- pbl:         ptr to buffer holding the block 我是用的專用模式dump的datafile中的block出來
---              在同一個session的dump檔案中 dump 出來的block 的這個都是同一個值
--- bdba:        和第一部分中的rdba 一個意思          
--- flag         1 byte     N=pctfree hit(clusters), F=don't put on free list
---                         K=flushable cluster keys. 當然還有別的標記: A ...
--- ntab         1 byte     這block中有幾個table的資料   cluster這個就可能大於1
--- nrow         2 bytes    block 中有多少行資料
--- frre         2 bytes    First free row index entry. -1=you have to add one.
--- fsbo         2 bytes    Free Space Begin offset
--- fseo         2 bytes    Free Space End offset
--- avsp         2 bytes    Available space in the block    <pctfree and pctused?>
--- tosp         2 bytes    Total available space when all TXs commit
--- 0xe: nrow    2 bytes    block 中的這個table有多少行資料
--- 0xe: offs    2 bytes    位移量 用 cluster 的時候可以看出值

-----------------------  第五部分
block_row_dump:
tab 0, row 0, @0x1fb2
tl: 6 fb: --H-FL-- lb: 0x1 cc: 1
col  0: [ 2]  c1 02
end_of_block_dump

--- tl:     這條記錄中的長度 包括row head 的一般情況的 3 位元組和表示資料長度的1位元組和資料本身的長度
--- fb:   1 byte   K = Cluster Key (Flags may change meaning if this is set to show HASH cluster)
---                C = Cluster table member
---                H = Head piece of row
---                D = Deleted row
---                F = First data piece
---                L = Last data piece
---                P = First column continues from previous piece
---                N = Last column continues in next piece
--- lb:   1 byte   和上面第三部分的 ITL 的lck相對應  表示這行是否被 lock 了
--- cc:   1 byte   表示這行有幾列資料
--- col  0: [ 2] : 1 byte  表示這行的這列的長度
--- c1 02 :        這就是table中的資料 "1"  可以通過下面的語句看 oracle真正使用的是
---                那些16進位的資料來表示的使用者資料 select dump(col_name,16) from table_name;

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       下面的資料就是上面的 dump 檔案對應的2進位檔案  我依照 2 進位資料的順序解釋內容

------------------------  下面的對應上面dump 檔案的第一部分
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00006000   06 02 00 00 03 00 00 01  A5 02 08 00 00 00 01 02  
00006010   00 00 00 00

--- 06               :   type: 0x06=trans data (對應上面dump檔案中的內容)
--- 02               :   frmt: 0x02
--- 00 00            :   filler  應該是 unused  上面的dump檔案中並沒有顯示這部分內容
--- 03 00 00 01      :   rdba: 0x01000003 在同一個 tablespace 中是唯一的 當 datafile 中可能不唯一
---                        來看看他的規律 :連續建4個 datafile  他們的第一block為
---                        0x 01 00 04 01
---                        0x 01 00 08 01
---                        0x 01 00 0c 01
---                        0x 01 00 00 02
---                        對應的資料在是 0x01040001 , 0x01080001 , 0x010c0001 , 0x02000001
---                        這就可以看出一個 datafile 的最大的容量是 0x01040001~0x0107ffff 總共是
---                        4M(因為還有一個datafile head)個block 如果block 是8k 一個datafile就是 32G
---                        這就是oracle 的文檔上面對 oracle 的 datafile (8k的時候)最大 32G 的原因
---                        同樣可以看出一個 tablespace 的datafile 可以從 0x0100 到 0xfffe 就是1023
---                        個 datafile 這也是 oracle 的文檔上面說一個tablesapce可以有1022 個datafile
---                        的原因(其實一個 tablespace 可以有 1023 個 datafile   我建過)
---                        oracle10G中 block 的big datafile 的這段資料的情況是0x00000001~0xffffffff
---                        這也是為什麼一個 big datafile 的tablesapce只有一個datafile 並且最大值為
---                        32T (8k的時候 : 4G*8k=32T ; 32k的資料區塊的時候為128T)
--- A5 02 08 00 00 00 :  scn: 0x0000.000802a5   oracle是c語言寫的 這6位不正好是一個 unsigned long
---                        和 unsigned int的組合
--- 01                :  seq: 0x01
--- 02                :  flg: 0x02
--- 00 00             :  chkval: 0x0000 在 init 中設定了 db_block_checksum=true 才有值
--- 00 00             :  unused 上面的dump檔案中並沒有顯示這部分內容
---    上面的20個bytes的資料任改其中的值肯定發生ORA-XXXXX(不一定就是ora-01578 我還看見過ora-600)
                                            

------------------------  下面的對應上面dump 檔案的第二部分

                       01 00 00 00  4A 61 00 00 A3 02 08 00  
00006020   00 00 00 00 01 00 03 00  00 00 00 00

--- 01                :   typ: 1 - DATA
--- 00                :   只見過 0x00 沒見過其他的值 don't know
--- 00                :   見過有其他值 但用編輯器改這個值 在 dump 檔案中顯示不出來變化
--- 00                :   沒見變過其他的值 don't know
--- 4A 61 00 00       :   seg/obj: 0x614a
--- A3 02 08 00 00 00 :   csc: 0x00.802a3
--- 00 00             :   見過有其他值 但用編輯器改這個值 在 dump 檔案中顯示不出來變化      
--- 01                :   itc: 1    下面的 ITL 條目的個數
--- 00                :   見過有其他值 但用編輯器改這個值 在 dump 檔案中顯示不出來變化
--- 03                :   flg: O         ver: 0x01        Object id on Block? Y
---                       從我的觀察中 dump 出來的檔案中   flg     ver     Object id on Block
---                       他們共同佔用的這個一個位元組   他的規律可以從下面的情況看出
---                         2進位資料     flg       ver       Object id on Block?
---                           0x00         -        0x00           N
---                           0x01         0        0x00           N
---                           0x02         -        0x01           Y
---                           0x03         0        0x01           Y
---                           0x04         -        0x02           Y
---                           0x05         0        0x02           Y
---                           0x06         -        0x03           Y
---                           0x07         0        0x03           Y
---                           0x08         -        0x04           N
---                           0x09         0        0x04           N
---                           0x0a         -        0x05           Y
---                           0x0b         0        0x05           Y
---                           0x0c         -        0x06           Y
---                           0x0d         0        0x06           Y
---                           0x0e         -        0x07           Y
---                           0x0f         0        0x07           Y
---                           0x10 ... 類似上面的迴圈了   這種情況在9i上已經改變因為ASSM的出現
--- 00                :   fsl: 0
--- 00 00 00 00       :   fnx: 0x0

------------------------  下面的對應上面dump 檔案的第三部分

                                                03 00 45 00  
00006030   B4 00 00 00 0A 17 80 00  C7 00 36 00 01 20 00 00  
00006040   A5 02 08 00

--- 03 00 45 00 B4 00 00 00  :   xid:  0x0003.045.000000b4
--- 0A 17 80 00 C7 00 36 00  :   uba:  0x0080170a.00c7.36
--- 01  0                    :   Lck   鎖定的row數 這裡還用到了下一個 byte 的資料
--- 2                        :   Flag  2 對應的二進位表示為 0010 正好和dump檔案中的 --U- 吻合
--- 00 00 A5 02 08 00        :   Scn/Fsc

------------------------  下面的對應上面dump 檔案的第四部分

                       00 01 01 00  FF FF 14 00 B2 1F 9B 1F  
00006050   9B 1F 00 00 01 00 B2 1F  

--- 00               :   flag
--- 01               :   ntab
--- 01 00            :   nrow
--- FF FF            :   frre
--- 14 00            :   fsbo
--- B2 1F            :   fseo
--- 9B 1F            :   avsp
--- 9B 1F            :   tosp
--- 00 00            :   0xe: offs
--- 01 00            :   0xe: nrow
--- B2 1F            :   0x12:pri[0] offs=0x1fb2

------------------------  下面的對應上面dump 檔案的第五部分

--- 這部分和上面的資料中間省略了很多 因為這列子中這些部分沒儲存資料

00007FF0   00 00 00 00 00 00 2C 01  01 02 C1 02

--- 這是 block 中存使用者資料的地方
--- 2C     :    fb:
--- 01     :    lb: 這一行是否被lock
--- 01     :    這條記錄中有多少列的資料  從這裡看出因為只用一個byte去記錄這一行有多少列
---               所以最多是255列 但一個表可以最多是1000列 如果table 的列大於255列 這裡就會
---               發生連結 根據一行記錄的長度來看是 塊內的連結或者是塊與塊直接的連結
---               這也是為什麼table 的設計會盡量少於255列的原因
--- 02     :    第1列的資料的長度是多少
--- C1 02  :    儲存在 block 中的資料 "1"

------------------------  下面的對應上面dump 檔案的第一部分的 "tail: 0x02a50601"
                                                01 06 A5 02 
--- 這是用來效驗 block 是否完整的標誌 改這 block 最後的4 bytes 資料中的任意肯定ora-1578

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
上面只是講解了一個最簡單的oracle 的block 的格式 其他還有很多的情況 如 cluster , index 等
long , lob , long raw 這些在 block 中的表示因為資料長度的不同都會有不同的體現

有的時候改動block 中的任意資料不一定會發生 ORA-01578 因為下面的兩個參數沒有設定為 true
db_block_checking    db_block_checksum   
這兩個參數對於system tablespace 預設都是true 所以改變 system tablespace 中的
資料肯定會發生ORA-01578
隨著oracle版本的不斷升級 oracle 對block中儲存資料的正確性也在不斷的提升要求 而且通過常規的
手段想去瞭解 oracle block 的格式也可能越來越困難