巡检时，执行如下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 );
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'
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
Output:
可以看出是CES_FACT_INM表
select owner,object_name,object_id,object_type from dba_objects where data_object_id=51983
Output
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('08wx0uf3t1gt2'))
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"));
再次查看执行计划，发现对CES_FACT_INM表的访问走了新建的函数索引，而且cost显著下降
执行很快出结果，用时不到1秒
buffer_gets也显著下降至136
SELECT sql_fulltext,disk_reads,buffer_gets FROM V$SQLAREA WHERE SQL_ID='08wx0uf3t1gt2'
Output:
