亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

  免費注冊 查看新帖 |

Chinaunix

  平臺 論壇 博客 文庫
最近訪問板塊 發(fā)新帖
查看: 2714 | 回復: 2
打印 上一主題 下一主題

ASSM管理(BMB段管理)的內(nèi)部機理 [復制鏈接]

論壇徽章:
0
跳轉(zhuǎn)到指定樓層
1 [收藏(0)] [報告]
發(fā)表于 2011-02-14 10:22 |只看該作者 |倒序瀏覽
在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

論壇徽章:
59
2015七夕節(jié)徽章
日期:2015-08-24 11:17:25ChinaUnix專家徽章
日期:2015-07-20 09:19:30每周論壇發(fā)貼之星
日期:2015-07-20 09:19:42ChinaUnix元老
日期:2015-07-20 11:04:38榮譽版主
日期:2015-07-20 11:05:19巳蛇
日期:2015-07-20 11:05:26CU十二周年紀念徽章
日期:2015-07-20 11:05:27IT運維版塊每日發(fā)帖之星
日期:2015-07-20 11:05:34操作系統(tǒng)版塊每日發(fā)帖之星
日期:2015-07-20 11:05:36程序設計版塊每日發(fā)帖之星
日期:2015-07-20 11:05:40數(shù)據(jù)庫技術(shù)版塊每日發(fā)帖之星
日期:2015-07-20 11:05:432015年辭舊歲徽章
日期:2015-07-20 11:05:44
2 [報告]
發(fā)表于 2011-02-14 10:25 |只看該作者
學習了。太厲害了。

論壇徽章:
0
3 [報告]
發(fā)表于 2011-02-15 15:55 |只看該作者
學習了
您需要登錄后才可以回帖 登錄 | 注冊

本版積分規(guī)則 發(fā)表回復

  

北京盛拓優(yōu)訊信息技術(shù)有限公司. 版權(quán)所有 京ICP備16024965號-6 北京市公安局海淀分局網(wǎng)監(jiān)中心備案編號:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年舉報專區(qū)
中國互聯(lián)網(wǎng)協(xié)會會員  聯(lián)系我們:huangweiwei@itpub.net
感謝所有關(guān)心和支持過ChinaUnix的朋友們 轉(zhuǎn)載本站內(nèi)容請注明原作者名及出處

清除 Cookies - ChinaUnix - Archiver - WAP - TOP