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。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/8225414/viewspace-957093/ ,如需转载,请注明出处,否则将追究法律责任。