950
深入剖析-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=0xb000c18
col 0; len 20; (20): 2f 31 62 39 34 37 31 65 38 5f 53 69 67 6e 61 74 75 72 65 31
col 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所帶來的“去重”
原文發布時間為：2017-09-18
作者：崔華
本文來自雲棲社區合作夥伴“數據和雲”，了解相關信息可以關注“數據和雲”微信公眾號
最後更新：2017-09-20 14:03:35