ASSM內部存儲研究大揭密
2024-07-21 02:37:59
供稿：網友
因為ASSM的官方文檔很少，經過多次的查證之后，終于弄明白了ASSM治理（BMB段治理）的內部機理，現在發表給大家共享，此文版權所有，嚴禁轉載！！！！！！
因為資料有限，假如有錯誤，請大家指正
為了進一步讓大家明白ASSM，先說明ASSM的基本情況！
-----------------------------------------------------------------------------------------------------
在920以前，表的剩余空間的治理與分配都是由鏈接列表freelist來完成的，因為freelist存在串行的問題因此輕易引起往往輕易引起段頭的爭用與空間的浪費（其實這一點并不明顯），最主要的還是因為需要DBA 花費大量的精力去治理這些爭用并監控表的空間利用。
自動段空間治理（ASSM），它首次出現在Oracle920里。有了ASSM，鏈接列表freelist被位圖所取代，它是一個二進制的數組，能夠迅速有效地治理存儲擴展和剩余區塊（free block），因此能夠改善分段存儲本質，ASSM表空間上創建的段還有另外一個稱呼叫Bitmap Managed Segments（BMB 段）。
讓我們看看位圖freelist是如何實現的。我會從使用區段空間治理自動參數創建tablespace開始：
create tablespace demo
datafile '/ora01/oem/demo01.dbf '
size 5m
EXTENT MANAGEMENT LOCAL -- Turn on LMT
SEGMENT SPACE MANAGEMENT AUTO -- Turn on ASSM;
一旦你定義好了tablespace，那么表和索引就能夠使用各種方法很輕易地被移動到新的tablespace里，帶有ASSM的本地治理tablespace會略掉任何為PCTUSED、NEXT和FREELISTS所指定的值。
當表格或者索引被分配到這個tablespace以后，用于獨立對象的PCTUSED的值會被忽略，而Oracle9i會使用位圖數組來自動地治理tablespace里表格和索引的freelist。對于在LMT的tablespace內部創建的表格和索引而言，這個NEXT擴展子句是過時的，因為由本地治理的tablespace會治理它們。但是，INITIAL參數仍然是需要的，因為Oracle不可能提前知道初始表格加載的大小。對于ASSM而言，INITIAL最小的值是三個塊。
新的治理機制用位圖來跟蹤或治理每個分配到對象的塊，每個塊有多少剩余空間根據位圖的狀態來確定，如>75%,50%-75%,25%-50%和<25%，也就是說位圖其實采用了四個狀態位來代替以前的pctused，什么時候該利用該數據塊則由設定的pctfree來確定。
使用ASSM的一個巨大優勢是，位圖freelist肯定能夠減輕緩沖區忙等待（buffer busy wait）的負擔，這個問題在Oracle9i以前的版本里曾是一個嚴重的問題,在沒有多個freelist的時候，每個Oracle表格和索引在表格的頭部都曾有一個數據塊，用來治理對象所使用的剩余區塊，并為任何SQL插入聲明所創建的新數據行提供數據塊。當數據緩沖內的數據塊由于被另一個DML事務處理鎖定而無法使用的時候，緩沖區忙等待就會發生。當你需要將多個任務插入到同一個表格里的時候，這些任務就被強制等待，而同時Oracle會在同時分派剩余的區塊，一次一個。
有了ASSM之后，Oracle宣稱顯著地提高了DML并發操作的性能，因為（同一個）位圖的不同部分可以被同時使用，這樣就消除了尋找剩余空間的串行化。根據Oracle的測試結果，使用位圖freelist會消除所有分段頭部（對資源）的爭奪，還能獲得超快的并發插入操作
盡管ASSM顯示出了令人激動的特性并能夠簡化Oracle DBA的工作，但是Oracle9i的位圖分段治理還是有一些局限性的：
• 一旦DBA被分配之后，它就無法控制tablespace內部的獨立表格和索引的存儲行為。
• 大型對象不能夠使用ASSM，而且必須為包含有LOB數據類型的表格創建分離的tablespace。
• 你不能夠使用ASSM創建臨時的tablespace。這是由排序時臨時分段的短暫特性所決定的。
• 只有本地治理的tablespace才能夠使用位圖分段治理。
• 使用超高容量的DML（例如INSERT、UPDATE和DELETE等）的時候可能會出現性能上的問題。
ASSM到底是怎么回事，表是怎么結構的呢？
----------------------------------------------------------------------------------
要害字：ASSM，自動段治理
BMB Segment 位圖塊段治理
1、我們先創建一個本地治理的表空間，采用段自動治理方式
create tablespace demo
datafile '/ora01/oem/demo01.dbf '
size 50m
EXTENT MANAGEMENT LOCAL --一定是本地治理
SEGMENT SPACE MANAGEMENT AUTO; --ASSM治理的標志
2、創建同樣一個表
SQL> create table demotab ( x number ) tablespace demo
storage (initial 1000K);
Table created
我們指定初試區間大小是1000K
SQL> select t.table_name,t.initial_extent,t.next_extent,t.pct_free,t.pct_used from user_tables t where t.table_name = 'DEMOTAB';
TABLE_NAME INITIAL_EXTENT NEXT_EXTENT PCT_FREE PCT_USED
------------------------------ -------------- ----------- ---------- ----------
DEMOTAB 1024000 10
可以看到，NEXT_EXTENT與PCT_USED都為空。
3、執行該過程，檢查表的初始狀態
SQL> exec show_space('demotab');
Total Blocks............................128
Total Bytes.............................1048576
Unused Blocks...........................125
Unused Bytes............................1024000
Last Used Ext FileId....................7
Last Used Ext BlockId...................8
Last Used Block.........................3
從這里我們能看到一些該表的特性，其中最引人注重的就是表頭了，占用了三個塊的大小（128-125）
另外一個注重的地方就是該表從第8個塊開始，但是實際上這里是錯誤的，應當是從第9個塊開始，文件頭占用了64K的空間等于8個塊。
我們從dba_extent中也能看到這樣的信息，實際上是從第9個塊開始的。
SQL> select t.segment_name,t.extent_id,t.block_id from dba_extents t where t.segment_name = 'DEMOTAB';
SEGMENT_NAME EXTENT_ID BLOCK_ID
-------------------------------------------------------------------------------- ---------- ----------
DEMOTAB 0 9
DEMOTAB 1 17
……
從這里可以看到，第一個區間的開始塊是9
4、我直接開始分析第9，10，11個塊（段頭）
SQL> alter system dump datafile 7 block 9;
System altered
SQL> alter system dump datafile 7 block 10;
System altered
SQL> alter system dump datafile 7 block 11;
System altered
Start dump data blocks tsn: 6 file#: 7 minblk 9 maxblk 9
buffer tsn: 6 rdba: 0x06800009 (7/9)
scn: 0x0000.00181a2c seq: 0x01 flg: 0x04 tail: 0x1a2c2001
frmt: 0x02 chkval: 0x30a6 type: 0x20=FIRST LEVEL BITMAP BLOCK
Dump of First Level Bitmap Block
--------------------------------
nbits : 4 nranges: 2 parent dba: 0x0680000a poffset: 0
unformatted: 13 total: 16 first useful block: 3
owning instance : 1
instance ownership changed at
Last sUCcessful Search
Freeness Status: nf1 0 nf2 0 nf3 0 nf4 0
Extent Map Block Offset: 4294967295
First free datablock : 3
Bitmap block lock opcode 0
Locker xid: : 0x0000.000.00000000
Highwater:: 0x0680000c ext#: 0 blk#: 3 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 0
HWM Flag: HWM Set
--------------------------------------------------------
DBA Ranges :
--------------------------------------------------------
0x06800009 Length: 8 Offset: 0
0x06800011 Length: 8 Offset: 8
0:Metadata 1:Metadata 2:Metadata 3:unformatted
4:unformatted 5:unformatted 6:unformatted 7:unformatted
8:unformatted 9:unformatted 10:unformatted 11:unformatted
12:unformatted 13:unformatted 14:unformatted 15:unformatted
--------------------------------------------------------
End dump data blocks tsn: 6 file#: 7 minblk 9 maxblk 9
Start dump data blocks tsn: 6 file#: 7 minblk 10 maxblk 10
buffer tsn: 6 rdba: 0x0680000a (7/10)
scn: 0x0000.00181a39 seq: 0x01 flg: 0x04 tail: 0x1a392101
frmt: 0x02 chkval: 0x2738 type: 0x21=SECOND LEVEL BITMAP BLOCK
Dump of Second Level Bitmap Block
number: 8 nfree: 8 ffree: 0 pdba: 0x0680000b
opcode:0
xid:
L1 Ranges :
--------------------------------------------------------
0x06800009 Free: 5 Inst: 1
0x06800019 Free: 5 Inst: 1
0x06800029 Free: 5 Inst: 1
0x06800039 Free: 5 Inst: 1
0x06800049 Free: 5 Inst: 1
0x06800059 Free: 5 Inst: 1
0x06800069 Free: 5 Inst: 1< right">（出處：清風軟件下載學院）
