如何利用AWR报告监控Oracle数据库性能，识别PLSQL瓶颈点？

本文共计718个文字，预计阅读时间需要3分钟。

相关专题

awr报告不是“可选监控手段”，而是oracle数据库中唯一能回溯、可对比、带上下文的pl/sql性能诊断依据——它不依赖实时会话状态，也不受sql*plus断连影响，只要快照存在，就能还原出某段pl/sql执行期间的真实资源消耗。

怎么确认PL/SQL调用已进入AWR采集范围

PL/SQL本身不会单独出现在SQL Statistics里，除非它显式执行了SQL语句。纯逻辑计算（如循环、字符串拼接）不产生等待、不读块、不写日志，AWR根本看不到。

• 必须启用PL/SQL native compilation或确保PL/SQL中包含至少一条可被v$sql捕获的DML/SELECT（哪怕只是SELECT 1 INTO v_x FROM dual）
• 检查dba_hist_sqlstat中是否存在对应sql_id：若PL/SQL过程内嵌SQL未使用绑定变量，每次调用都会生成新sql_id，导致AWR中分散为多条记录
• 若PL/SQL通过DBMS_SCHEDULER或DBMS_JOB触发，需确认作业运行时段与AWR快照时间重叠；否则报告里查不到任何痕迹

在AWR里定位PL/SQL相关SQL的3个关键入口

不要直接搜“PL/SQL”，要找它驱动的SQL。真正拖慢系统的，永远是那几条被反复调用的低效SQL，而不是存储过程外壳。

• SQL ordered by Elapsed Time：优先看Elapsed Time per Exec > 500ms 且 Executions > 100 的语句——这类SQL大概率来自高频PL/SQL过程（如定时清洗、接口入仓）
• SQL ordered by Gets：若某SQL的Buffer Gets per Exec > 200,000，但返回行数Rows Processed per Exec
• Top 5 Timed Events中若出现latch: shared pool或library cache lock，往往对应PL/SQL频繁编译或动态SQL硬解析——检查是否在循环里拼接并EXECUTE IMMEDIATE未参数化的SQL

为什么DBMS_PROFILER和DBMS_HPROF不能替代AWR分析PL/SQL

它们只告诉你“哪一行代码慢”，但无法回答“为什么慢”——缺少系统级上下文。

• DBMS_PROFILER不记录等待事件，看不出是I/O卡住还是锁阻塞；而AWR里log file sync高+该SQL执行频次突增，就能锁定是PL/SQL里COMMIT太勤
• DBMS_HPROF堆栈深度有限，对递归调用或自治事务容易截断；AWR则通过sql_id关联到完整执行计划，能看出是否因统计信息陈旧导致索引未走
• 两者都要求提前开启，无法用于事后追查；而AWR只要快照存在，随时可翻出上周三下午3点那个跑崩的存储过程调用了哪些SQL

真正难的不是找到PL/SQL调用的SQL，而是确认这些SQL是否在正确的时间、以正确的执行计划、在合适的并发量下运行——AWR的Instance Efficiency Percentages里Buffer Hit Ratio掉到85%以下，配合db file sequential read飙升，才说明问题不在代码逻辑，而在底层数据分布或缓存配置。