处理Oracle EBS R12标准功能切换职责速度慢的问题
最近用户(用EBS系统的时候)普遍反馈一个问题: 这个问题如何处理? 其实是这样子的,如果以前使用系统的时候正常,现在突然变慢,在服务器的性能没大幅度下降的前提下,应该是某个SQL的执行计划出现问题了。 怎么找出是哪条SQL慢呢?正常情况下,一般跟踪会话的执行情况即可。例如开个10046事件跟踪会话的执行SQL情况等等。 1 首先,打开系统,在职责的界面,直接查看帮助–>关于Oracle Application,找出该职责对应的会话ID(SID),然后执行下面的SQL。 SELECT A.INST_ID,A.SID,A.PROCESS,A.ACTION,A.STATUS,A.SQL_ID,A.SQL_CHILD_NUMBER
FROM GV$SESSION A
WHERE A.SID=4208
AND A.INST_ID=1;
2 接着,回到EBS界面,做切换职责的动作,然后瞬速切回到开发工具查询上面的SQL!确认STATUS=ACTIVE的时候,哪条SQL是停留时间最长的。 SELECT SQL_TEXT,INST_ID,SQL_ID,CHILD_NUMBER,ROUND(ELAPSED_TIME / 1000000 / DECODE(EXECUTIONS,0,1,EXECUTIONS),5) PER_ELAPSED_TIME--单条SQL的平均执行时间(秒) FROM GV$SQL WHERE SQL_ID='0y7y17bcappxk' AND CHILD_NUMBER=0 AND INST_ID=1;
我这边切换职责,卡的SQL是: SELECT P.PID,P.SERIAL#,P.SPID FROM V$PROCESS P,V$SESSION S WHERE S.AUDSID = USERENV('SESSIONID') AND S.PADDR = P.ADDR
3 找到是哪条SQL慢,问题就可以分析了:为什么慢。 SQL_ID 0y7y17bcappxk,child number 0 -------------------------------------
SELECT P.PID,P.SPID FROM V$PROCESS P,V$SESSION S WHERE
S.AUDSID = USERENV('SESSIONID') AND S.PADDR = P.ADDR
Plan hash value: 1245246913
------------------------------------------------------------------------------------ | Id | Operation | Name | E-Rows |E-Bytes| Cost (%CPU)| ------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1 (100)|
| 1 | NESTED LOOPS | | 1 | 60 | 0 (0)|
| 2 | MERGE JOIN CARTESIAN | | 149 | 5960 | 0 (0)|
| 3 | NESTED LOOPS | | 9 | 108 | 0 (0)|
| 4 | FIXED TABLE FULL | X$KSLWT | 100 | 800 | 0 (0)|
|* 5 | FIXED TABLE FIXED INDEX| X$KSLED (ind:2) | 1 | 4 | 0 (0)|
| 6 | BUFFER SORT | | 17 | 476 | 0 (0)|
|* 7 | FIXED TABLE FULL | X$KSUPR | 17 | 476 | 0 (0)|
|* 8 | FIXED TABLE FIXED INDEX | X$KSUSE (ind:1) | 1 | 20 | 0 (0)| ------------------------------------------------------------------------------------
执行计划正常的应该是: SQL_ID 0y7y17bcappxk,V$SESSION S WHERE
S.AUDSID = USERENV('SESSIONID') AND S.PADDR = P.ADDR
Plan hash value: 2285488774
----------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time | -----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | NESTED LOOPS | | 2 | 120 | 3 (100)| 00:00:01 |
|* 2 | HASH JOIN | | 2 | 112 | 3 (100)| 00:00:01 |
| 3 | NESTED LOOPS | | 2 | 56 | 1 (100)| 00:00:01 |
| 4 | FIXED TABLE FULL | X$KSLWT | 1154 | 9232 | 0 (0)| |
|* 5 | FIXED TABLE FIXED INDEX| X$KSUSE (ind:1) | 1 | 20 | 0 (0)| |
|* 6 | FIXED TABLE FULL | X$KSUPR | 686 | 19208 | 2 (100)| 00:00:01 |
|* 7 | FIXED TABLE FIXED INDEX | X$KSLED (ind:2) | 1 | 4 | 0 (0)| | -----------------------------------------------------------------------------------------------
由于执行计划在Toad里面直接执行,也是没问题的。 解决办法: select s.SQL_TEXT,'exec sys.dbms_shared_pool.purge('''||s.ADDRESS||','||s.HASH_VALUE||''',''c'');'
from v$sqlarea s
where sql_id = '0y7y17bcappxk';
exec sys.dbms_shared_pool.purge('0700000673865A50,3635074994','c');
将这个执行计划Purge掉之后,Oracle再重新执行SQL的时候,会重新找执行计划。 这边重新找的执行计划是正常的,所以,切换职责的速度也就正常了!实测基本是2秒左右就可以切换好职责。 问题得以解决! (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |