<p>Oracle 19c RAC中无法通过v$pdbs或v$sysstat获取PDB级IO吞吐量，必须启用CDB资源计划后查询v$rsrc_pdb_metric视图，并结合enq: IO - rate limit等待事件验证限流效果。</p>
直接查 v$pdbs 和 v$sysstat 看不到PDB级IO吞吐量
oracle 19c rac 中，v$sysstat、v$iostat_function 这类视图只在 cdb$root 汇总，不按 pdb 切分；v$pdbs 本身不含 i/o 统计字段。硬凑 con_id 关联没有意义——i/o 计数器不在 pdb 命名空间里暴露。真要监控 pdb 级别 io 吞吐，必须依赖资源管理框架+等待事件+外部采样组合判断。
必须先启用 CDB 资源计划，否则 MAX_IOPS/MAX_MBPS 不生效
这是最常被跳过的前提。即使你在 PDB 里执行了 ALTER SYSTEM SET max_iops = 200 SCOPE=BOTH，只要 CDB$ROOT 没启用资源计划，这些参数就只是摆设。确认方法：
- 在 CDB$ROOT 执行：
SELECT value FROM v$parameter WHERE name = 'resource_manager_plan'—— 返回空或''就没开 - 再查：
SELECT plan, status FROM DBA_RSRC_PLANS WHERE status = 'ACTIVE'—— 必须有至少一行返回 - 若未启用，立即执行：
ALTER SYSTEM SET resource_manager_plan = 'DEFAULT_PLAN' SCOPE=BOTH
DEFAULT_PLAN 是 Oracle 自带的、唯一默认支持 PDB_DIRECTIVE 的基础计划。自定义 plan 若没显式包含 PDB 指令，改参数也没用。
用 v$rsrc_pdb_metric 查实时 IO 吞吐（单位：MB/s 和 IOPS）
该视图是唯一原生支持 PDB 级别 IO 监控的动态性能视图，每 15 秒自动刷新一次。关键字段：
-
CON_ID：对应 PDB 的容器 ID -
MEASURE：值为IOPS或MBPS，区分指标类型 -
VALUE：当前 15 秒窗口内的平均值（不是峰值） -
TIME_WAITED：累计等待时间，可用于反推是否触发限流
常用查询：
SELECT p.name pdb_name,
m.measure,
ROUND(m.value, 2) value,
m.time_waited
FROM v$rsrc_pdb_metric m
JOIN v$pdbs p ON m.con_id = p.con_id
WHERE m.measure IN ('IOPS', 'MBPS')
ORDER BY p.name, m.measure;注意：v$rsrc_pdb_metric 在 RAC 中只反映本实例视角的 PDB IO（即当前节点上该 PDB 的会话发起的 IO），不聚合跨节点流量。若某 PDB 跨节点负载不均，需在每个节点分别查。
识别 IO 限流是否真正起作用：看 enq: IO - rate limit 等待事件
当 PDB 触发 MAX_IOPS 或 MAX_MBPS 限制时，会话不会报错，但会出现新的等待事件：enq: IO - rate limit。它不像传统锁等待那样阻塞，而是让 IO 请求排队，造成延迟上升、吞吐下降。
- 查当前活跃等待：
SELECT event, seconds_in_wait FROM v$session WHERE event = 'enq: IO - rate limit' - 查历史累计等待：
SELECT event, time_waited_micro/1000000 sec_total FROM v$system_event WHERE event = 'enq: IO - rate limit' - 若该事件频繁出现且
v$rsrc_pdb_metric.VALUE接近你设置的MAX_IOPS/MAX_MBPS，说明限流已介入
这个等待事件在 AWR 报告中归类于 “Other” 类别，容易被忽略；且仅在限流实际发生时才计入，不是只要设了参数就一直存在。
真实 IO 能力和配置值之间常有 gap：比如 MAX_IOPS=100 并不意味着稳定跑出 100，尤其在 RAC 中受缓存一致性协议、全局队列争用、ASM 分配单元大小影响。不要只盯参数，得结合 v$asm_disk_iostat（单节点 ASM 层）和应用端响应时间交叉验证。
