ASSM的局限性(转摘)

Fenng

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

一旦DBA被分配之后，它就无法控制tablespace内部的独立表格和索引的存储行为。
大型对象不能够使用ASSM，而且必须为包含有LOB数据类型的表格创建分离的tablespace。
你不能够使用ASSM创建临时的tablespace。这是由排序时临时分段的短暂特性所决定的。
只有本地管理的tablespace才能够使用位图分段管理。
使用超高容量的DML（例如INSERT、UPDATE和DELETE等）的时候可能会出现性能上的问题。


当然不止这些了，抛个砖而已

biti_rainy

1： 没有类似master freelist的功能,如果delete可能导致各部分使用空间可能不均衡，那oracle对于insert的时候采取怎样的算法呢？各部分是不是有一个使用率的界定？插入一条记录的时候选择一个  区段 ，这个选择代价不能太大，但又不能偏颇？

2： 对于自动管理，总是存在很多疑虑的，除非oracle只支持 自动管理，否则总是有局限的，就好比不敢轻易使用 UNDO表空间一样

小猪猪

FENNG也不转载全

打PP

为了保持其最强大和最灵活数据库的地位，Oracle在最近发布的几个版本里一直都在创建新的机制来对表格和索引的存储进行简化和分块。从Oracle8i开始，Oracle开始在tablespace内部将对象管理进行自动化。第一个增强的地方原来叫做本地管理tablespace（或者简写作LMT）。在LMT里，Oracle将tablespace里的信息从数据字典的表格空间里移出去，而直接将其保存到tablespace自身里。这在Oracle9i里已经成为了一个事实的标准，因为它减轻了数据字典的负担。

  

表格空间的第二个主要增强的是自动分段空间管理（ASSM），它首次出现在Oracle9i里。有了ASSM，链接列表freelist被位图所取代，它是一个二进制的数组，能够迅速有效地管理存储扩展和剩余区块（free block），因此能够改善分段存储本质。


管理空间的两种方法

让我们从比较这两种空间管理开始：

本地管理tablespace（LMT）——LMT是通过把EXTENT MANAGEMENT LOCAL子句添加到tablespace的定义句法而实现的。和原来由字典管理的tablespace（DMT）不同，LMT会将扩展管理自动化，并保持Oracle DBA不会被用来指定管理扩展大小的NEXT存储参数。这个原则唯一的例外是在NEXT和MINEXTENTS一起用在表格创建的时候。
自动区段空间管理（ASSM）——ASSM的tablespace是通过将SEGMENT SPACE MANAGEMENT AUTO子句添加到tablespace的定义句法里而实现的。通过使用位图freelist取代传统单向的链接列表freelist，ASSM的tablespace会将freelist的管理自动化，并取消为独立的表格和索引指定PCTUSED、FREELISTS和FREELIST GROUPS存储参数的能力。

Oracle值得赞扬的地方是，这两个空间管理的方法都是可选的特性，而且Oracle的老手可能仍会使用更加详细的方法，只要他们愿意的话。要注意，位图区段管理在Oracle9i里是可选的，而且只能在tablespace这一层实现，这一点是十分重要的。原有的系统还能够继续使用传统方法来管理freelist。

位图freelist挑战传统的空间管理
在我讨论位图freelist和传统的空间管理之前，让我们看看位图freelist是如何实现的。我会从使用区段空间管理自动参数创建tablespace开始：


     
    create tablespace
       asm_lmt_ts
    datafile
       'c:\oracle\oradata\diogenes\asm_lmt.dbf'
    size
       5m
    EXTENT MANAGEMENT LOCAL       -- Turn on LMT
    SEGMENT SPACE MANAGEMENT AUTO -- Turn on ASSM
    ;
     


一旦你定义好了tablespace，那么表格和索引就能够使用各种方法很容易地被移动到新的tablespace里。下面就是我进行创建的代码：

     
    create table
       new_cust
    tablespace
       assm_lmt_ts
    as
       select * from customer;
     
    alter index cust_name_idx rebuild tablespace assm_lmt_ts;
     
   
  

