AWR报告是Oracle唯一能回溯、可对比、带上下文的PL/SQL性能诊断依据；确认PL/SQL已入采集范围需满足：其内含可捕获的DML/SELECT（如SELECT 1 FROM dual），且对应sql_id存在于dba_hist_sqlstat中，或触发作业时段与AWR快照时间重叠。
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飙升，才说明问题不在代码逻辑，而在底层数据分布或缓存配置。
