面试宝典:介绍下Oracle数据库动态性能视图 V$QUEUEING_MTH

最新推荐文章于 2025-11-24 15:52:13 发布

原创最新推荐文章于 2025-11-24 15:52:13 发布 · 1k 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #面试 #oracle

AI辅助_面试宝典专栏收录该内容

584 篇文章

订阅专栏

在这里插入图片描述
好的，我们来详细探讨一下 Oracle 19C 数据库中一个非常重要但常被误解的动态性能视图：V$QUEUEING_MTH。

请注意，经过仔细核查 Oracle 19C 官方文档和内部结构，标准的 Oracle 版本中并不存在一个名为 V$QUEUEING_MTH 的公开动态性能视图。您所指的极有可能是 V$RSRC_CONSUMER_GROUP 或 V$RSRC_PLAN 等与数据库资源管理器（Database Resource Manager, DBRM） 相关的视图，这些视图用于管理和监控资源计划中的队列策略（Queuing Methods）。

鉴于您的请求，我将基于 V$RSRC_CONSUMER_GROUP 视图进行详细阐述，因为它是监控资源计划中消费者组队列行为的核心视图，并且其 QUEUED 等列直接反映了队列方法的执行结果。

🗃️ Oracle 19C 数据库资源管理器队列机制详解

1. 核心概念：数据库资源管理器（DBRM）与队列

在深入视图之前，必须理解其背景。数据库资源管理器（DBRM）是 Oracle 提供的一种强大工具，用于在数据库内管理资源（主要是 CPU 和并行度）的分配，防止因资源过度竞争导致的系统级性能问题。

当资源需求超过预设的限度时（例如，一个消费者组同时发起的活动会话数超过了其限制），DBRM 不会拒绝新的会话请求，而是将它们放入一个队列中等待分配资源。这种管理排队会话的算法或策略，就是队列方法（Queuing Method）。V$RSRC_CONSUMER_GROUP 视图则实时反映了每个消费者组的资源使用情况和队列状态。

2. `V$RSRC_CONSUMER_GROUP` 视图概述与使用场景

作用：V$RSRC_CONSUMER_GROUP 动态性能视图提供了当前实例中所有资源消费者组（Resource Consumer Group）的实时统计信息。它展示了每个组消耗的 CPU 资源、正在排队等待的会话数量、从队列中被移出的会话数量等关键指标。它是监控和诊断数据库资源管理器运行状况和效果的首要视图。

主要使用场景包括：

实时监控资源分配：DBA 可以实时查看哪个消费者组正在消耗最多的 CPU，以及是否有组正在经历排队。
诊断性能问题：当用户报告会话响应缓慢或“挂起”时，通过检查该视图可以快速判断会话是否正在资源管理器的队列中等待，从而将问题定位到资源竞争而非其他原因（如锁竞争、I/O 慢）。
验证资源计划效果：在实施或调整了资源计划后，DBA 通过此视图验证计划是否按预期工作，例如，是否成功限制了目标组的资源使用，并为高优先级组保障了资源。
容量规划与调优：长期收集该视图的历史数据，可以分析资源使用的趋势，为调整资源计划中的参数（如 CPU_P1、ACTIVE_SESS_POOL_P1、QUEUEING_P1）提供数据支持。

3. `V$RSRC_CONSUMER_GROUP` 关键字段详解

下表列出了该视图中与队列机制最相关的核心字段及其含义：

