在Oracle RAC架构演进中，数据库实例的管理方式逐步从静态绑定走向动态调度。Administrator Managed是早期版本延续下来的管理模型，它要求数据库管理员在创建数据库时就明确每个实例运行在哪一台服务器上，这种映射关系被写入OCR并长期固定。Policy Managed则是从11g R2开始引入的基于服务器池的策略化管理模型，集群依据用户定义的策略和可用服务器池资源，自动决定实例的启动位置与数量。两种模型并非简单的新旧替代，而是在不同业务场景下各有适用面。
Administrator Managed的管理机制与配置方式
Administrator Managed模型的核心特征是实例与节点名称强绑定。当你使用DBCA创建数据库并选择该模式时，系统会为每一个指定的节点生成一个实例，例如节点node1上运行orcl1，节点node2上运行orcl2。这种绑定信息存储在Oracle Clusterware的OCR中，由数据库资源ora.orcl.db所引用。管理员通过srvctl命令可以清晰看到每个实例的固定家目录与节点依赖，日常运维中定位问题较为直接。
在资源配置上，Administrator Managed通常配合固定的VIP和监听器使用。如果集群需要扩容，比如新增node3，管理员必须手动执行srvctl add instance来登记新实例orcl3，并将其关联到node3，同时修改数据库初始化参数如instance_number和thread。这种人工介入的方式在节点数量少、业务固定的内网系统中比较稳妥，因为变更路径完全可控，不会出现实例被调度到未知节点的情形。
下面的示例展示了如何查看Administrator Managed数据库的实例配置。从输出能够看到INSTANCE_NAME与NODE_NAME的一一对应关系，这也是该模型最直观的体现。
-- 查看Administrator Managed数据库实例信息 srvctl config database -db orcl -- 输出示例： -- Database unique name: orcl -- Database name: orcl -- Oracle home: /u01/app/oracle/product/19.0.0/dbhome_1 -- Node: node1 -- Node: node2 -- Instance: orcl1, node: node1 -- Instance: orcl2, node: node2
Policy Managed的服务器池与策略调度原理
Policy Managed模型彻底解耦了实例与物理节点的绑定关系。集群中存在一个或者多个服务器池（server pool），比如pool_a定义为最少1台、最多2台服务器。数据库被创建为Policy Managed后，它只声明自己需要几个实例，例如CARDINALITY=2，至于这两个实例具体落在哪几台服务器上，由Clusterware根据池内可用服务器和策略自动安排。当某台服务器宕机，实例会在池内其他机器上自动重启，无需人工改配置。
这种调度能力依赖于OCR中的服务器分类属性和策略规则。管理员可以用srvctl修改池的MIN、MAX、IMPORTANCE参数，也可以基于业务负载编写策略，让不同数据库在资源紧张时按权重抢占服务器池。对于私有云或需要随业务峰谷频繁扩缩容的环境，Policy Managed显著降低了运维复杂度。不过它的抽象层更高，排错时需要先确认服务器归属池，再追溯实例分配逻辑，学习曲线比Administrator Managed更陡。
以下命令演示了创建一个服务器池并将数据库设为Policy Managed的基本过程。注意 DATABASE_TYPE 设置为 RAC 且未指定节点，仅给定实例数量。
-- 创建服务器池 srvctl add srvpool -serverpool pool_a -min 1 -max 2 -importance 1 -- 将数据库配置为Policy Managed srvctl modify database -db orcl -serverpool pool_a -dbtype RAC -cardinality 2 -- 查看服务器池状态 srvctl status srvpool -serverpool pool_a
两种模型在运维与高可用场景中的差异对比
从故障切换角度看，Administrator Managed的实例故障后只能在预设节点恢复，如果该节点硬件损坏且未提前配置冗余，就需要管理员紧急介入迁移实例。Policy Managed则依托服务器池，只要池内还有空闲服务器，实例就能自动飘移，对业务中断时间更短。在隔离性方面，多租户环境下使用Policy Managed可以为不同业务划分独立池，避免资源争抢，而Administrator Managed只能通过操作系统层面的cgroup等外部手段补充。
在扩容与缩容效率上，二者差距明显。Administrator Managed新增节点需停部分管理操作并改多处配置，容易在变更窗口出错。Policy Managed仅需把新服务器加入集群并归入对应池，数据库实例会根据CARDINALITY自动补足，全程无需动数据库配置。下面的对照表总结了关键维度差异，便于架构选型时快速判断。
| 对比维度 | Administrator Managed | Policy Managed |
|---|---|---|
| 实例与节点关系 | 固定绑定 | 池内动态分配 |
| 扩容操作 | 手动加实例 | 自动按池扩充 |
| 故障恢复位置 | 原节点 | 池内任意可用节点 |
| 适用场景 | 节点少且稳定 | 弹性云环境 |
实际生产中也可以并存：核心交易库用Administrator Managed保稳定，报表类库用Policy Managed追弹性。但需注意OCR中两类资源不能混用同一服务器池，否则会导致调度冲突。理解清楚二者底层依赖，才能在RAC集群生命周期里少走弯路。
Oracle_RACPolicy_ManagedAdministrator_Managed修改时间：2026-08-19 03:10:15