本地管理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。
查看本文来源