awr报告不直接暴露高级队列（aq）内部排队行为，需通过top 5 timed events中pl/sql lock timer、db file sequential read及enq: jq/sq contention等等待事件，结合sql statistics中dbms_aq相关语句、instance efficiency percentages异常（如parse cpu %低、buffer nowait %
awr报告本身不直接暴露高级队列（aq）的内部排队行为，但能清晰反映aq引发的典型负载特征——你得从等待事件、sql统计和资源消耗三处交叉验证，否则容易把“队列积压”误判为“sql慢”或“io高”。
看 Top 5 Timed Events 是否出现 AQ 相关等待
AQ 操作在底层会触发特定等待，最常见的是 enq: TX - row lock contention（事务锁争用）和 enq: SQ - contention（序列化队列锁）。但更关键的是：PL/SQL lock timer 和 db file sequential read 若在 Top 5 中持续靠前，且伴随高逻辑读，大概率是 AQ 的 dequeue 过程在轮询或执行回调 PL/SQL 时卡住。
- 若
enq: JQ - contention出现（仅限 Oracle 12c+），说明 Job Queue 进程与 AQ 消费者存在资源竞争，需检查job_queue_processes设置是否过低 -
buffer busy waits高 +gc buffer busy同时上升，可能是多个消费者并发 dequeue 同一张 AQ 表，导致索引块争用 - 注意：AQ 自身不产生
aq: qmn coordinator idle wait类等待——那是 QMN 进程空闲态，不计入 DB Time，别把它当瓶颈
查 SQL Statistics 里带 DBMS_AQ / DBMS_AQIN 的语句
AQ 的入队（DBMS_AQ.ENQUEUE）、出队（DBMS_AQ.DEQUEUE）、监听（DBMS_AQ.LISTEN）操作最终都会编译成可识别的 SQL。在 AWR 的 “SQL ordered by Gets” 或 “SQL ordered by Executions” 列表中，搜索含 DBMS_AQ 或 aq$_ 前缀的 SQL ID。
- 重点关注
EXECUTIONS高但ELAPSED_TIME_PER_EXEC波动大的语句——说明 dequeue 调用频率稳定，但每次处理耗时不均，常因消息体大、回调逻辑复杂或网络延迟引起 - 若某条
UPDATE aq$_xxx_tables语句逻辑读（GETS）极高，大概率是未设置navigation => DBMS_AQ.NEXT_MESSAGE导致全表扫描式遍历队列表 - 避免依赖 “SQL ordered by CPU Time”：AQ 的 CPU 消耗往往分散在 PL/SQL 解析和执行阶段，主 SQL 可能只占 10%~20%
核对 Instance Efficiency Percentages 和 Load Profile
AQ 负载有隐性放大效应，单看 SQL 可能不显眼，但整体效率指标会异常：
-
Parse CPU to Parse Elapsed %低于 70%：说明硬解析占比高，而 AQ 场景下常见原因是不同消费者使用不同dequeue_options（如wait => 0vswait => 30），导致无法重用游标 -
Buffer Nowait %低于 99.5%：结合高db block gets，指向 AQ 表的热块争用，特别是aq$_xxx_i索引块 -
Redo size每秒突增但Transactions无明显变化：典型 AQ 入队场景——每条消息都触发独立事务提交，即使业务上是“批量发送”，底层仍是 N 次小事务
别漏掉 AWR 中隐藏的 AQ 配置线索
AWR 报告末尾的 “Initialization Parameters” 部分虽不起眼，但几个参数直接影响 AQ 行为：
-
aq_tm_processes：若值为 0，QMN 进程被禁用，所有 dequeue 必须走应用层轮询，DB Time 会大量堆在应用连接上，而非数据库内 -
job_queue_processes：低于 2 时，AQ 的定时调度（如延迟消息、失败重试）会严重滞后，表现为DB time持续高于elapsed，但 Top Event 里找不到明显等待 -
shared_pool_size或sga_target过小：AQ 相关的 PL/SQL 包（DBMS_AQ,DBMS_AQADM）加载后易老化，引发频繁 reload，体现为library cache lock等待上升
真正难定位的 AQ 负载，往往藏在 “DB Time 远大于 elapsed 时间 × CPU 核数” 却又没有显著 Top Wait 的矛盾里——这时要立刻查 v$active_session_history 中 session_state = 'WAITING' 且 event 为空的样本，它们大概率正卡在 AQ 的 PL/SQL 回调里做同步 I/O 或外部服务调用。
