Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

最近某客户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数量越多,那么也就越不容易导致竞争。

    分享到:
18180207355
加Q咨询