字段名称	类型	描述
NAME	VARCHAR2(32)	消费者组的名称。例如 `OLTP_GROUP`, `REPORTING_GROUP`, `OTHER_GROUPS`, `SYS_GROUP` 等。
ACTIVE_SESSIONS	NUMBER	当前属于该消费者组的活动会话总数。这包括正在执行的和在队列中等待的会话。
EXECUTING_SESSIONS	NUMBER	当前正在执行（即正在使用 CPU）的会话数。这是 `ACTIVE_SESSIONS` 的子集。
QUEUED_SESSIONS	NUMBER	当前正在队列中等待的会话数。这些会话是活动的，但尚未获得执行许可，因为已经达到了该组配置的 `ACTIVE_SESS_POOL_P1` 限制。`ACTIVE_SESSIONS = EXECUTING_SESSIONS + QUEUED_SESSIONS`。
SESSIONS_QUEUED	NUMBER	自实例启动以来，该消费者组中总共进入过队列的会话累计数量。这是一个历史总值。
CONSUMED_CPU_TIME	NUMBER	自实例启动以来，该组所有会话消耗的 CPU 时间总量（单位：百分之一秒）。
CPU_WAIT_TIME	NUMBER	自实例启动以来，该组所有会话因资源管理器限制而等待 CPU 的总时间（单位：百分之一秒）。这反映了因受限制而未能立即获得 CPU 的延迟。
YIELDS	NUMBER	自实例启动以来，该组会话主动让出 CPU 的次数。这是资源管理器内部调度机制（如时间片到期）的一个指标。

4. 相关视图与基表

V$RSRC_CONSUMER_GROUP 是资源管理器监控视图体系中的一员，要全面了解情况，需要结合其他相关视图。

4.1 相关动态性能视图

视图名称	描述
`V$RSRC_PLAN`	显示当前正在使用的资源计划（Resource Plan）。
`V$RSRC_SESSION_INFO`	显示每个会话的资源管理器相关信息，包括其当前的消费者组、之前的消费者组、排队状态等。这是会话级的详细视图。
`V$SESSION`	标准会话视图。其 `RESOURCE_CONSUMER_GROUP` 列显示了会话当前的消费者组。可以与 `V$RSRC_SESSION_INFO` 关联查询。
`V$RSRC_CONS_GROUP_HISTORY`	以每分钟一次的频率记录 `V$RSRC_CONSUMER_GROUP` 的历史快照，用于历史趋势分析。
`V$RSRC_SESS_HISTORY`	记录已完成的会话的资源使用历史信息。

4.2 基表信息

与 V$QUEUE 类似，资源管理器的 V$ 视图也建立在 X$ 表之上。

V$RSRC_CONSUMER_GROUP -> V_$RSRC_CONSUMER_GROUP -> GV_$RSRC_CONSUMER_GROUP -> X$KJRSDGC (可能的底层表之一，未公开)
此外，资源计划的元数据（静态定义）存储在数据字典基表中，如：
- DBA_RSRC_PLANS: 所有资源计划的定义。
- DBA_RSRC_CONSUMER_GROUPS: 所有消费者组的定义。
- DBA_RSRC_PLAN_DIRECTIVES: 所有资源计划指令（即分配规则）的定义。队列方法（如 EMPHASIS）和参数（如 QUEUEING_P1）正是在指令中定义的。
- 这些数据字典视图的基表是 SYS.RSRC_PLAN$, SYS.RSRC_CONSUMER_GROUP$, SYS.RSRC_PLAN_DIRECTIVE$ 等。

5. 底层原理与内部机制：队列方法如何工作

资源管理器中的“队列方法”并非一个独立的实体，而是资源分配指令的一部分。其底层原理涉及调度和排队算法。

