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

在这里插入图片描述
经过全面检索，我没有找到关于 V$RSRCMGRMETRIC_HISTORY 动态性能视图的详细官方资料。不过，根据我对Oracle数据库的理解，V$RSRCMGRMETRIC_HISTORY 视图通常与 Oracle数据库资源管理器（Database Resource Manager） 相关，用于提供资源管理器相关的历史性能指标数据。这些指标通常以一定时间间隔（如每分钟）进行统计，并保留一段时间的历史记录，帮助DBA监控和诊断资源管理策略的长期执行情况和趋势。

请注意：以下介绍基于Oracle动态性能视图的一般知识和资源管理器的架构原理。鉴于该视图的详细信息未在公开搜索结果中充分体现，部分内容（尤其是字段和内部X$表名）可能需要您根据实际环境进行验证。

📊 1. 视图概述与作用

V$RSRCMGRMETRIC_HISTORY 视图的主要作用是提供Oracle数据库资源管理器（Database Resource Manager）在历史时间段内收集的资源消耗和性能指标的详细数据。它用于监控资源消费者组（Consumer Group）的历史资源使用情况，帮助DBA评估资源计划（Resource Plan）的长期有效性，并诊断资源分配相关问题。

核心作用：

历史趋势分析：提供历史时间段的资源使用情况快照，用于分析长期趋势和模式。
资源消费分析：展示每个资源消费者组（如OLTP_Group, BATCH_Group）的历史CPU使用、等待时间、活动会话数等。
策略效果评估：验证定义的资源计划指令（如CPU_P1, ACTIVE_SESS_POOL_P1）是否长期按预期工作。
问题诊断：帮助识别历史资源争用、限制触达（如因ACTIVE_SESS_POOL_P1或QUEUEING_P1导致的等待）等情况。

🔍 2. 主要应用场景

资源管理器性能监控：监控资源消费者组的历史CPU使用率、等待时间、排队会话数等，确保资源分配长期符合预期。
资源争用诊断：当出现性能问题时，使用此视图分析历史是否由于资源管理器限制（如resmgr: cpu quantum等待事件）导致。
资源计划调整验证：修改资源计划后，通过此视图观察历史资源分配的变化情况，验证调整效果。
容量规划：长期收集此视图数据，分析资源使用趋势，为容量规划提供依据。

📋 3. 字段详解

虽然不同Oracle版本该视图的字段可能略有差异，但以下是一些常见且核心的字段及其解释：

字段名称	数据类型	含义与说明	示例值
BEGIN_TIME	DATE	指标收集周期的开始时间。通常精确到秒，表示这一分钟统计窗口的开始。	`2023-10-05 14:30:00`
END_TIME	DATE	指标收集周期的结束时间。通常是`BEGIN_TIME`之后的一分钟。	`2023-10-05 14:31:00`
CONSUMER_GROUP_NAME	VARCHAR2(30)	资源消费者组名称。表示该组统计信息属于哪个资源消费者组（如`OLTP_GROUP`, `BATCH_GROUP`, `OTHER_GROUPS`）。	`'OLTP_GROUP'`
CPU_CONSUMED_TIME	NUMBER	CPU消耗时间（毫秒）。在该时间窗口内，该消费者组所有会话消耗的CPU总时间。	`150000`
CPU_WAIT_TIME	NUMBER	CPU等待时间（毫秒）。在该时间窗口内，该消费者组所有会话因资源管理器限制而等待CPU的总时间（例如，由于`resmgr: cpu quantum`等待事件）。	`5000`
RUNNING_SESSIONS	NUMBER	运行中的会话数。在该时间窗口内，该消费者组中处于运行状态（即正在使用CPU）的平均会话数。	`12`
RUNNING_SESSIONS_LIMIT_HIT	NUMBER	触发运行会话限制的次数。在该时间窗口内，由于活动会话池限制（`ACTIVE_SESS_POOL_P1`）而导致新会话无法立即运行的次数。	`3`
QUEUED_SESSIONS	NUMBER	排队中的会话数。在该时间窗口内，该消费者组中因活动会话池已满而处于排队状态的平均会话数。	`2`
YIELDS	NUMBER	yielding次数。在该时间窗口内，该消费者组的会话因资源管理器而主动让出CPU的次数（通常与`resmgr: cpu quantum`等待相关）。	`45`

说明：

CONSUMER_GROUP_NAME：OTHER_GROUPS 是一个特殊的消费者组，它包含所有没有明确映射到任何特定消费者组的会话。任何资源计划都必须为 OTHER_GROUPS 定义指令。
CPU_WAIT_TIME 和 YIELDS：这些字段与 resmgr: cpu quantum 等待事件直接相关，是诊断CPU资源限制的关键指标。
RUNNING_SESSIONS_LIMIT_HIT 和 QUEUED_SESSIONS：这些字段与活动会话池限制（ACTIVE_SESS_POOL_P1）相关，用于诊断并发会话数限制问题。

🔗 4. 相关视图与基表