要注意，当表格或者索引被分配到这个tablespace以后，用于独立对象的PCTUSED的值会被忽略，而Oracle9i会使用位图数组来自动地管理tablespace里表格和索引的freelist。对于在LMT的tablespace内部创建的表格和索引而言，这个NEXT扩展子句是过时的，因为由本地管理的tablespace会管理它们。但是，INITIAL参数仍然是需要的，因为Oracle不可能提前知道初始表格加载的大小。对于ASSM而言，INITIAL最小的值是三个区块。

关于一个万能的方法对于Oracle来说是否是最好的方法还有一些争论。在大型数据库里，单独的对象设置会带来性能和存储上的巨大不同。


PCTFREE的问题

  

PCTFREE参数是用来指定数据块剩余空间大小的，这一空间为将来数据行的扩展而保留。如果PCTFREE设置得不得当，SQL的更新声明就可能导致大量的数据行碎片和断链。

数据行在刚保存的时候还很小，而在后来进行了扩展，在这种情况下，PCTFREE的设置就显得尤其重要了。在这样的系统里，通常会把PCTFREE设置成等于95，这就告诉Oracle要为数据行今后的扩展保留95％的数据区段空间。



PCTUSED的问题

对PCTUSED不正确的设置（例如设得太小了）会导致SQL插入声明性能的急剧下降。如果数据区块剩余空间不是很多，那么在SQL插入操作的过程中就会产生过量的I/O，这是因为被重新使用的Oracle数据区块会被迅速地填满。从极端的角度来看，没有正确地设置PCTUSED会导致数据区块的剩余空间要比表格数据行的平均长度小。在这样的情况下，Oracle会五次尝试从freelist链取回区块。在五次尝试以后，Oracle会提升表格的水位，并为插入操作腾出五个新的数据块。

有了Oracle9i的ASSM，PCTUSED就不再控制表格数据块的重新链接阙值了，但是你必须依靠Oracle的判断来确定区块在什么时候会有足够的剩余空间放置到freelist里。

尽管有了本地管理的tablespace和ASSM之后Oracle9i会忽略PCTUSED、FREELISTS和FREELIST GROUPS等参数，但是当它们用于表格定义的时候，Oracle还是不会给出错误信息：


     
    SQL> create table
    2 test_table
    3 (c1 number)
    4 tablespace
    5 asm_test
    6 pctfree 20 pctused 30
    7 storage
    8 ( freelists 23 next 5m ) ;
    Table created.
   


如果你不记得带有ASSM的本地管理tablespace会略掉任何为PCTUSED、NEXT和FREELISTS所指定的值的话，这将是一个十分严重的问题。.

使用ASSM的一个巨大优势是，位图freelist肯定能够减轻缓冲区忙等待（buffer busy wait）的负担，这个问题在Oracle9i以前的版本里曾是一个严重的问题。现在让我们来仔细看看这个特性。

缓冲区不再忙等待
在没有多个freelist的时候，每个Oracle表格和索引在表格的头部都曾有一个数据块，用来管理对象所使用的剩余区块，并为任何SQL插入声明所创建的新数据行提供数据块。当数据缓冲内的数据块由于被另一个DML事务处理锁定而无法使用的时候，缓冲区忙等待就会发生。当你需要将多个任务插入到同一个表格里的时候，这些任务就被强制等待，而同时Oracle会在同时分派剩余的区块，一次一个。

有了ASSM之后，Oracle宣称显著地提高了DML并发操作的性能，因为（同一个）位图的不同部分可以被同时使用，这样就消除了寻找剩余空间的串行化。根据Oracle的测试结果，使用位图freelist会消除所有分段头部（对资源）的争夺，还能获得超快的并发插入操作


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

