查v$system_event发现平均等待时间异常升高是数据库响应恶化主因，需结合ASH定位高等待SQL，并用AWR确认趋势，同时排查应用层并发与事务行为。
查 v$system_event 看平均等待时间是否异常升高
Oracle 平均响应时间恶化，本质是会话在关键等待事件上花的时间变长了，不是单条 SQL 慢，而是整个数据库“卡在某类资源上”。v$system_event 是最直接的入口——它统计所有会话在各类等待事件上的总耗时、次数和平均值。
- 重点关注字段：
event（如db file sequential read、log file sync、direct path read）、time_waited（微秒）、total_waits、average_wait（单位：百分之一秒，即 10ms 级别） - 执行语句：
SELECT event, total_waits, time_waited, ROUND(time_waited/NULLIF(total_waits,0),2) AS average_wait FROM v$system_event WHERE total_waits > 0 ORDER BY time_waited DESC; - 判断依据：如果
average_wait比日常基线高出 2–3 倍（例如log file sync从 5ms 升到 20ms+），说明对应资源（如日志写入、磁盘读）已成瓶颈，需进一步定位触发该等待的 SQL - 注意：
v$system_event是实例级聚合视图，不带 SQL_ID，只告诉你“哪类操作变慢”，不能直接看到具体语句
用 v$active_session_history 关联等待事件与 SQL
有了异常等待事件，下一步是找出哪些 SQL 正在大量触发它。这时不能只看 v$sql 的历史统计，而要查 v$active_session_history（ASH）——它是每秒采样一次的“快照录像带”，能还原真实运行时上下文。
- 典型查询：
SELECT sql_id, sql_plan_hash_value, event, COUNT(*) AS sample_count FROM v$active_session_history WHERE event IN ('db file sequential read', 'log file sync') AND sample_time > SYSDATE - 1/24 GROUP BY sql_id, sql_plan_hash_value, event ORDER BY sample_count DESC; - 关键点：
event字段必须精确匹配（大小写敏感，含空格），比如'db file sequential read'不可写成'db file sequential read '（末尾空格） - 为什么不用
v$sql？因为v$sql的disk_reads或elapsed_time是累计值，无法反映“此刻正在拖慢响应时间”的活跃 SQL；ASH 才能抓到正在等磁盘、等日志的“现行犯” - 结果中
sample_count高的sql_id就是嫌疑最大者，再用SELECT sql_text FROM v$sql WHERE sql_id = 'xxx';查出具体语句
对比 AWR 报告确认趋势性恶化
单次查询可能受瞬时干扰，要确认“平均响应时间恶化”是持续问题，得看 AWR 快照间的对比。AWR 是唯一能跨时段量化变化的权威来源。
- 执行
awrrpt.sql或使用 OEM 生成 AWR 报告，重点看 “Top 5 Timed Events” 和 “SQL Statistics → SQL ordered by Elapsed Time” 两部分 - 对比两个时间段（例如昨天 14:00–15:00 vs 今天同一时段）：
average_wait是否持续上升？time_waited占总 DB 时间比例是否明显增加？ - 特别注意：如果报告里
DB CPU占比下降，但log file sync或db file sequential read占比飙升，说明性能恶化主因是 IO 或日志写入，而非 CPU 瓶颈 - AWR 数据默认保留 8 天，若需更久历史，需提前配置保留策略；没有企业版许可则无法使用 AWR
别忽略应用层并发与事务行为
很多“平均响应时间恶化”表面是数据库问题，根子在应用。SQL 本身没问题，但调用方式放大了等待效应。
- 常见诱因：
COMMIT频率过高（导致log file sync等待堆积）、长事务未及时提交（阻塞其他会话）、连接池设置过小（大量会话排队等连接） - 验证方法：查
v$session中status = 'ACTIVE'且event = 'log file sync'的会话，看它们的program和machine是否集中来自某台应用服务器 - 一个容易被跳过的细节：同一条 SQL 在不同并发下表现差异极大。例如单次执行 200ms 的查询，在 50 并发下可能因 buffer busy waits 或 enq: TX row lock contention 导致平均响应时间升至 2s+——此时优化单条 SQL 没用，得调并发或拆事务
