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执行本身是分离的。
实操建议：
- 打开AWR报告后，直接搜索
Time Model Statistics，定位到“Parse Time Elapsed”行，注意看它的绝对值（秒）和占DB Time的百分比； - 若该值>1%，且远高于历史基线（比如平时0.2%突然跳到1.5%），就要警惕；
- 别只盯单次解析耗时——
Hard Parses每秒次数（在Load Profile节）更关键：超过100次/秒基本说明绑定变量缺失或cursor_sharing配置不当； - 对比
Soft Parses和Hard Parses比例：硬解析占比>5%通常已属异常。
v$sql里查不到Parse Time？用v$sqlarea或dba_hist_sqlstat
v$sql视图不记录解析时间，它只存执行统计（如elapsed_time、cpu_time）。想查某条SQL的解析开销，必须换视图。
实操建议：
- 查当前活跃SQL的硬解析次数：
SELECT sql_id, parsing_schema_name, loads, executions FROM v$sql WHERE loads > 0 ORDER BY loads DESC FETCH FIRST 10 ROWS ONLY； - 查历史解析行为（需诊断过去几小时）：
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； -
loads字段在v$sql中代表硬解析次数，不是“加载次数”——这是常见误解； -
dba_hist_sqlstat里没有parse_time列，但hard_parses和soft_parses足够定位问题SQL。
硬解析飙升时，先查shared pool和绑定变量
硬解析高 ≠ 一定是SQL写得差。更可能是共享池配置或应用层调用方式出了问题。
实操建议：
- 确认
shared_pool_size是否过小：查SELECT component, current_size/1024/1024 mb FROM v$memory_dynamic_components WHERE component = 'shared pool'，若current_size频繁波动或接近min_size，说明内存不足导致执行计划被挤出； - 检查应用是否用了字面量而非绑定变量：
SELECT sql_text FROM v$sql WHERE sql_text LIKE '%WHERE id = 123%' AND sql_text NOT LIKE '%WHERE id = :b1%'； - 临时启用
cursor_sharing = force可缓解（但慎用——可能引入非最优执行计划）； - 避免在PL/SQL块里拼接SQL字符串，尤其带
EXECUTE IMMEDIATE的动态语句，这是硬解析大户。
DBA_HIST_SQLTEXT截断怎么办？优先用v$sql取完整SQL
AWR报告只显示SQL前1000字符，dba_hist_sqltext也常因存储策略丢失最新SQL或被截断。解析问题往往卡在WHERE条件末尾或子查询里，前1000字看不出端倪。
实操建议：
- 先查
v$sql：SELECT sql_fulltext FROM v$sql WHERE sql_id = 'abc123xyz'——这是最可能拿到完整文本的地方； - 若
v$sql里找不到，再试dba_hist_sqltext，但要加AND piece = 1确保取首段，并用ORDER BY piece拼接多段； - 注意
v$sql只保留最近缓存的SQL，如果SQL刚执行完就被老化淘汰，就得靠ASH回溯：SELECT sql_text FROM v$active_session_history WHERE sql_id = 'abc123xyz' AND rownum = 1； - 不要依赖AWR报告里那个被截断的SQL片段做判断——它连IN列表都可能没显示全。
解析耗时容易被当成次要指标忽略，但它往往是性能拐点的前兆：硬解析一多，CPU毛刺、library cache lock争用、shared pool latch争抢就会接踵而至。真正要盯的不是“花了多少秒解析”，而是“为什么每次都要重新解析”。
