深入剖析-Oracle索引分支塊的結構

作者介紹

崔華 網名 dbsnake

Oracle ACE Director,ACOUG 核心專家

重要結論

1、每個索引分支塊都只有一個lmc,這個lmc指向的分支塊/葉子塊中的所有索引鍵值列中的最大值一定小于該lmc所在分支塊的所有索引鍵值列中的最小值;

2、索引分支塊的行記錄所對應的存儲格式為“行頭 + 分支塊/葉子塊的RDBA + col 0 + col 1”,其中col 0為索引鍵值列,等于該行行頭“分支塊/葉子塊的RDBA”所指向的葉子塊中的第一行索引行所對應的數據行的ROWID

實例解析

通過實例解析Oracle索引分支塊的結構

/nbstu01/app/oracle/diag/rdbms/nbstest/NBSTEST/trace/NBSTEST_ora_9699378.trc的內容為如下所示:

從上述顯示內容中我們可以看出,現在索引IDX_T2有如下這三個分支塊:

我們現在直接來dump上述分支塊0x38003c6,dump后的trace文件內容為如下所示:

先來看上述顯示內容中的第9行記錄:

上述第9行記錄所在葉子塊的起止地址為0x380028f:

上述葉子塊的dump內容為如下所示:

然后我們再來dump上述葉子塊的前一個塊(即kdxleprv 58720910=0x380028e);

也就是說上述第9行記錄對應了兩個索引行,這兩個索引行恰好分布在兩個葉子塊中,一個在葉子塊0x0380028f中,一個在葉子塊0x380028e中

再來看上述分支塊的dump內容中的第20行記錄:

上述第20行記錄所在葉子塊的起始地址為0x380029a:

上述葉子塊的dump內容為如下所示:

然后我們再來dump上述葉子塊的前一個塊(即58720921=0x3800299);

也就是說上述第20行記錄對應了兩個索引行,這兩個索引行也恰好分布在兩個葉子塊中,一個在葉子塊0x0380029a中,一個在葉子塊0x03800299中

再來看上述分支塊dump內容中的第230行記錄:

因分析過程和結論和上述類似,這里略去。

col1記錄的值為其ROWID頭3個byte的實例

上述分支塊的行記錄所對應葉子塊的dump內容為如下所示:

再來dump上述葉子塊的前一個塊:

這里上述葉子塊的第一行記錄所對應的ROWID為01 43 d1 fd 00 2b,其前一個葉子塊的最后一行記錄所對應的ROWID為01 43 d0 11 00 91,這兩個ROWID的頭3個byte分別為01 43 d1和01 43 d0,已然不同,所以上述分支塊的行記錄的col1只用記錄01 43 d1就可以了。

col1記錄的值為其ROWID頭1個byte的實例

row#18[7464] dba: 184552472=0xb000c18col 0; len 20; (20): 2f 31 62 39 34 37 31 65 38 5f 53 69 67 6e 61 74 75 72 65 31col 1; len 1; (1): 0b

上述分支塊的行記錄所對應葉子塊的dump內容為如下所示:

再來dump上述葉子塊的前一個塊:

這里上述葉子塊的第一行記錄所對應的ROWID為0b 00 0b 6a 00 57,其前一個葉子塊的最后一行記錄所對應的ROWID為01 43 d1 a7 00 06,這兩個ROWID的頭1個byte分別為0b和01,已然不同,所以上述分支塊的行記錄的col1只用記錄0b就可以了。

常見問題

sys.undump存儲過程的源碼能否提供下?

create or replace procedure undump(i_vc_input in varchar2) is/*

功能: 將dump出來的16進制文本內容翻譯成其原始文本,目前僅支持ZHS16GBK和AL32UTF8字符集作者: dbsnake創建日期:2010-11-30

輸入參數:i_vc_input: 輸入的dump出來的16進制文本內容

輸出參數:無

輸入輸出參數:無

調用到的存儲過程:無

sys.cdba()是否是系統自帶的

不是,CDBA的源碼如下:

關于oracle自定義外連接”(+)”書中寫的關于full outer join的等價改寫:

您提到Oracle斷然不會采用這樣的等價改寫,而是通過如下的改寫:

通過這兩種改寫方式得到的結果是一致的,并查看了兩種改寫的執行計劃,只是在第一種方式中多了union的排序操作,是因為這個原因嗎?

排序只是union的副作用,這里為什么用union來模擬是因為我需要union所帶來的“去重”