ASSM.docx

上传人:b****7 文档编号:9683441 上传时间:2023-02-05 格式:DOCX 页数:18 大小:21.97KB
下载 相关 举报
ASSM.docx_第1页
第1页 / 共18页
ASSM.docx_第2页
第2页 / 共18页
ASSM.docx_第3页
第3页 / 共18页
ASSM.docx_第4页
第4页 / 共18页
ASSM.docx_第5页
第5页 / 共18页
点击查看更多>>
下载资源
资源描述

ASSM.docx

《ASSM.docx》由会员分享,可在线阅读,更多相关《ASSM.docx(18页珍藏版)》请在冰豆网上搜索。

ASSM.docx

ASSM

ASSM 说明

         在Orale9i以前,表的剩余空间的管理与分配都是由链接列表freelist来完成的,因为freelist存在串行的问题因此容易引起往往容易引起段头的争用与空间的浪费(其实这一点并不明显),最主要的还是因为需要DBA 花费大量的精力去管理这些争用并监控表的空间利用。

  

        自动段空间管理(ASSM),它首次出现在Oracle920里。

有了ASSM,链接列表freelist被位图所取代,它是一个二进制的数组,能够迅速有效地管理存储扩展和剩余区块(freeblock),因此能够改善分段存储本质,ASSM表空间上创建的段还有另外一个称呼叫BitmapManagedSegments(BMB 段)。

  

让我们看看位图freelist是如何实现的。

从使用区段空间管理自动参数创建tablespace开始:

  

createtablespacedemo  

datafile'/ora01/oem/demo01.dbf'  

size5m  

EXTENTMANAGEMENTLOCAL--TurnonLMT  

SEGMENTSPACEMANAGEMENTAUTO--TurnonASSM;  

一旦你定义好了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肯定能够减轻缓冲区忙等待(bufferbusywait)的负担,这个问题在Oracle9i以前的版本里曾是一个严重的问题 。

 

     在没有多个freelist的时候,每个Oracle表格和索引在表格的头部都曾有一个数据块,用来管理对象所使用的剩余区块,并为任何SQL插入声明所创建的新数据行提供数据块。

当数据缓冲内的数据块由于被另一个DML事务处理锁定而无法使用的时候,缓冲区忙等待就会发生。

当你需要将多个任务插入到同一个表格里的时候,这些任务就被强制等待,而同时Oracle会在同时分派剩余的区块,一次一个。

  

       有了ASSM之后,Oracle宣称显著地提高了DML并发操作的性能,因为(同一个)位图的不同部分可以被同时使用,这样就消除了寻找剩余空间的串行化。

根据Oracle的测试结果,使用位图freelist会消除所有分段头部(对资源)的争夺,还能获得超快的并发插入操作 

尽管ASSM显示出了令人激动的特性并能够简化OracleDBA的工作,但是Oracle9i的位图分段管理还是有一些局限性的:

  

     1. 一旦DBA被分配之后,它就无法控制tablespace内部的独立表格和索引的存储行为。

  

      2. 大型对象不能够使用ASSM,而且必须为包含有LOB数据类型的表格创建分离的tablespace。

  

      3. 你不能够使用ASSM创建临时的tablespace。

这是由排序时临时分段的短暂特性所决定的。

  

      4. 只有本地管理的tablespace才能够使用位图分段管理。

  

      5· 使用超高容量的DML(例如INSERT、UPDATE和DELETE等)的时候可能会出现性能上的问题。

三. 相关测试:

1、我们先创建一个本地管理的表空间,采用段自动管理方式  

/*Formattedon2009-12-719:

17:

33(QP5v5.115.810.9015)*/

CREATE TABLESPACE demo

DATAFILE 'D:

/demo01.dbf'

SIZE 50M

EXTENT MANAGEMENT LOCAL          --一定是本地管理

SEGMENT SPACE MANAGEMENT AUTO;   --ASSM管理的标志

2、创建同样一个表  

/*Formattedon2009-12-719:

18:

00(QP5v5.115.810.9015)*/

CREATE TABLE demotab (x NUMBER)

TABLESPACE demo

STORAGE (INITIAL 1000 K);

我们指定初试区间大小是1000K 

  /*Formattedon2009-12-719:

18:

37(QP5v5.115.810.9015)*/

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、执行该过程,检查表的初始状态  

exec show_space('demotab','auto','T','Y');  --show_space() 代码见附件

TotalBlocks............................128

TotalBytes.............................1048576

UnusedBlocks...........................125

UnusedBytes............................1024000

LastUsedExtFileId....................7

LastUsedExtBlockId...................9

LastUsedBlock.........................3

 *************************************************

Thesegmentisanalyzed

0%--25%freespaceblocks.............0

0%--25%freespacebytes..............0

25%--50%freespaceblocks............0

25%--50%freespacebytes.............0

50%--75%freespaceblocks............0

50%--75%freespacebytes.............0

75%--100%freespaceblocks...........0

75%--100%freespacebytes............0

UnusedBlocks...........................0

UnusedBytes............................0

TotalBlocks............................0

Totalbytes.............................0

从这里我们能看到一些该表的特性,其中最引人注意的就是表头了,占用了三个块的大小(128-125)  

    另外一个注意的地方就是该表从第9个块开始,文件头占用了64K的空间等于8个块。

  

我们从dba_extent中也能看到这样的信息,是从第9个块开始的。

/*Formattedon2009-12-719:

24:

23(QP5v5.115.810.9015)*/

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

DEMOTAB                  2         25

DEMOTAB                  3         33

DEMOTAB                  4         41

DEMOTAB                  5         49

DEMOTAB                  6         57

DEMOTAB                  7         65

DEMOTAB                  8         73

DEMOTAB                  9         81

