如何通过Navicat特定视图查询，分析Oracle AWR报告的执行计划以定位性能瓶颈？

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

相关专题

navicat 本身不支持直接生成或查看 awr 报告，也不能用它查出 awr 报告里的执行计划 —— 因为 awr 报告是汇总性性能快照，不是单条 sql 的执行计划。 它和 explain plan、dbms_xplan 是两类东西：前者看系统级资源趋势（如 cpu 使用率、硬解析比例），后者看某条语句怎么走索引、是否走全表扫描。混用会找不到关键瓶颈点。

为什么在 Navicat 里执行 @?/rdbms/admin/awrrpt 会报错 ORA-06550 或找不到脚本

Oracle 官方的 awrrpt.sql 脚本只存在于数据库服务端安装目录（如 /u01/app/oracle/product/19c/dbhome_1/rdbms/admin/），不随客户端分发。Navicat 连接的是远程实例，没有本地文件系统访问权限，所以执行 @?/rdbms/admin/awrrpt 时：

• Navicat 尝试把 @? 解析成它自己能访问的路径，但实际找不到该文件
• 即使你手动把脚本拷贝到本地并指定绝对路径（如 @/tmp/awrrpt.sql），脚本内部又依赖 DBMS_WORKLOAD_REPOSITORY 包和 PLAN_TABLE 等对象，而 Navicat 默认不自动创建这些前提条件
• 常见报错包括：SP2-0310: unable to open file "awrrpt.sql"、ORA-00942: table or view does not exist（缺 PLAN_TABLE）

想在 Navicat 中查 AWR 相关数据，只能走 SQL 查询视图

Navicat 支持运行标准 SQL，所以你可以绕过脚本，直接查 AWR 底层历史视图。但注意：必须用有 SELECT_CATALOG_ROLE 或 DBA 权限的用户登录，否则会提示 ORA-00942。

• 查快照时间范围：SELECT snap_id, instance_number, to_char(end_interval_time, 'YYYY-MM-DD HH24:MI') FROM dba_hist_snapshot WHERE end_interval_time >= SYSDATE - 1 ORDER BY snap_id DESC
• 查某段时间最耗资源的 SQL（按逻辑读）：SELECT sql_id, sql_text, buffer_gets FROM dba_hist_sqlstat s JOIN dba_hist_sqltext t USING (sql_id) WHERE s.snap_id BETWEEN 841 AND 842 ORDER BY buffer_gets DESC FETCH FIRST 5 ROWS ONLY
• 查某条 SQL 在 AWR 中的历史执行计划（需已存在）：SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('your_sql_id', NULL, NULL, 'ADVANCED'))

其中 DISPLAY_AWR 是关键：它从 AWR 快照中提取已捕获过的执行计划，不是实时解释，所以前提是这条 SQL 真正在对应快照区间内被执行过且被采样到。

真正定位 SQL 性能瓶颈，应该分两层查

AWR 视图帮你圈出“哪几条 SQL 很慢”，但看不出“为什么慢”。这时要切回单条 SQL 的执行计划：

• 在 Navicat 中新建查询，粘贴目标 SQL（确保语法完整、无未绑定变量）
• 点击右下角的 解释 按钮（不是“运行”）→ Navicat 自动执行 EXPLAIN PLAN FOR ... + SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY)
• 重点看 OPERATION 列是否出现 FULL（全表扫描）、ACCESS PREDICATES 是否用了索引字段、ESTIMATED COST 是否异常高
• 如果发现 filter 谓词远多于 access，说明索引没被有效利用，可能需要调整 WHERE 条件顺序或加函数索引

容易忽略的一点：AWR 里记录的 SQL_ID 和你在 Navicat 中手工写的 SQL 可能因空格、大小写、绑定变量写法不同而不匹配 —— 查不到计划时，先用 V$SQL 确认当前缓存中的确切 SQL_ID，再查 AWR。