一旦DBA被分配之后，它就无法控制tablespace内部的独立表格和索引的存储行为。
大型对象不能够使用ASSM，而且必须为包含有LOB数据类型的表格创建分离的tablespace。
你不能够使用ASSM创建临时的tablespace。这是由排序时临时分段的短暂特性所决定的。
只有本地管理的tablespace才能够使用位图分段管理。
使用超高容量的DML（例如INSERT、UPDATE和DELETE等）的时候可能会出现性能上的问题。

在我下一篇文章里，我将解释如何获得一些用于DBA的新工具，还有Oracle9i的ASSM特性。我还将看看你要如何将这些工具和ASSM一起使用。

biti_rainy

在另外一篇文章中，大师指出：
oracle对于assm中块的使用率标志有四种：
0---25,25---50,50----75,75--100

所以联合  pctfree，在做判断的时候是否会出现问题,就是使得  实质上的 pctused 显得过高，假设pctfree = 10 ,则pctused 实质上成为了 75,pctfree = 26则 pctused实质上成为了 50   ?

Automatic Segment Space Management

This is the concept of locally managed segments - must be set at tablespace level and in LMTs only. Each extent in the segment has a bitmap block containing a set of bits to represent the 'fullness' of each block in the extent. For large extents, a hierarchy of bitmap blocks is required.

create tablespace ...
segment space management auto;

Each block in the extent can be either 0-25% full, 25-50% full, 50-75% full or 75-100% full and the bits will be set accordingly. An additional bit indicates whether or not pctfree has been exceeded. Eg. For a pctfree of 10%, a block would be considered to have free space unless the bit representing 75-100% had been set. If the block utilisation dropped below 75% full, the bit for the block would be cleared and the block could then be considered for row insertion.

This introduces a complication in that each extent now has it's own high water mark. Forunately, free blocks above this extent high water mark (now known as unformatted) are not read when the table is full table scanned.

Some observations about ASSM:

Heavy, concurrent inserts will spray rows across extents and could even distribute rows randomly within an extent. This will have a significant impact on the clustering factor for any indexes created on the table.

Full table scans read the extent bitmap to determine which blocks in the extent are unformatted (ie. above the extent high water mark).

What would happen if adjusting pctfree would cause a block to cross a 'fullness' boundary? The bitmaps would not represent the blocks accurately. Fortunately, DBMS_REPAIR now includes a SEGMENT_FIX_STATUS procedure to account for this. You would need to remember to run this procedure if you adjust pctfree for any segment in an ASSM tablespace.


On a personal note, I fail to see any advantage of ASSM. It cannot benefit concurrency (and therefore scalability) and depending on the number of extents and the pctfree setting, you could end up wasting space at best and seriously damaging performance at worst (as indexes become less viable). To me, it seems that Oracle is attempting to 'dumb down' what is an extremely important and fundamental aspect of data storage. What was wrong with freelists anyway? The 'less performance in exchange for low maintenance' trade-off doesn't work because of the issue with changing pctfree.

Fenng

呵呵，回小猪猪，我是＊转摘＊的

ken000

小猪猪的下篇文章呢

biti_rainy

说如果 你不信任 auto ,这就不适合你

我问什么情况下用起来有问题

只说 ASSM 的详细内容是没有公布在文档上的，将在每一个版本不停的更新，所以看样子他并不愿意过多的讨论这个话题，因为一切都是变化的，assm本身的东西都还在不停的变化完善之中。所以，谁愿意去吃螃蟹先吃了  

biti_rainy

他说
assm详细内容还没有公布在文档上，在oracle内部都还在随着版本不停的更新，不断的完善过程中，所以似乎他不愿意讨论这个问题

看样子，就等大家去吃螃蟹了

因为一个东西好不好，还是要 实践  来检验呀，谁都不能乱说呀

Fenng

Tom关于技术细节的东西都不愿意回答的

呵呵，他是个专家，还不是大师

小猪猪

我在ZDNET上找到的
就贴过来了