Policy-Managed 默认只启单实例，因未配置服务器池的 MIN_SIZE/MAX_SIZE 或未绑定数据库；需用 crsctl 创建池、srvctl 绑定，并重启数据库生效。
policy-managed 架构不是“配完就跑”的模式，它依赖服务器池（server pools）的定义和策略生效逻辑。默认安装 oracle 12c rac 后，数据库实例往往只在单节点启动，这不是故障，而是 policy-managed 的初始行为——它在等你明确告诉它“哪些资源归谁用”。
为什么 dbca 创建后只看到一个实例在运行
这是 Policy-Managed 最常被误判为“失败”的现象。根本原因在于：未显式配置服务器池的 MIN_SIZE 和 MAX_SIZE，或未将数据库绑定到目标池。
-
crsctl status serverpool会显示默认池Free和Generic，但你的数据库可能没分配到任何池 -
srvctl config database -d <db_name>输出中若无Server pools:行，说明数据库未关联池 - 即使指定了池名，若该池
MIN_SIZE=0或当前可用节点不满足CANDIDATE_SERVERS列表，实例也不会启动
创建并绑定服务器池的关键命令
必须用 crsctl 手动创建池（dbca 图形界面不暴露全部参数），再用 srvctl 绑定数据库。不能跳过这步直接建库。
- 创建带约束的池：
crsctl add serverpool mypool -attr "MIN_SIZE=2,MAX_SIZE=4,CANDIDATE_SERVERS='rac01 rac02 rac03'" - 验证池状态：
crsctl status serverpool mypool -f，关注SERVER_NAMES和ACTIVE_SERVERS - 将已有数据库绑定到池：
srvctl modify database -d PROD -g mypool - 强制重平衡（触发实例迁移）：
srvctl start database -d PROD（不是start instance）
注意：srvctl modify database 不会立即启动新实例，需配合 start database 或等待 CRS 自动调度。
实例名后缀下划线与节点选择逻辑
Policy-Managed 下实例名格式固定为 <DB_NAME>_<N>（如 PROD_1、PROD_2），这是 CRS 根据池内 ACTIVE_SERVERS 动态分配的结果，无法手动指定某实例跑在哪台机器上。
- 节点选择由 CRS 内部策略决定：优先使用
CANDIDATE_SERVERS中在线且负载低的节点 - 若节点宕机，CRS 会自动将实例迁移到池内其他节点，但不会超出
MAX_SIZE - 手动停掉一个实例（
srvctl stop instance -i PROD_2）后，CRS 可能立刻拉起PROD_3补位——只要池还有余量
这种“不可预测性”正是 Policy-Managed 的设计目标：管理员管策略，不管具体位置。
容易忽略的兼容性陷阱
看似简单的池配置，实际受多个隐含条件制约：
- Oracle 12.1 及以后版本才支持多节点
MIN_SIZE > 1；12.1 之前版本即使配置了MIN_SIZE=2，也只允许一个实例运行 - 所有候选节点必须已加入集群且
crsctl check crs全部通过，否则CANDIDATE_SERVERS中的离线节点会被静默忽略 - 若使用 Flex ASM，服务器池必须包含至少一个 ASM 实例所在节点，否则数据库无法挂载磁盘组
-
srvctl modify database -g后必须重启数据库才能生效，仅 reload 不够
最隐蔽的问题是：RAC One Node 环境下 Policy-Managed 不可用，它强制要求多节点集群且 CRS 完全在线——这点文档极少强调，但实操中高频报错。
