SQL Monitor用于实时监控高开销SQL执行过程，AWR则按快照周期汇总全库历史负载；前者盯“正在发生的手术”，后者看“过去24小时的体检报告”，二者互补而非替代。
sql monitor 用于实时抓取单条高开销 sql 的执行过程，awr 则是按快照周期汇总全库负载的“历史切片”。两者不是替代关系，而是互补：一个盯“正在发生的手术”，一个看“过去24小时的体检报告”。
SQL Monitor 什么时候必须用
当你遇到一条 SQL 执行卡住、响应极慢、或开发反馈“这条语句突然变慢了”，但又没等到它跑完就超时中断——这时候 V$SQL_MONITOR 就是第一响应工具。
- 它默认监控并行执行的语句，或单次执行消耗 ≥5 秒 CPU/I/O 的语句（可通过
_sql_monitor_threshold隐含参数调整） - 每秒刷新一次，字段如
ELAPSED_TIME、CPU_TIME、IO_INTERCONNECT_BYTES都是真实累计值，不是估算 - 配合
V$SQL_PLAN_MONITOR能看到每一步实际返回行数（OUTPUT_ROWS）和耗时（LAST_ELAPSED_TIME），直接暴露执行计划偏差点 - 注意：它只保留最近执行完成的语句，默认最多存 300 条，且不跨实例（RAC 中需在对应节点查）
AWR 报告更适合哪些场景
你要回答的是“过去一小时内数据库为什么整体变慢”，而不是“某条 SQL 怎么了”，那就该翻 AWR 报告。
- 它基于两个
DBA_HIST_SNAPSHOT快照生成，时间粒度默认 60 分钟，可手动调到 15 分钟甚至更密（但会增大SYSMAN表空间压力） -
Top 5 Timed Events章节告诉你等待瓶颈在哪（比如大量db file sequential read或log file sync） -
SQL Statistics按逻辑读、执行次数、CPU 时间等维度排序，帮你发现“安静但吃资源”的慢 SQL（它们往往不会触发 SQL Monitor） - 19c 中 AWR 已内置 ASH 数据聚合结果，所以你能在报告里直接看到“Top SQL by Active Session Time”，不用再单独跑 ASH 报告
常见误用：把 SQL Monitor 当 AWR 用，或反过来
这两个工具的数据来源、生命周期、聚合方式完全不同，混用会导致诊断断层。
- 错误做法：只查
V$SQL_MONITOR发现某条 SQL 慢，就认定是它拖垮了系统 —— 但 AWR 显示这 SQL 执行次数极少，真正问题是library cache lock等待事件占了 DB Time 的 70% - 错误做法：用 AWR 报告去分析一条刚执行失败的 SQL —— 如果它没跑满 5 秒、也没并行，就不会进
V$SQL_MONITOR，AWR 里也找不到它的详细执行计划和实际 I/O 统计 - 关键区别：SQL Monitor 是内存中动态视图，重启实例即清空；AWR 数据写入磁盘表（
DBA_HIST_*），受DBA_HIST_WR_CONTROL控制保留天数（默认 8 天） - 交叉验证技巧：在 AWR 报告里找到 Top SQL 的
SQL_ID，再用它去查V$SQL_MONITOR是否有近期执行记录，能判断该 SQL 是偶发抖动还是持续恶化
最常被忽略的一点：SQL Monitor 的数据在 PDB 级别是隔离的，而 AWR 报告可以按 PDB 单独生成（用 awrrpt.sql 进入后选 “PDB” 选项）。多租户环境下，不切对容器直接查 CDB$ROOT 的 V$SQL_MONITOR，可能根本看不到问题 PDB 里的活跃 SQL。
