Oracle:poor sql导致的latch: cache buffers chains案例

巡检时，执行如下sql发现长会话：

SELECT SE.SID,SE.SERIAL#,TO_CHAR(LOGON_TIME,'YYYY-MM-DD HH24:MI:SS'),SE.STATUS,SE.OSUSER,SE.MACHINE,SE.PROGRAM,SE.BLOCKING_SESSION, 
SE.SQL_ID,SE.PREV_SQL_ID ,SE.EVENT,SE.P1TEXT,SE.P1,SE.P2TEXT,SE.P2,SE.P3TEXT,SE.P3,SE.SECONDS_IN_WAIT 
FROM SYS.V_$SESSION  SE , SYS.v_$session_wait SW 
        WHERE SE.SID=SW.SID  AND SE.STATUS='ACTIVE'   AND SE.USERNAME NOT IN ('SYS','SYSMAN','DBSNMP') 
        AND (SE.LAST_CALL_ET/86400) > 1 
        AND ( TO_CHAR(SYSDATE,'YYYYMMDD') <> TO_CHAR(SE.LOGON_TIME,'YYYYMMDD') OR SYSDATE-LOGON_TIME >= 24/24 );
1
2
3
4
5
6

Output:

从输出来看，肇事sql_id是08wx0uf3t1gt2，event是latch: cache buffers chains
这个事件主要原因：
1.热点数据的争用
2.低效率的sql

从如下查询的输出来看，这个sql有大量的逻辑读，判断应该是低效率的sql所致

SELECT sql_fulltext,disk_reads,buffer_gets FROM V$SQLAREA WHERE SQL_ID='08wx0uf3t1gt2'

1
2

Output:

也可查询发生热点块竞争的对象

select ts#,file#,dbarfil,dbablk,obj ,tch from sys.x$bh where  hladdr in (SELECT p1raw FROM V$SESSION WHERE event='latch: cache buffers chains')
order by tch desc
1
2

Output:

可以看出是CES_FACT_INM表

select owner,object_name,object_id,object_type from dba_objects where data_object_id=51983

1
2

Output

 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('08wx0uf3t1gt2'))
1

Ouput:


从上面的输出来看，尽管对CES_FACT_INM表的访问走了索引，但从底下的谓词来看，我们还可以针对filter部分建立一个function index:

 create index IDX_FUNC_CES_FACT_INM on
    CESUSER.CES_FACT_INM(DECODE(SYS_OP_C2C("DECR_TYPE"),'EX',"SUP_AJU_NO",'27',
    "SUP_AJU_NO","AJU_NO"));
1
2
3

再次查看执行计划，发现对CES_FACT_INM表的访问走了新建的函数索引，而且cost显著下降

执行很快出结果，用时不到1秒

buffer_gets也显著下降至136

 SELECT sql_fulltext,disk_reads,buffer_gets FROM V$SQLAREA WHERE SQL_ID='08wx0uf3t1gt2'
1

Output: