Oracle数据库如何通过AWR分析SQL解析耗时

Parse Time Elapsed需在AWR报告的Time Model Statistics节中查找，其值超1%或硬解析超100次/秒、硬解析占比超5%即异常；v$sql不存解析时间，应查v$sqlarea或dba_hist_sqlstat；硬解析飙升主因常为shared pool不足或绑定变量缺失。

Parse Time Elapsed在Time Model Statistics里怎么看

Parse Time Elapsed不是独立指标，它藏在AWR报告的Time Model Statistics节里，不是Top SQL或等待事件列表里的显眼项。很多人翻遍“SQL ordered by Elapsed Time”却漏掉它，因为解析耗时根本不会出现在那里——它属于数据库启动、硬解析、执行计划生成阶段的开销，和SQL执行本身是分离的。

实操建议：

1. 打开AWR报告后，直接搜索Time Model Statistics，定位到“Parse Time Elapsed”行，注意看它的绝对值（秒）和占DB Time的百分比；
2. 若该值>1%，且远高于历史基线（比如平时0.2%突然跳到1.5%），就要警惕；
3. 别只盯单次解析耗时——Hard Parses每秒次数（在Load Profile节）更关键：超过100次/秒基本说明绑定变量缺失或cursor_sharing配置不当；
4. 对比Soft Parses和Hard Parses比例：硬解析占比>5%通常已属异常。

v$sql里查不到Parse Time？用v$sqlarea或dba_hist_sqlstat

v$sql视图不记录解析时间，它只存执行统计（如elapsed_time、cpu_time）。想查某条SQL的解析开销，必须换视图。

实操建议：

1. 查当前活跃SQL的硬解析次数：SELECT sql_id, parsing_schema_name, loads, executions FROM v$sql WHERE loads > 0 ORDER BY loads DESC FETCH FIRST 10 ROWS ONLY；
2. 查历史解析行为（需诊断过去几小时）：SELECT sql_id, sum(hard_parses) hard_parses_total, sum(soft_parses) soft_parses_total FROM dba_hist_sqlstat WHERE snap_id BETWEEN 12345 AND 12346 GROUP BY sql_id HAVING sum(hard_parses) > 10 ORDER BY hard_parses_total DESC；
3. loads字段在v$sql中代表硬解析次数，不是“加载次数”——这是常见误解；
4. dba_hist_sqlstat里没有parse_time列，但hard_parses和soft_parses足够定位问题SQL。

硬解析飙升时，先查shared pool和绑定变量

硬解析高 ≠ 一定是SQL写得差。更可能是共享池配置或应用层调用方式出了问题。

实操建议：

1. 确认shared_pool_size是否过小：查SELECT component, current_size/1024/1024 mb FROM v$memory_dynamic_components WHERE component = 'shared pool'，若current_size频繁波动或接近min_size，说明内存不足导致执行计划被挤出；
2. 检查应用是否用了字面量而非绑定变量：SELECT sql_text FROM v$sql WHERE sql_text LIKE '%WHERE id = 123%' AND sql_text NOT LIKE '%WHERE id = :b1%'；
3. 临时启用cursor_sharing = force可缓解（但慎用——可能引入非最优执行计划）；
4. 避免在PL/SQL块里拼接SQL字符串，尤其带EXECUTE IMMEDIATE的动态语句，这是硬解析大户。

DBA_HIST_SQLTEXT截断怎么办？优先用v$sql取完整SQL

AWR报告只显示SQL前1000字符，dba_hist_sqltext也常因存储策略丢失最新SQL或被截断。解析问题往往卡在WHERE条件末尾或子查询里，前1000字看不出端倪。

实操建议：

1. 先查v$sql：SELECT sql_fulltext FROM v$sql WHERE sql_id = 'abc123xyz'——这是最可能拿到完整文本的地方；
2. 若v$sql里找不到，再试dba_hist_sqltext，但要加AND piece = 1确保取首段，并用ORDER BY piece拼接多段；
3. 注意v$sql只保留最近缓存的SQL，如果SQL刚执行完就被老化淘汰，就得靠ASH回溯：SELECT sql_text FROM v$active_session_history WHERE sql_id = 'abc123xyz' AND rownum = 1；
4. 不要依赖AWR报告里那个被截断的SQL片段做判断——它连IN列表都可能没显示全。

解析耗时容易被当成次要指标忽略，但它往往是性能拐点的前兆：硬解析一多，CPU毛刺、library cache lock争用、shared pool latch争抢就会接踵而至。真正要盯的不是“花了多少秒解析”，而是“为什么每次都要重新解析”。