资源计划激活：DBA 创建一个资源计划，其中包含多个指令。指令为每个消费者组分配 CPU 资源（使用 EMPHASIS 或 RATIO 方法），并可以设置活动会话池（ACTIVE_SESS_POOL_P1）等限制。该计划在实例级或会话级被激活。
会话分配与执行：用户会话被分配到特定的消费者组。资源管理器的调度器（Scheduler）根据活动计划中的指令为每个消费者组分配 CPU 时间片。
队列的产生（关键步骤）：
- 当一个会话变得活动并请求资源时，资源管理器会检查其所属消费者组的当前活动会话数（ACTIVE_SESSIONS）是否已经达到了 ACTIVE_SESS_POOL_P1 的限制。
- 如果未达到：会话立即开始执行（EXECUTING_SESSIONS 增加）。
- 如果已达到：新的活动会话不会被立即执行，而是被放入一个先进先出（FIFO）的队列中等待。此时，QUEUED_SESSIONS 和 SESSIONS_QUEUED 会增加。
队列的消耗：
- 当某个当前正在执行的会话完成工作变为非活动状态（或让出 CPU）时，它会释放一个“槽位”。
- 调度器然后从队列的头部取出一个等待的会话，允许其开始执行。这就是 FIFO 队列的工作方式。
- 参数 QUEUEING_P1 可以指定会话在队列中的最大等待时间，超时后会报错 ORA-07454 并退出队列。
CPU 分配方法：EMPHASIS 和 RATIO 是两种主要的 CPU 分配方法，它们决定了如何在组间分配时间片，这直接影响队列的出队速度。
- EMPHASIS (强调)：基于百分比的多级优先分配。CPU 资源按比例分配，高优先级的队列（如 LEVEL 1）会先被调度，有资源剩余才分配给 LEVEL 2。这是最常用的方法。
- RATIO (比率)：基于简单权重的单级分配。

6. 常用查询 SQL 示例

6.1 监控当前消费者组资源使用和队列状态

这是最核心的监控查询，展示了所有组的实时状态。

SELECT name,
       active_sessions,
       executing_sessions,
       queued_sessions,
       sessions_queued,
       round(consumed_cpu_time / 100, 2) AS consumed_cpu_sec,
       round(cpu_wait_time / 100, 2) AS cpu_wait_sec
FROM v$rsrc_consumer_group
ORDER BY queued_sessions DESC, cpu_wait_sec DESC;

6.2 查找正在排队的会话详情

此查询将资源管理器队列信息与会话详细信息关联，用于具体问题诊断。

SELECT s.sid,
       s.serial#,
       s.username,
       s.module,
       s.program,
       s.status AS session_status,
       s.event,
       rcg.name AS consumer_group,
       rsi.current_queue_duration AS queue_time_sec
FROM v$session s,
     v$rsrc_session_info rsi,
     v$rsrc_consumer_group rcg
WHERE s.sid = rsi.sid
  AND rsi.current_consumer_group_id = rcg.id
  AND rsi.queued = 'YES' -- 关键：过滤出正在排队的会话
ORDER BY queue_time_sec DESC;

6.3 查看当前活动的资源计划及其指令

此查询检查当前正在使用的资源计划的配置，了解队列策略的根源。

SELECT plan,
       group_or_subplan,
       type,
       cpu_p1, cpu_p2, cpu_p3, cpu_p4, -- CPU 分配比例
       active_sess_pool_p1, -- 活动会话池限制，队列的根源
       queueing_p1, -- 队列超时时间
       parallel_degree_limit_p1 -- 并行度限制
FROM v$rsrc_plan; -- 或查询 DBA_RSRC_PLAN_DIRECTIVES 获取更多细节

7. 重要知识点与注意事项

V$QUEUEING_MTH 视图：如开头所述，此视图在标准 Oracle 19C 中不存在。队列方法是资源计划指令的一个属性，其效果通过 V$RSRC_CONSUMER_GROUP 和 V$RSRC_SESSION_INFO 等视图监控。
队列与锁等待的区别：资源管理器造成的队列（resmgr:cpu quantum 或 resmgr:become active 事件）与传统的锁等待（enq: TX - row lock contention）或 I/O 等待（db file sequential read）完全不同。前者是资源分配的主动管理，后者是资源竞争的被动结果。
ACTIVE_SESS_POOL_P1 与 PARALLEL_DEGREE_LIMIT_P1：这两个指令参数是引发队列的常见原因。前者限制并发活动会话数，后者限制并行查询的并行度。
OTHER_GROUPS：这是一个必须存在的消费者组，它在资源计划中捕获所有未明确映射到其他组的会话。任何计划都必须为 OTHER_GROUPS 定义指令。
动态修改：资源管理器允许在不重启实例的情况下动态修改计划、组和指令，但修改需要谨慎，以免对生产系统造成意外影响。