Oracle大师Roger Cornejo的推荐：使用ASH诊断Oracle解析故障

这篇文章被Oracle大师Roger Cornejo在X平台上推荐（见下图），英文原文在：

Diagnosing Parsing Issue with ASH

在这里插入图片描述

解析，尤其是硬解析，是非生产性操作，会消耗大量系统资源，导致库缓存争用。ASH（Active Session History）可以通过其采样机制来诊断和分析过度的解析。本文探讨了如何有效地使用ASH来识别解析问题。

模拟解析问题

首先，我们使用以下PL/SQL匿名块来模拟解析问题：

SQL> set timing on
SQL> create table yuan_obj as select * from dba_objects;Table created.Elapsed: 00:00:00.746
SQL>
SQL> declare2    i number;3    sql_text varchar2(256);4  begin5    for i in 1..100000 loop6       sql_text := 'select object_name from yuan_obj where object_id = '||i;7       execute immediate sql_text;8    end loop;9  end;10  /PL/SQL procedure successfully completed.Elapsed: 00:05:44.904

此场景是由于缺乏绑定变量而导致的低效SQL执行的经典示例。

检测解析问题

v$active_session_history和DBA_HIST_ACTIVE_SESS_HISTORY视图中的in_parse和in_hard_parse列可用于检测解析问题：

in_parse：此列指示会话当前是否正在执行解析操作。
in_hard_parse：此列指示会话是否正在执行硬解析。

以下SQL查询在过去10分钟内分组并统计解析活动的发生次数：

col in_parse form a10
col in_hard_parse form a10
select in_parse,in_hard_parse,count(*) as cnt,100 * trunc(ratio_to_report(count(*)) over (), 4) as "PERCENT"from v$active_session_historywhere sample_time > current_timestamp - interval '10' minutegroup by in_parse, in_hard_parseorder by count(*) desc;

当运行低效的PL/SQL块时，我们得到如下输出：

IN_PARSE   IN_HARD_PARSE     CNT   PERCENT
Y          Y                 229     91.23
Y          N                  17      6.77
N          N                   5      1.99

此输出表明解析，尤其是硬解析，占据了大多数数据库活动，只有1.99%的数据库资源真正用于查询执行。

让我们通过分析数据库正在经历的等待事件来深入了解：

col event form a30
set linesize 200
SELECTNVL(event, 'ON CPU') AS event,COUNT(*) AS total_wait_time,TO_CHAR(100 * TRUNC(RATIO_TO_REPORT(COUNT(*)) OVER (), 6), 'FM990.9999') || '%' AS "%"
FROMv$active_session_history
WHEREsample_time > SYSDATE - 10 / 60 / 24
GROUP BYevent
ORDER BYtotal_wait_time DESC;

输出：

EVENT                          TOTAL_WAIT_TIME %
------------------------------ --------------- ----------
ON CPU                                     503 92.1245%
latch: shared pool                          38 6.9597%
library cache: mutex X                       4 0.7326%
latch: row cache objects                     1 0.1831%

此输出表明解析大量使用了CPU，并且溢出到相关的Oracle等待事件中。

识别有问题的SQL语句

要识别有问题的SQL语句，可以利用v$sqlstats中的force_matching_signature列。此列包含一个哈希值，用于标识在文本上相似但可能具有不同文字值的SQL语句。此哈希值用于基于相似但不完全相同的SQL语句进行光标共享。

以下查询将v$active_session_history与v$sqlstats连接，以检索与最频繁执行的SQL语句共享相同force_matching_signature的SQL语句。

SELECT a.sample_time,a.sql_id,NVL(a.event, 'CPU') AS event,a.in_parse,a.in_hard_parse,a.force_matching_signature,t.exact_matching_signature,t.sql_text
FROM v$active_session_history a
LEFT JOIN v$sqlstats t ON a.sql_id = t.sql_id
WHERE t.force_matching_signature = (SELECT force_matching_signatureFROM (SELECT s.force_matching_signature, COUNT(*) AS cntFROM v$sqlstats sGROUP BY s.force_matching_signatureORDER BY COUNT(*) DESC)WHERE ROWNUM = 1
);

另一种发现相似SQL语句的方法是比较编辑后的SQL文本：

SELECT a.sample_time,a.sql_id,NVL(a.event, 'CPU') AS event,a.in_parse,a.in_hard_parse,a.force_matching_signature,t.exact_matching_signature,t.sql_text
FROM v$active_session_history a
LEFT JOIN v$sqlstats t ON a.sql_id = t.sql_id
WHERE SUBSTR(t.sql_text, 1, 40)= (SELECT truncated_sql_textFROM (SELECT SUBSTR(s.sql_text, 1, 40) AS truncated_sql_text,  COUNT(*) AS cntFROM v$sqlstats sGROUP BY SUBSTR(s.sql_text, 1, 40)ORDER BY COUNT(*) DESC)WHERE ROWNUM = 1
);

虽然两个查询的目的是相同的，但使用force_matching_signature的查询通常更准确。在这种情况下，两个查询产生相同的输出，如下所示（为简洁起见进行了截断）：
在这里插入图片描述
输出显示了文本上相似的SQL语句（具有相同的FORCE_MATCHING_SIGNATURE，即4786214959369239152）可以具有不同的字面值，从而具有不同的EXACT_MATCHING_SIGNATURE和不同的SQL_ID。

解决方案建议

在识别出有问题的SQL语句后，我们应与应用程序供应商合作修改应用程序代码。目标是尽可能用绑定变量替换文字。这种修改允许Oracle重用执行计划，从而减少与解析相关的开销。

可以将之前低效的PL/SQL优化如下：

DECLAREi NUMBER;
BEGINFOR i IN 1..100000 LOOPEXECUTE IMMEDIATE 'select object_name from yuan_obj where object_id = :1' USING i;END LOOP;
END;
/

SQL> alter system flush shared_pool;System altered.SQL> set timing on
SQL> DECLARE2    i NUMBER;3  BEGIN4    FOR i IN 1..100000 LOOP5      EXECUTE IMMEDIATE 'select object_name from yuan_obj where object_id = :1' USING i;6    END LOOP;7  END;8  /PL/SQL procedure successfully completed.Elapsed: 00:00:03.298

优化后的块显著更快，将执行时间从近6分钟减少到仅3秒多。

待优化后的块运行结束后，从v$active_session_history和v$sqlstats视图中检索先前SQL执行的信息：

SELECT a.sample_time,a.sql_id,NVL(a.event, 'CPU') AS event,a.in_parse,a.in_hard_parse,a.force_matching_signature,t.exact_matching_signature,t.sql_text
FROM v$active_session_history a
LEFT JOIN v$sqlstats t ON a.sql_id = t.sql_id
WHERE SUBSTR(t.sql_text, 1, 40)= substr('select object_name from yuan_obj where object_id =',1,40);