- 論壇徽章:
- 0
|
在920以前,表的剩余空間的管理與分配都是由鏈接列表freelist來完成的,因為freelist存在串行的問題因此容易引起往往容易引起段頭的爭用與空間的浪費(其實這一點并不明顯),最主要的還是因為需要DBA 花費大量的精力去管理這些爭用并監(jiān)控表的空間利用!
自動段空間管理(ASSM),它首次出現(xiàn)在Oracle920里。有了ASSM,鏈接列表freelist被位圖所取代,它是一個二進制的數(shù)組,能夠迅速有效地管理存儲擴展和剩余區(qū)塊(free block),因此能夠改善分段存儲本質(zhì),ASSM表空間上創(chuàng)建的段還有另外一個稱呼叫Bitmap Managed Segments(BMB 段)!
讓我們看看位圖freelist是如何實現(xiàn)的。我會從使用區(qū)段空間管理自動參數(shù)創(chuàng)建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會使用位圖數(shù)組來自動地管理tablespace里表格和索引的freelist。對于在LMT的tablespace內(nèi)部創(chuàng)建的表格和索引而言,這個NEXT擴展子句是過時的,因為由本地管理的tablespace會管理它們。但是,INITIAL參數(shù)仍然是需要的,因為Oracle不可能提前知道初始表格加載的大小。對于ASSM而言,INITIAL最小的值是三個塊!
新的管理機制用位圖來跟蹤或管理每個分配到對象的塊,每個塊有多少剩余空間根據(jù)位圖的狀態(tài)來確定,如>75%,50%-75%,25%-50%和<25%,也就是說位圖其實采用了四個狀態(tài)位來代替以前的pctused,什么時候該利用該數(shù)據(jù)塊則由設定的pctfree來確定。
使用ASSM的一個巨大優(yōu)勢是,位圖freelist肯定能夠減輕緩沖區(qū)忙等待(buffer busy wait)的負擔,這個問題在Oracle9i以前的版本里曾是一個嚴重的問題
在沒有多個freelist的時候,每個Oracle表格和索引在表格的頭部都曾有一個數(shù)據(jù)塊,用來管理對象所使用的剩余區(qū)塊,并為任何SQL插入聲明所創(chuàng)建的新數(shù)據(jù)行提供數(shù)據(jù)塊。當數(shù)據(jù)緩沖內(nèi)的數(shù)據(jù)塊由于被另一個DML事務處理鎖定而無法使用的時候,緩沖區(qū)忙等待就會發(fā)生。當你需要將多個任務插入到同一個表格里的時候,這些任務就被強制等待,而同時Oracle會在同時分派剩余的區(qū)塊,一次一個。
有了ASSM之后,Oracle宣稱顯著地提高了DML并發(fā)操作的性能,因為(同一個)位圖的不同部分可以被同時使用,這樣就消除了尋找剩余空間的串行化。根據(jù)Oracle的測試結(jié)果,使用位圖freelist會消除所有分段頭部(對資源)的爭奪,還能獲得超快的并發(fā)插入操作
盡管ASSM顯示出了令人激動的特性并能夠簡化Oracle DBA的工作,但是Oracle9i的位圖分段管理還是有一些局限性的:
? 一旦DBA被分配之后,它就無法控制tablespace內(nèi)部的獨立表格和索引的存儲行為。
? 大型對象不能夠使用ASSM,而且必須為包含有LOB數(shù)據(jù)類型的表格創(chuàng)建分離的tablespace!
? 你不能夠使用ASSM創(chuàng)建臨時的tablespace。這是由排序時臨時分段的短暫特性所決定的!
? 只有本地管理的tablespace才能夠使用位圖分段管理!
? 使用超高容量的DML(例如INSERT、UPDATE和DELETE等)的時候可能會出現(xiàn)性能上的問題。
1、我們先創(chuàng)建一個本地管理的表空間,采用段自動管理方式
create tablespace demo
datafile '/ora01/oem/demo01.dbf '
size 50m
EXTENT MANAGEMENT LOCAL --一定是本地管理
SEGMENT SPACE MANAGEMENT AUTO; --ASSM管理的標志
2、創(chuàng)建同樣一個表
SQL> create table demotab ( x number ) tablespace demo
storage (initial 1000K);
Table created
我們指定初試區(qū)間大小是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、執(zhí)行該過程,檢查表的初始狀態(tài)
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
……
從這里可以看到,第一個區(qū)間的開始塊是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
0x06800079 Free: 5 Inst: 1
--------------------------------------------------------
End dump data blocks tsn: 6 file#: 7 minblk 10 maxblk 10
Start dump data blocks tsn: 6 file#: 7 minblk 11 maxblk 11
buffer tsn: 6 rdba: 0x0680000b (7/11)
scn: 0x0000.00181a3d seq: 0x01 flg: 0x04 tail: 0x1a3d2301
frmt: 0x02 chkval: 0x4904 type: 0x23=PAGETABLE SEGME |
|