同样业务的系统,有一个系统十分不正常,速度不如另外一个系统的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”) from table_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以后,业务立刻正常.