最近某客户9208环境,遭遇latch free问题,而在oracle 9i版本中,latch free 只是一个汇总类型的event。
换句话讲，有多种event的表现其实都是通过latch free来呈现。 客户这里的实际情况查询是主要体现在：

row cache objects和cache buffer chains. 对于cache buffer chains，相对比较简单，通常也就是热块或
SQL效率问题。而 row cache objects相对麻烦一些,客户的环境经过分析发现的row cache中的dc_rollback_segs
等待严重导致，如下：

针对这个问题，似乎不太好处理，mos提供了一个通过调整_rollback_segment_count参数来避免该问题，而且还不一定有效。

我们先不管是否有效，那么这个参数有何作用 ？ 通过10gR2 环境来研究一下。

++++++Session 1

我们先来看下level 2的dump，看下row cache objects的dc是不是41个，如下：

我们可以看到，确认是41个,跟我们查询v$latch_children是符合的.

+++++Session 2

从上面的trace我们可以发现,保护dc_rollback_segments row cache的bucket有30个,如下：

从该trace我们可以看到buckets的个数以及hash chain的情况，如下：

我们看到，此时有2种hash chain size,分别是0和1. 其中1 表示当前存放内容的hash chain，保护了636个buckets。 另外
hash chain size 为0的，表示这部分的64900 个bucket是空闲的，也就是说没有其中没有任何内容.

下面我们将参数_rollback_segment_count调整为6，然后再来观察下保护dc_rollback_segments的bucket有多少个。

注意：_rollback_segment_count参数是指数据库中保持online回滚段的个数(非SYSTEM回滚段,sysem回滚段总是online的)

+++++Session 3

我们来看下调整参数之后保护dc_rollback_segments 的bucket有没有变化：
[root@killdb ~]# cat /home/ora10g/admin/roger/udump/roger_ora_20510_001.trc|grep dc_rollback_segments|wc -l
30

我们这里来看似乎仍然是30，真的吗 ？我们先来看下此时一共有多个bucket：

当前库中此时使用的bucket有220个，因为我将db重启了，所以这个比之前要少,是正常的。 我们重点是来看
保护dc_rollback_segments的bucket是不是有所变化 ？

打开trace文件，搜索发现确认有所降低，如下：

我们可以看到，此时虽然count显示是有30个bucket在保护dc_rollback_segments，然而实际上
bucket 48/86/91分别保护了3、2、2个object. 换句话讲，实际上用到的bucket就应该是30-(3+2+2)+3=26.

从上面的实验来看，_rollback_segment_count参数确认影响row cache中保护dc_*对象的bucket数量，
总体原则就是参数越大，bucket就越多，反之亦然.

简单的总结一下：
1. _rollback_segment_count参数是控制非SYSTEM回滚段处于online状态的个数;
2. _rollback_segment_count参数越大,保持online状态的回滚段就越多。9i默认情况下oracle会自己去进行判断，
有自己的算法，随着不停的inactive和active操作,smon去offline和online回滚段,会加剧系统资源的消耗;
3. hash bucket数量越多,那么也就越不容易导致竞争。