Oracle 12c如何利用资源管理器限制I/O流量_配置Resource Manager-Oracle-PHP中文网

resource manager 不能直接限制 i/o 流量，真正实现 pdb 级物理 i/o 硬限速的是 max_iops 和 max_mbps 参数，需在目标 pdb 内用 alter system 设置，且须配合启用 resource_manager_plan 才能协同管控 cpu 与 i/o。

resource manager 本身不能直接限制 i/o 流量——这是最常见的认知偏差。真正能对 pdb 级别物理 i/o 做硬性限速的，是 max_iops 和 max_mbps 这两个初始化参数，且它们只在 pdb 中设置才生效，与 resource manager 的消费者组、计划指令完全无关。

`MAX_IOPS` 和 `MAX_MBPS` 必须在 PDB 级别显式设置

这两个参数不走 DBMS_RESOURCE_MANAGER API，而是通过 ALTER SYSTEM 在目标 PDB 内执行：

MAX_IOPS 控制每秒最大 I/O 操作次数（非逻辑读，是底层物理 I/O）
MAX_MBPS 控制每秒最大 I/O 吞吐量（MB/s），单位是 MiB/s（1024×1024 字节）

常见错误现象：

在 CDB$ROOT 中执行 ALTER SYSTEM SET MAX_IOPS = 500 —— 这只是设为所有新 PDB 的默认值，现有 PDB 不继承，也不生效。

正确做法：

先切换容器：ALTER SESSION SET CONTAINER = pdb_sales;
再设参：ALTER SYSTEM SET MAX_IOPS = 300 SCOPE = BOTH;
同理设吞吐：ALTER SYSTEM SET MAX_MBPS = 120 SCOPE = BOTH;
确认生效：SHOW PARAMETER max_iops（必须在该 PDB 内查）

注意：设为 0 表示不限制；低于 100 的 MAX_IOPS 或低于 25 的 MAX_MBPS 不推荐，可能引发频繁限流抖动。

`Resource Manager` 对 I/O 的“间接影响”仅限于 CPU 调度

Resource Manager 的 CREATE_PLAN_DIRECTIVE 支持 CPU_P1、PARALLEL_DEGREE_LIMIT_P1 等，但不支持任何 I/O 配额字段。它能做的只有：

降低某消费者组的 CPU 时间占比 → 减少其发起 I/O 的并发能力
限制并行度（PARALLEL_SERVER_LIMIT）→ 抑制并行查询产生的突发 I/O

但这不是 I/O 限速，而是“釜底抽薪”式压制。一旦用户用单线程大表全扫 + 大 buffer cache，Resource Manager 完全无法干预其物理 I/O 发起节奏。

典型误操作：

oracle知识库

oracle知识库下载

下载

给报表用户建了 REPORTING_GROUP，配了 CPU_P1 = 10，以为就能控住磁盘压力 → 实际 I/O 仍打满
在 CREATE_PLAN_DIRECTIVE 里硬写 MAX_IOPS = 200 → 语法报错，该参数根本不在指令支持列表中

如何验证 I/O 限速是否真实生效

出现 resmgr: I/O rate limit 等待事件，才是限速起作用的直接证据：

查当前阻塞会话：

SELECT event, p1 AS pdb_id, sql_id, sample_time
FROM v$active_session_history
WHERE event = 'resmgr: I/O rate limit'
AND sample_time > SYSDATE - 1/24;

关联 PDB 名称：

SELECT h.event, c.pdb_name, h.sql_id
FROM v$active_session_history h
JOIN cdb_pdbs c ON c.con_id = h.p1
WHERE h.event = 'resmgr: I/O rate limit';

如果长期没这个等待，但业务 I/O 很高，说明参数没生效或设为 0；如果频繁出现且伴随 SQL 响应变慢，说明限速已触发，需调高阈值。

`Resource Manager` 和 `MAX_IOPS/MAX_MBPS` 必须协同才完整

单独开任一机制都不够：

只设 MAX_IOPS/MAX_MBPS：能压住物理 I/O，但无法约束 CPU 使用和并行度，一个用户仍可占满 CPU 并拖慢其他会话
只配 Resource Manager：能分 CPU、控并行、切组，但对 I/O 完全无感，IO 密集型语句照样打爆存储

生产环境必须两者并用：

PDB 级设 MAX_IOPS/MAX_MBPS 拦住物理 I/O 洪水
同一 PDB 内配 Resource Manager 计划，按业务优先级分 CPU 和并行资源
确保 v$parameter.resource_manager_plan 非空（如 DEFAULT_PLAN），否则 Resource Manager 整体不激活

最容易被忽略的是：PDB 中 resource_manager_plan 参数为空时，MAX_IOPS 虽然生效，但 Resource Manager 的 CPU 分配、组切换等全部失效——你得手动打开它。