Oracle RAC 不支持基于时间段的原生动态资源分配，因其资源调度由操作系统和Clusterware统一管理，无法自动增减实例数或调整cpu_count/memory_target；替代方案是用DBMS_SCHEDULER切换Resource Manager计划或通过srvctl控制服务权重。
oracle rac 本身不支持“基于时间段”的原生动态资源分配策略——没有内置的 scheduler-based resource scaling 功能，所有节点级 cpu/内存资源调度均由操作系统和 oracle clusterware 统一管理，无法按小时或星期几自动增减实例数、调整 cpu_count 或 memory_target。
为什么不能直接配置“时间段+自动扩缩容”
Oracle RAC 的资源（如实例、服务、ASM 磁盘组）是静态部署、手动启停的。Clusterware（crsctl）和数据库实例不具备根据时间触发资源配置变更的能力；DBMS_SCHEDULER 可执行作业，但无法安全修改运行中实例的 cpu_count 或重启实例——这类操作会中断连接、破坏 RAC 一致性。
- 试图用调度器调用
srvctl modify database -n <db> -c <count>会失败：RAC 不允许在线修改节点数 -
ALTER SYSTEM SET cpu_count=... SCOPE=SPFILE需重启实例生效，而srvctl stop instance会触发服务漂移，影响应用可用性 - Oracle Resource Manager（
DBMS_RESOURCE_MANAGER）可按用户/模块限 CPU 资源，但不感知“时间段”，需配合DBMS_SCHEDULER手动切换 plan，且仅作用于 SQL 执行层，不改变物理资源分配
可行替代方案：用 DBMS_SCHEDULER + Resource Manager 切换资源计划
这是最接近“时间段动态分配”的生产级做法：在不同时间段激活不同的资源管理计划（plan），控制各 consumer group 的 CPU 比例和并发限制。
- 先创建两个 plan：
DAYTIME_PLAN（工作时间高优先级）、NIGHT_PLAN（夜间低配） - 用
DBMS_SCHEDULER.CREATE_JOB在每天 07:00 启用DAYTIME_PLAN，22:00 启用NIGHT_PLAN - 确保实例已启用资源管理：
ALTER SYSTEM SET resource_manager_plan = 'DEFAULT_PLAN' SCOPE=BOTH（初始空 plan），后续由 job 动态覆盖 - 注意：
resource_manager_plan是实例级参数，所有节点需同步配置；job 必须在每个实例上单独创建，或使用instance_name条件限定执行节点
示例 job 创建语句：
BEGIN
DBMS_SCHEDULER.CREATE_JOB(
job_name => 'switch_to_daytime_plan',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN DBMS_RESOURCE_MANAGER.SWITCH_PLAN(''DAYTIME_PLAN''); END;',
start_date => TRUNC(SYSDATE) + 7/24,
repeat_interval => 'FREQ=DAILY; BYHOUR=7; BYMINUTE=0',
enabled => TRUE
);
END;
更彻底的方案：结合外部脚本与 srvctl 控制服务权重
若业务允许部分时段降级服务（非核心实例停运），可通过 OS 层定时任务 + srvctl 控制服务分布，间接实现“时间段资源倾斜”。
- 定义两个服务：
OLTP_SVC（主服务，权重 100）和BATCH_SVC（批处理服务，权重 50） - 夜间（23:00–06:00）运行脚本：
srvctl modify service -d mydb -s OLTP_SVC -r -i node2（从 node2 上移除 OLTP_SVC，迫使流量集中到 node1） - 同时启动
BATCH_SVC并绑定到 node2：srvctl add service -d mydb -s BATCH_SVC -r -i node2 - 必须验证服务的
clb_goal和rlb_goal设置是否匹配负载策略，否则客户端连接不会按预期路由 - 该方式绕过数据库内部机制，依赖 Clusterware 服务管理，风险在于误操作可能使服务离线——务必在
srvctl status service验证后再上线
容易被忽略的关键约束
RAC 的“资源”本质是共享的：CPU、内存、IO 都由所有节点共同竞争访问，所谓“分配”只是通过软件策略引导负载，并不真正隔离物理资源。任何时间段策略都面临三个硬限制：
- 实例数固定：无法在运行时新增或删除 RAC 实例，只能启停，而停实例等于降低整体可用性
- ASM 磁盘组不可分时段挂载/卸载——存储层无时间维度控制能力
- 即使成功切换资源计划，也无法限制归档日志生成、AWR 快照或后台进程（如
LGWR、CKPT）的资源消耗，它们始终全量运行
真正需要时间段弹性伸缩的场景（如测试环境周期性压测），建议改用 Oracle Multitenant + PDB snapshot copy + 单实例快速克隆，而非强推 RAC 做时间感知调度。
