Instance Caging 是 Oracle 的软 CPU 限制机制，依赖 resource_manager_plan 和 cpu_count 配合实现，仅限单节点生效、需重启实例，不控制内存/IO。
Instance Caging 是什么，它真能限制单节点 CPU 使用？
能，但仅限于“软限制”——instance caging 不是操作系统级的 cgroup 隔离，而是 oracle 自己在实例启动后通过内部调度器主动让出 cpu 时间片。它依赖 resource_manager_plan 启用，且只对 cpu 起作用，不控制内存、io 或进程数。
常见误判是以为设了 cpu_count 就能硬锁住核数，其实那只是影响优化器计算执行计划的基数，和实际运行时 CPU 占用无关。真正起作用的是资源管理器 + Instance Caging 的组合。
启用 Instance Caging 的三步实操（RAC 环境下必须逐节点操作）
RAC 中每个实例独立管理资源，Instance Caging 必须在每个目标节点上单独配置，不能靠集群参数全局下发。
- 登录目标节点的实例（比如
srvctl stop instance -d orcl -i orcl1后用sqlplus / as sysdba连orcl1） - 设置
cpu_count为期望的逻辑 CPU 上限（例如限制为 8 核）：ALTER SYSTEM SET cpu_count=8 SCOPE=SPFILE;
- 启用资源管理器并绑定内置计划：
ALTER SYSTEM SET resource_manager_plan='DEFAULT_PLAN' SCOPE=BOTH;
（DEFAULT_PLAN是 Oracle 自带的、已启用 Instance Caging 的计划） - 重启该实例使
cpu_count生效：srvctl start instance -d orcl -i orcl1
注意：改完 cpu_count 不重启实例，Instance Caging 不会生效；resource_manager_plan 设为空或无效值也会静默失效。
验证是否真的生效？别只看 v$parameter
v$parameter 里 cpu_count 和 resource_manager_plan 都对，不代表正在限频。必须查运行时指标：
- 确认资源管理器活跃：
SELECT name, is_top_plan FROM v$rsrc_plan WHERE is_top_plan = 'TRUE';
应返回DEFAULT_PLAN - 检查当前实例的 CPU 使用是否被“削峰”：
SELECT name, active_sessions, consumed_cpu_time FROM v$rsrc_consumer_group WHERE name = 'OTHER_GROUPS';
如果consumed_cpu_time增长明显慢于系统负载上升，说明限频起作用 - 直接看 OS 层：在该节点跑
top -H，观察 Oracle 进程的 %CPU 总和是否稳定在cpu_count × 100%附近（比如设了 4，总和长期超不过 400%）
容易漏掉的点：RAC 中另一个节点可能没配，导致业务连接到未限制节点后突发高 CPU，误以为本节点配置失败。
和 Resource Manager Plan 自定义方案冲突怎么办？
如果你已创建自定义 plan（比如叫 MY_RAC_PLAN）并启用，DEFAULT_PLAN 就不会自动接管 —— Instance Caging 只绑定在 DEFAULT_PLAN 及其子计划中。要继续用自定义 plan，必须显式启用 Caging：
- 在 plan 中为
OTHER_GROUPS消费组指定CPU_P1或CPU_P2指令（不能只靠utilization_limit） - 或者更稳妥的方式：用
DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN创建一个极简 plan，把OTHER_GROUPS的CPU_P1设为所需比例，再启用它 - 切记：无论哪种方式，
cpu_count参数仍需设置，否则资源管理器无法换算物理核数基准
最常踩的坑是以为 “plan 里写了 utilization_limit=50 就等于限一半 CPU”，其实那是针对整个实例可分配 CPU 的百分比，不是对物理核的绝对限制；只有配合 cpu_count + DEFAULT_PLAN 或显式 CPU_P1，才能达成预期的节点级 CPU 封顶效果。