DEMOTAB                 10         89

DEMOTAB                 11         97

DEMOTAB                 12        105

DEMOTAB                 13        113

DEMOTAB                 14        121

DEMOTAB                 15        129

从这里可以看到,第一个区间的开始块是9 

4、我直接开始分析第9,10,11个块(段头)  

SQL>altersystemdumpdatafile7block9;  

Systemaltered  

SQL>altersystemdumpdatafile7block10;  

Systemaltered  

SQL>altersystemdumpdatafile7block11;  

Systemaltered   

进入Udump 查看刚才生成的trace 文件

***2009-12-0719:

30:

16.406

***SERVICENAME:

(DBA.ANQINGREN.ORG)2009-12-0719:

30:

16.390

***SESSIONID:

(123.758)2009-12-0719:

30:

16.390

Startdumpdatablockstsn:

8file#:

7minblk9maxblk9

buffertsn:

8rdba:

0x01c00009(7/9)

scn:

0x0000.001a0da0seq:

0x01flg:

0x04tail:

0x0da02001

frmt:

0x02chkval:

0x44e6type:

0x20=FIRSTLEVELBITMAPBLOCK

Hexdumpofblock:

st=0,typ_found=1

Dumpofmemoryfrom0x085C8400to0x085CA400

85C84000000A22001C00009001A0DA004010000  [...............]

85C8410000044E6000000000000000000000000  [.D..............]

85C842000000000000000000000000000000000  [................]

        Repeat1times

85C844000000000000000000000000000000004  [................]

85C8450FFFFFFFF0000000D0000000300000010  [................]

85C846000010002000000000000000000000000  [................]

85C847000000000000000030000000000000000  [................]

85C848000000000000000000000000000000000  [................]

85C849001C0000A000000000000000000000003  [................]

85C84A00000000801C0000C0000000000000000  [................]

85C84B000000000000000000000000000000001  [................]

85C84C00000D302000000000000000001C00009  [................]

85C84D0000000080000000001C0001100000008  [................]

85C84E000000008000000000000000000000000  [................]

85C84F000000000000000000000000000000000  [................]

        Repeat8times

85C858000000000000000000000000000001011  [................]

85C859000000000000000000000000000000000  [................]

        Repeat485times

85CA3F00000000000000000000000000DA02001  [...............]

DumpofFirstLevelBitmapBlock

 --------------------------------

   nbits:

4nranges:

2         parentdba:

  0x01c0000a   poffset:

0    

   unformatted:

13      total:

16        firstusefulblock:

3     

   owninginstance:

1

   instanceownershipchangedat

   LastsuccessfulSearch

   FreenessStatus:

  nf10      nf20      nf30      nf40     

   ExtentMapBlockOffset:

4294967295

   Firstfreedatablock:

3     

   Bitmapblocklockopcode0

   Lockerxid:

     :

  0x0000.000.00000000

   Inc#:

0Objd:

54018

  HWMFlag:

HWMSet

      Highwater:

:

  0x01c0000c  ext#:

0      blk#:

3      extsize:

8    

  #blocksinseg.hdr'sfreelists:

0    

  #blocksbelow:

0    

  mapblk  0x00000000  offset:

0    

  --------------------------------------------------------

  DBARanges:

  --------------------------------------------------------

   0x01c00009  Length:

8      Offset:

0     

   0x01c00011  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

  --------------------------------------------------------

Enddumpdatablockstsn:

8file#:

7minblk9maxblk9

***2009-12-0719:

35:

44.296

Startdumpdatablockstsn:

8file#:

7minblk10maxblk10

buffertsn:

8rdba:

0x01c0000a(7/10)

scn:

0x0000.001a0dc1seq:

0x01flg:

0x04tail:

0x0dc12101

frmt:

0x02chkval:

0x5439type:

0x21=SECONDLEVELBITMAPBLOCK

Hexdumpofblock:

st=0,typ_found=1

Dumpofmemoryfrom0x085C8400to0x085CA400

85C84000000A22101C0000A001A0DC104010000  [!

...............]

85C841000005439000000000000000000000000  [9T..............]

85C842000000000000000000000000000000000  [................]

        Repeat1times

85C844000000000000000000000000001C0000B  [................]

85C845000000008000000080000000000000000  [................]

85C846000000000000000000000D30200000001  [................]

85C84700000000001C000090001000501C00019  [................]

85C84800001000501C000290001000501C00039  [....).......9...]

85C84900001000501C000490001000501C00059  [....I.......Y...]

85C84A00001000501C000690001000501C00079  [....i.......y...]

85C84B000010005000000000000000000000000  [................]

85C84C000000000000000000000000000000000  [................]

        Repeat498times

85CA3F00000000000000000000000000DC12101  [.............!

..]

DumpofSecondLevelBitmapBlock

   number:

8       nfree:

8       ffree:

0      pdba:

     0x01c0000b

   Inc#:

0Objd:

54018

  opcode:

0

 xid:

  L1Ranges:

  --------------------------------------------------------

   0x01c00009  Free:

5Inst:

1

   0x01c00019  Free:

5Inst:

1

   0x01c00029  Free:

5Inst:

1

   0x01c00039  Free:

5Inst:

1

   0x01c00049  Free:

5Inst:

1

   0x01c00059  Free:

5Inst:

1

   0x01c00069  Free:

5Inst:

1

   0x01c00079  Free:

5Inst:

1

 

  --------------------------------------------------------

Enddumpdatablockstsn:

8file#:

7minblk10maxblk10

Startdumpdatablockstsn:

8file#:

7minblk11maxblk11

buffertsn:

8rdba:

0x01c0000b(7/11)

scn:

0x0000.001a0dc6seq:

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 幼儿教育 > 育儿理论经验

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1