網上摘錄關於index block split相關一些知識
1,index block split發生時,要從index segment header的free list獲取分配空間;
2,更新一些segment metadata blocks我理解把分裂的資訊記錄在裡面
3,如index block刪除,標記為free,仍舊還要更新到一些segment metadata blocks中
4,如果index block split或刪除併發很高，在rac環境產生大量的gc buffer busy waits（因為在等待這個split index block）
5,使用freelist管理方式即更新segment header block(index)，這樣就導致上述的等待很多
6,oracle引入了freelist groups減輕這個競爭壓力,你可以手工重構segments改變
freelist groups的數量;

freelist groups它不會和其它的freelist groups分享空塊列表

7,assm產生就是為了解決上述的問題不用再手工重配置

8,assm減少segment space management metadata block的競爭壓力.
也不用手工重建freelist groups

9,而且assm還有其它的一些好處，根據oracle pid用hash function把新插入的記錄儲存到不同的資料塊中

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
1，assm時代，用bitmap代替了 freelist
2,對於index我們知道一般情況下一個新的條目只能屬於一個特定的leaf block;
但若剛好這個新條目插入到索引的最右邊索引塊，且這個索引塊FULL了，此時要分配一個新的索引塊
3，大家可以想一想，如果大量併發時，有鍵值相近的很多insert操作,它們就會hang在同一個leaf block;
   當然你可以用反向鍵索引，但會產生其它的問題（不能用範圍掃描）


-----------------------------------------------------------------------
---索引塊分裂分為50:50和90:10分裂,前者是最普通的一種方式，後者即插入鍵值大於當前最大鍵值，
---即在索引的最大右邊葉子塊不能容納最新插鍵值時發生

----剛初建的索引

branch: 0x2835ceb 42163435 (0: nrow: 3, level: 1)
   leaf: 0x2835cec 42163436 (-1: nrow: 485 rrow: 485)--三個葉子塊的條目總數為1000即表記錄數
   leaf: 0x2835ced 42163437 (0: nrow: 479 rrow: 479)
   leaf: 0x2835cee 42163438 (1: nrow: 36 rrow: 36)

--插入一箇中間鍵後的索引 (如何知道每個葉子塊儲存最大條目數，即可以定位葉子塊分裂的時間)
branch: 0x2835ceb 42163435 (0: nrow: 3, level: 1)
   leaf: 0x2835cec 42163436 (-1: nrow: 485 rrow: 485)
   leaf: 0x2835ced 42163437 (0: nrow: 480 rrow: 480) ---第二個葉子塊未分裂，但葉子塊的條目增加了1個，即新增的鍵值
   leaf: 0x2835cee 42163438 (1: nrow: 36 rrow: 36)

--再插入一箇中間鍵後的索引
branch: 0x2835ceb 42163435 (0: nrow: 3, level: 1)
   leaf: 0x2835cec 42163436 (-1: nrow: 485 rrow: 485)
   leaf: 0x2835ced 42163437 (0: nrow: 481 rrow: 481)--同上
   leaf: 0x2835cee 42163438 (1: nrow: 36 rrow: 36)

--插入多箇中間鍵值後的索引，增加一個葉子塊
branch: 0x2835ceb 42163435 (0: nrow: 4, level: 1)
   leaf: 0x2835cec 42163436 (-1: nrow: 485 rrow: 485)
   leaf: 0x2835ced 42163437 (0: nrow: 316 rrow: 316) --原葉子塊保留一部分條目，
   leaf: 0x2835cef 42163439 (1: nrow: 265 rrow: 265) --新增加的葉子塊，原葉子塊拆分一些條目插入到這個葉子塊中
   leaf: 0x2835cee 42163438 (2: nrow: 36 rrow: 36)

--可知發生了葉子塊分裂
SQL> select b.name,a.value from v$sesstat a,v$statname b where a.statistic#=b.statistic# and b.name like '%split%' and sid in(select sid from v$mystat where rownum=1);

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
leaf node splits                                                          1
leaf node 90-10 splits                                                    0
branch node splits                                                        0
root node splits                                                          0
queue splits                                                              0


---再看後者：90:10索引塊分裂

--插入多個最大鍵值後的索引
branch: 0x2835ceb 42163435 (0: nrow: 4, level: 1)
   leaf: 0x2835cec 42163436 (-1: nrow: 485 rrow: 485)
   leaf: 0x2835ced 42163437 (0: nrow: 316 rrow: 316)
   leaf: 0x2835cef 42163439 (1: nrow: 265 rrow: 265)
   leaf: 0x2835cee 42163438 (2: nrow: 536 rrow: 536)

--未發現 leaf node 90-10 splits
SQL> select b.name,a.value from v$sesstat a,v$statname b where a.statistic#=b.statistic# and b.name like '%split%' and sid in(select sid from v$mystat where rownum=1);

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
leaf node splits                                                          1
leaf node 90-10 splits                                                    0
branch node splits                                                        0
root node splits                                                          0
queue splits                                                              0

--繼續插入最大鍵值多少後的索引,發現了葉子塊分裂
branch: 0x2835ceb 42163435 (0: nrow: 5, level: 1)
   leaf: 0x2835cec 42163436 (-1: nrow: 485 rrow: 485)
   leaf: 0x2835ced 42163437 (0: nrow: 316 rrow: 316)
   leaf: 0x2835cef 42163439 (1: nrow: 265 rrow: 265)
   leaf: 0x2835cee 42163438 (2: nrow: 568 rrow: 568)
   leaf: 0x2843774 42219380 (3: nrow: 468 rrow: 468)

--發生了1次葉子塊分裂
SQL> select b.name,a.value from v$sesstat a,v$statname b where a.statistic#=b.statistic# and b.name like '%split%' and sid in(select sid from v$mystat where rownum=1);

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
leaf node splits                                                          2
leaf node 90-10 splits                                                    1
branch node splits                                                        0
root node splits                                                          0
queue splits                                                              0

另：索引的在物理不會有序，因為刪除的條目如標記為free,會被重用；故物理不會有序；

*** 2013-03-19 13:25:05.694
----- begin tree dump
branch: 0x2835ceb 42163435 (0: nrow: 222, level: 1)
   leaf: 0x2835cec 42163436 (-1: nrow: 485 rrow: 485) --就以這個為基礎測試
   leaf: 0x2835ced 42163437 (0: nrow: 479 rrow: 479)
   --略
----- end tree dump

--插入鍵值為1後的索引
leaf: 0x2835cec 42163436 (-1: nrow: 486 rrow: 486) --葉子塊增加一個條目

--重複上述動作
leaf: 0x2835cec 42163436 (-1: nrow: 487 rrow: 487)

leaf: 0x2835cec 42163436 (-1: nrow: 488 rrow: 488)---變成488

--新增多次鍵值後，發生了,出現了branch block split
----- begin tree dump
branch: 0x2835ceb 42163435 (0: nrow: 22, level: 2)
   branch: 0x2843af3 42220275 (-1: nrow: 319, level: 1)
      leaf: 0x2835cec 42163436 (-1: nrow: 279 rrow: 279) --由之前的488變為279;而且分支塊分裂很佔用資源

index block split相關一些知識

相關文章