本地治理tablespace（LMT）和自动分段空间治理（ASSM）提供了一种治理数据库里个体对象freelist的新方法。除了这些ASSM特性，Oracle9i还提供了几个新的DBMS PL/SQL工具包，用来使用ASSM查看和治理tablespace。这些工具包包括：
dbms_space.space_usage
dbms_repair.rebuild_freelists
现在让我们来看看这些工具包是如何使用ASSM的tablespace的。
关于ASSM的补充材料
要获得更多关于ASSM的信息，请阅读我的 上一篇文章 。
Oracle8i里稀疏表格的问题
假如一个高度动态的对象（例如表格或者索引）由多个freelist来定义，而且对这个表格的INSERT和DELETE活动繁重，那么在这种情况下，稀疏表格通常就会在非ASSM的tablespace中发生。在稀疏表格里，表格会显示有数千个剩余的区块，然而这个表格却会不断地扩展。其行为就似乎Oracle没有任何剩余的数据块了。
数据仓里的稀疏表格会消耗掉巨大的不必要的存储空间，即使在表格还有很多剩余空间的情况下，它们还是会消耗掉很多G字节的新存储空间。要记住，当你有多个freelist的时候，freelists是独立的，而且Oracle不能分享freelist的区块。不管你是否在使用ASSM，任何INSERT SQL声明都只会附加到一个freelist里，而且它只会使用附加到那个freelist里的剩余区块（见图A）。
图A
Oracle8i里不平衡的freelist
导致稀疏表格的原因是在INSERT和DELETE并发活动之间缺乏负载平衡。在这个例子里，我有三个为表格定义的freelist，但是一个清除任务（SQL删除操作）作为单个任务在运行。由于这个删除任务只附加到了这三个freelist中的一个里，所以所有被删除的区块都被添加到了这个freelist。在Oracle9i以前的版本里，DBA不得不将所有对FREELISTS值的清除任务并行化，这样才能保证所有的freelist都被空数据块平均地填充了。
还是在Oracle9i以前的版本里，DBA不得不使用导入／导出（eXPort/import）或者alter table move来重新组织表格，这样才能平衡每个freelist链上的剩余区块。Oracle9i使用了dbms_repair.rebuild_freelists过程，这就让这一工作简单得多了。rebuild_freelists过程的目的是将位图freelist区块和主freelist接合起来，并为区段清除掉其他所有的freelist。对于被真正应用集群使用多个freelist groups所访问的表格和索引，Oracle9i会在原有的freelist组中平均分配剩余区块。
对于带有多个freelist的表格和索引来说，这是一个重要的特性，因为DBA不再需要重新组织表格已重新平衡过了的位图freelist。这里有一个例子，是这个过程被用来为EMP表格重建freelist的：
dbms_repair.rebuild_freelists('SCOTT','EMP');
Oracle9i里用于位图freelist的查看表
Oracle9i还有几个新的v$和x$查看表，这些查看表会显示ASSM位图freelist的状态。事务处理freelist被保存在x$kvii固定表格的ktsmtf数据列内部，而v$waitstat查看表包含了位图freelist的信息。要记住，带有ASSM的freelist结构已经从单向链接列表变更为了位图freelist。在下面的例子里，你会看到所有和位图区块或者位图索引块相关的系统等待：
select
class,
count,
time
from
v$waitstat
where
class like 'bitmap%';
有了多位图的特性，你就应该会很少看到任何等待了，因为有多个位图freelist可供并发DML使用，就像下面这个例子一样：
CLASS COUNT TIME
------------------------
bitmap block 173 121
bitmap index block 206 43
有多少个DBA会使用ASSM？
到底有多少个有经验的DBA会开始使用ASSM以及有多少会继续使用原来的方法还有待观察。虽然ASSM许诺为多个DML声明提供更高的吞吐量，但是Oracle的专家还是必须小心数据行链，并记得在适当的时候为每个表格或者索引使用PCTFREE。
