ASSM原理

     为什么要引入ASSM:  在920以前，表的剩余空间的管理与分配都是由链接列表freelist来完成的，因为freelist存在串行的问题因此容易引起往往容易引起段头的争用与空间的浪费（其实这一点并不明显），最主要的还是因为需要DBA 花费大量的精力去管理这些争用并监控表的空间利用。新的管理机制用位图来跟踪或管理每个分配到对象的块，每个块有多少剩余空间根据位图的状态来确定，如>75%,50%-75%,25%-50%和<25%，也就是说位图其实采用了四个状态位来代替以前的pctused，什么时候该利用该数据块则由设定的pctfree来确定。根据Oracle的测试结果，使用位图freelist会消除所有分段头部（对资源）的争夺，还能获得超快的并发插入操作。尽管ASSM显示出了令人激动的特性并能够简化Oracle DBA的工作，但是Oracle9i的位图分段管理还是有一些局限性的：
· 一旦DBA被分配之后，它就无法控制tablespace内部的独立表格和索引的存储行为。 
· 大型对象不能够使用ASSM，而且必须为包含有LOB数据类型的表格创建分离的tablespace。 
· 你不能够使用ASSM创建临时的tablespace。这是由排序时临时分段的短暂特性所决定的。 

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

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

 

L3 BMB实际上是链表的形式，第二个L3 BMB出现的可能性都非常小。

BMB内部机制说明

      BMB由三级构成，L3 BMB是顶级别，它含有L2 BMB的列表，没有饱和信息。L2 BMB是次级，它含有L1 BMB,并有L1 BMB的饱和信息。L1 BMB是最后一级，它含有Block的饱和度(5级)。跟ExtentMap一样，第一个 L3 BMP含在SegmentHeader中，出现第二个L3 BMP的可能性几乎没有。表非常大的时候，可能会出出现第二个L2 BMB。对于8K的block，小于2G的表，基本上只有1个L2,L3 BMB.。为了减少contention, 开始每个L1 BMB只map很少数据的Block,但是随着表的增大ORACLE 会增加L1 BMB能map的Blocks数目，以减少过多的L1 BMB。

SegmentSize        Blocks Maped by L1 BMB

<1M        16

<64M        64

<!G        256

>1G        1024

      Segment Header和三级BMB都以Metadata块的形式放在Extent的起始部分，如果Extent比较大，一个 L1 BMB不够用，就用多个来表示；反之，如果Extent很小则一个L1 BMB被分成多个段，每个段map一个extent的blocks，因为多个extent可能是不连续的，那么有的Extent的起始部分没有Metadata块。L1 BMB可能是3bit表示一个Block,它有下列7种状态：

l        Metadata

l        Unformated

l        00%-25%Free

l        25%-50%Free

l        50%-75%Free

l        75%-100%Free

l        FULL

ASSM中的Extent结构