今天在配合研发部门做压力测试时，数据库一直有一个等待时间比较高：buffer busy waits。产生等待的BUFFER可能是段头（Segment Header），也可能是数据块，UNDO数据块等，而在top sql中看到有一条需要频繁数据插入的sql处理时间很长。在网上搜索给出了几种解决方法，也给出了原因，通过尝试好发现是数据库热块引起的。下面把一些网上关于热块的文章贴出了，供以后参考！

每 个块都有一个块首部。这个块首部中有一个事务表。事务表中会建立一些条目来描述哪些事务将块上的哪些行/元素锁定。这个事务表的初始大小由对象的 INITRANS 设置指定。对于表，这个值默认为2（索引的INITRANS 也默认为2）。事务表会根据需要动态扩展，最大达到MAXTRANS 个条目（假设块上有足够的自由空间）。所分配的每个事务条目需要占用块首部中的23～24 字节的存储空间。注意，对于Oraclelog，MAXTRANS 则会忽略，所有段的MAXTRANS 都是255。

也就是说，如果某个事物锁定了这个块的数据，则会在这个地方记录事务的标识，当然那个事务要先看一下这个地方是不是已经有人占用了，如果有，则去看看那个事务是否为活动状态。如果不活动，比如已经提交或者回滚，则可以覆盖这个地方。如果活动，则需要等待(闩的作用)

所以，如果有大量的并发访问使用的这个块，则参数不能太小，否则资源竞争将导致系统并发性能下降。

1. INITRANS =1 时 并发多个INSERT 事务(本次测试最多5个)的时候并不会由于ITL的争用而等待组塞,ORACLE 采取的策略是每个INSERT事物分配不同的一些块来使用,这样各个会话之间就不会产生冲突，除非段没有多余的块(次种情况与本次的主题无关).

2.INITRANS =1 时 并发多个UPDATE事务(本次测试最多7个)的时候也不会由于ITL的争用而导致等待产生,此时ORACLE除了使用默认的ITL之外，另外动态扩展所 需要的ITL，紧紧在非常极端的情况下才会出现等待，(当然应用层面的死锁或等待与本主题无关)。
1) 该BLOCK没有FREE空间了，注意FREE参数的设置不能太小。
2) 该块使用的ITL总数，超过该块允许的ITL的最大值min(round(block_size*0.5/24) - 2 ,255) 。
要达到这样的极端情况实际的生产情况是很难的，应该比业务sql的死锁出现的概率更小。

小结：创建表的时候除非已经清楚，大部分的情况下没有必要调整INITRANS参数，通常1-4以下足够用了，INITRANS 设置非常大的时候ORACLE 有出现坏块的BUG，另外FREE 参数倒是要注意不能随意改小,除非你已经很清楚更改的后果．