怪异的latch free – session allocation事件
..
<!--/post-title -->..
本来一直想写这个的,不过最近感觉身体不好,今天才写出来.
10月5日晚上,在客户现场配合业务运行.业务开始后,发现作同样业务的系统,有一个系统十分不正常,速度不如另外一个系统的1/4.客户无法忍受,其实我也无法忍受了,如果照那个速度,我估计要联系工作24小时才可以.
没有办法,对系统进行检查.发现在不正常的系统中,产生了严重的latch free等待.当看到这个的时候,我第一反应是sql语句有问题或者产生了热点,因为应用干的活是在一个表中查询,通过索引查询,但是同时有几十个session作同样的事情.仔细检查了sql语句,语句非常简单.
select user_id,nvl(substr(os_status,:”SYS_B_0″,:”SYS_B_1″),:”SYS_B_2″),nvl(substr(os_status,:”SYS_B_3″,:”SYS_B_4″),:”SYS_B_5″) fromtable_name where acc_id = :f1
而执行计划走的索引,也是在acc_id上的索引.
经过检查索引和表的状态,发现表基本没有碎片,索引也是被最近被重建过的(后来才发现,问题就出在重建这个索引上,这是后话).
分析系统的latch free的小类，发现系统中，排名最高的几种latch free事件如下：
LATCH# NAME GETS MISSES SLEEPS
row cache objects 7309905930 1076355567 24799351
shared pool 1.2642E+10 168368806 28928269
process allocation 102171945 9233300 29316107
library cache 2.9539E+10 1234502998 87366744
session allocation 3091150764 514908537 244535123
从这个看，sleeps最多的事件是session allocation，并且，该事件的misses/gets超过了10％。
跟踪产生latch free的session，发现根本无法获得trace文件。Session会立刻断开。
分析listener.log，发现网络连接并无问题。经过分析和判断，初步认定该问题应该是由session的不断创建和退出引起，查询v$px_session发现，果然有session不断的在创建和退出。
分析后，我们认为，产生该问题，可能是由于并发查询引起。仔细检查使用的表,发现表的degree为1,并无问题,分析使用到的那个索引,该索引的degree为15.这就是问题所在了,也是为什么查询中,无法trace session,因为session会立刻断开,到此也明白问题所在了.
因为系统不可能允许我停机修改数据库参数,调整并发查询的参数,因此,只能修改该索引的degree了,将该索引的degree修改为1以后,业务立刻正常.
其实我们也经常听人说,并发开高了不好,会有问题,到底有什么问题,估计也没有多少人真的碰到过.另外,在创建索引的时候,我们都喜欢并发创建,可是创建完成以后,喜欢忘记关闭并行.结果列,给后来人造成麻烦,不是吗?
作DBA,关键是要小心,小心再小心,其实这个问题出现,就是因为在系统作一个大的割接的时候,为了加快重建索引的速度,使用了非常大的并发,结果忘记关闭并行,就在业务繁忙的时候,导致问题出现.
DBA,小心一切操作,充分评估你的操作给后续系统带来的隐患.
最后非常感谢处理这个问题的时候,BITI_RAINY给予的帮助:)
from:http://www.oracledba.com.cn/blog/?p=327