偶尔有空上来看看
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
分类： oracle
2010-03-31 15:12:22
创建表的时候，选择合适的extent大小是十分重要的，过小的extent大小会导致过多的扩展，影响大数据量插入的性能。这对于存在大量并发插入的情况尤为重要。不过我们也不需要过于担心extent大小带来的性能问题，我们讨论的性能下降可能是千分之一，甚至更小，实际上，一个段拥有小于1024个extent对段的访问性能的影响很小
下一个问题就是表空间碎片的问题，由于一个表空间中的表的extent大小不同，因此表空间使用一段时间后，表空间的使用就出现了不连续，在extent之间会出现一些“洞”，这种情况我们一般叫做表空间碎片。一些老dba总是告诫别人，注意整理表空间碎片，否则会影响数据库的性能。实际上，从根本上来说，表空间碎片最大的危害是浪费了空间，而不是影响了性能。所有的数据访问都会在有效地extent中进行，根本不会去扫描碎片所载的数据块，所以说表空间碎片会影响性能是一种以讹传讹的观点。
事实上，对于表的参数定义来说，设置合理的pctfree值比减少表空间碎片要重要的多，老白碰到的客户中，能够根据表和业务的特点来设计pctfree的情况少之又少。不合理的pctfree可能导致大量行链的出现，影响访问性能。
在创建表的时候，还有一个十分重要的参数就是initrans，这个参数指定了初始化事务槽的数量。事务槽是一个十分重要的对象，每个事务要修改某个数据块的时候，需要在这个数据块中分配一个事务槽。如果当前没有空闲的事务槽，就需要动态扩展一个，每个事务槽需要24个字节，讲到事务槽，大家可能明白了oracle分配空间为什么要从底部向顶部分配空间了，事务槽是从顶部向底部分配空间的，这样的话，两个分配方式不会冲突。一般情况下，缺省的事务槽参数并不会带来明显的性能问题，不过对于一些并发修改较大的表，如果pctfree参数设置过低，就会导致事务槽扩展的时候无法分配空间，从而导致事务等待事务槽。我们可以通过如下脚本来检查系统中那些表产生了较为严重的事务槽等待：
set line 132
col statistic_name format a30 trunc
select t.owner, t.object_name, t.object_type, statistic_name, t.value value
from v$segment_statistics t
where t.statistic_name = 'itl waits'
and t.value > 10 order by value;
如果上面的查询查出来的事务槽等待较为严重的段，那么我们就需要考虑对这些段增加initrans参数的值了。不过我们查看到的值是数据库启动以来的总的统计值，因此我们需要通过一个时间段中多次执行这个sql，从而判断是否某个段真正经常出现itl等待。在修改initrans参数的时候，我们也要注意，我们修改了这个参数后，这个段中新增的数据块会增加初始化事务槽的数量，老的数据块是不会改变的，如果要彻底解决问题，还需要对这个段进行一次重组。