核心相关视图:
- V$RSRCMGRMETRIC：提供当前资源管理器指标数据，通常只保留最近一个或多个周期的数据。
- DBA_RSRC_PLANS, DBA_RSRC_PLAN_DIRECTIVES, DBA_RSRC_CONSUMER_GROUPS：这些数据字典视图提供关于资源计划、指令和消费者组的静态配置信息。
- V$RSRC_PLAN：显示当前活跃的资源计划。
- V$SESSION：可以关联查看当前会话属于哪个消费者组（RESOURCE_CONSUMER_GROUP字段）。
- V$SYSMETRIC_HISTORY：提供系统级的性能指标历史数据，有时可以与资源管理器指标交叉参考。
底层基表与存储原理:
- V$RSRCMGRMETRIC_HISTORY 的数据来源于内存中的内部 X$ 表（其具体名称如 X$KJRSRCMH 或类似，通常未公开）。
- 这些指标由数据库资源管理器的后台进程（如VKRM）动态收集和更新。
- 数据是易失性的，实例重启后不会持久化。V$RSRCMGRMETRIC_HISTORY 通常保留较长时间的历史数据（如一小时），而 V$RSRCMGRMETRIC 则只显示最近周期。

⚙️ 5. 底层原理与知识点

Oracle数据库资源管理器（Resource Manager） 允许DBA对数据库内的资源（主要是CPU和并发度）进行更精细的分配和管理，以防止资源密集型应用耗尽系统资源并影响关键业务的性能。

其核心概念包括：

资源消费者组（Resource Consumer Group）：将会话分组，如“OLTP用户”、“批处理作业”、“报告用户”。
资源计划（Resource Plan）：定义资源分配的总体策略，指定在不同消费者组之间如何分配资源。
资源计划指令（Resource Plan Directive）：将消费者组与资源计划关联起来，并指定该组在计划中的资源分配规则（如CPU百分比、活动会话池限制、并行度限制、执行时间限制等）。

V$RSRCMGRMETRIC_HISTORY 视图反映的正是这些资源计划指令的历史执行情况和效果。

CPU管理原理：
Oracle资源管理器通过内部调度来实现CPU分配。当一个会话尝试使用CPU时，资源管理器会检查其所属消费者组的CPU资源使用是否已经达到计划指令的限制。如果达到限制，该会话会被暂时置于 resmgr: cpu quantum 等待状态，并记录到 CPU_WAIT_TIME 和 YIELDS 中，直到下一个调度周期。这确保了CPU资源按照配置的比例进行分配。

活动会话池管理原理：
ACTIVE_SESS_POOL_P1 参数限制了一个消费者组中同时处于活动状态（即非空闲等待）的会话数量。如果活动会话数达到上限，新的会话需要执行工作时将会被放入队列（记录在 QUEUED_SESSIONS），直到有活动会话完成工作变为非活动状态。如果会话无法立即进入活动状态，可能会记录 RUNNING_SESSIONS_LIMIT_HIT。

🔧 6. 常用查询SQL示例

查看特定消费者组（如OLTP_GROUP）的历史资源消耗趋势

SELECT TO_CHAR(begin_time, 'YYYY-MM-DD HH24:MI:SS') AS begin_time,
       consumer_group_name,
       cpu_consumed_time,
       cpu_wait_time,
       running_sessions,
       queued_sessions
FROM   v$rsrcmgrmetric_history
WHERE  consumer_group_name = 'OLTP_GROUP'
ORDER BY begin_time DESC;

检测历史是否有资源限制事件（如CPU等待或会话排队）

SELECT begin_time,
       consumer_group_name,
       cpu_wait_time,
       queued_sessions,
       running_sessions_limit_hit
FROM   v$rsrcmgrmetric_history
WHERE  cpu_wait_time > 0 OR queued_sessions > 0 OR running_sessions_limit_hit > 0
ORDER BY begin_time DESC;

比较不同消费者组的CPU使用情况

SELECT TO_CHAR(begin_time, 'YYYY-MM-DD HH24:MI') AS begin_time,
       consumer_group_name,
       ROUND(cpu_consumed_time / 1000, 2) AS cpu_seconds,
       ROUND(cpu_wait_time / 1000, 2) AS cpu_wait_seconds
FROM   v$rsrcmgrmetric_history
WHERE  begin_time > SYSDATE - 1/24 -- 最近1小时
ORDER BY begin_time, consumer_group_name;

分析资源管理器限制触发的频率

SELECT consumer_group_name,
       COUNT(*) AS sample_count,
       SUM(CASE WHEN cpu_wait_time > 0 THEN 1 ELSE 0 END) AS cpu_wait_samples,
       SUM(CASE WHEN queued_sessions > 0 THEN 1 ELSE 0 END) AS queued_samples,
       SUM(CASE WHEN running_sessions_limit_hit > 0 THEN 1 ELSE 0 END) AS session_limit_samples
FROM   v$rsrcmgrmetric_history
WHERE  begin_time > SYSDATE - 1 -- 最近1天
GROUP BY consumer_group_name
ORDER BY cpu_wait_samples DESC;

⚠️ 7. 重要注意事项

数据时效性：V$RSRCMGRMETRIC_HISTORY 中的数据不会永久保留，它仅反映一定时间范围内的历史活动。需要更长期的数据应考虑使用AWR或Statspack报告。
权限要求：查询这些视图通常需要 SELECT 权限 on V_$RSRCMGRMETRIC_HISTORY，这通常通过 SELECT_CATALOG_ROLE 或直接授权获得。
资源管理器状态：只有在启用了资源管理器（即设置了 RESOURCE_MANAGER_PLAN 参数）且该计划确实包含限制性指令时，此视图中的数据才具有丰富的意义。如果未启用资源管理器，大多数值可能为0或NULL。
理解等待事件：资源管理器的主要等待事件是 resmgr: cpu quantum（CPU资源限制）和 resmgr: become active（活动会话池限制）。当这些等待事件显著时，应结合此视图分析具体是哪个消费者组受到了影响。
性能开销：启用资源管理器并频繁收集指标会有轻微的性能开销，但通常对于需要资源控制的环境来说是值得的。