软件环境：
操作系统：Red Hat Enterprise Linux 5.4(Tikanga)
Oracle：11gR2 11.2.0.4.0 RAC
数据库名称: racdb
RAC集群两节点名称：racdb01，racdb02
Policy-Managed方式介绍
基于策略的管理方式，是以服务器池（Server Pools）为基础的，简单地说，就是先定义一些服务器池，池中包含一定量的服务器，然后再定义一些策略，根据这些策略Oracle会自动决定让多少数据 库实例运行在池中的几台机器上。数据库实例名后缀、数据库实例个数、所运行的主机，这些都是通过策略决定的，而不是数据库管理员事先定好的。
何种环境适合使用这种新的方式进行管理？
当管理大量的服务器集群，并且在这些集群中运行着多种不同重要程度，不同策略的RAC数据库时，为了简化管理，建议使用Policy- Managed方式，实际上Oracle也建议只有在超过3台的服务器的时候才使用Policy-Managed来管理整个数据库集群。想象一下使用 Policy-Managed方式可以达到的效果：如果我们有10台服务器组成，根据不同的应用的重要性定义服务器池的关键程度，然后在其中某些机器意外 停机的情况下，仍然可以自动地保持足够多的机器给重要的系统提供数据库服务，而将不关键的系统数据库服务器个数降低到最低限度。
策略管理：DBA指定数据库资源运行在哪个服务器池(排除generic or free)。Oracle Clusterware负责将数据库资源放在一台服务器。
Policy managed: Database administrators specify in which server pool (excluding generic or free) the database resource will run. Oracle Clusterware is responsible for placing the database resource on a server.
服务器以如下次序被分配入服务器池：
Generic server pool
User assigned server pool
Free
Oralce Clusterware使用服务器池的重要性决定分配服务器次序：
- 按重要性次序分配服务器给所有服务器池，直到满足服务器池的最小数目要求
- 按重要性次序分配服务器给服务器池，直到它们满足服务器池的最大数目要求
- 默认，任何剩下的服务器加入FREE服务器池
策略管理数据库背后的目标是删除到1个特定实例或服务 服务的硬编码
数据库可以和1个服务器池关联(而不是特定的节点集)。服务器池决定被资源(数据库，服务，第三方应用程序)所需的最小和最大服务器数目。
数据库实例将运行在已被分配给服务器池的服务器上。(使用min_size决定数据库必需运行在哪些服务器，以及必需运行在多少服务器上)
既然被分配给服务器池的服务器可以动态地变更，这允许Oracle基于集群可用的服务器总数动态地交付服务。
数据库实例将启动在足够多的服务器上(受制于服务器的可用性)。无需硬编码规定数据库实例运行在哪些服务器上。
数据库的任何实例可以运行在任何节点上。在实例号和节点之间无固定的映射关系。
当服务器被释放/添加/删除时，他们按之前提及的规则被分配到存在的服务器池中。
理论上的例子
例如，如果1个集群，总共有8个节点组成，并且支持3个RAC数据库。每个数据库将定义服务器的最小和最大数目。
假设DB1定义最小4台、最多6台服务器(重要性为10)，
假设DB2定义最小2台、最多3台服务器(重要性为7)，
假设DB3定义最小2台、最多3台服务器(重要性为5)。
初始8节点将被配置成节点1-4被分配给DB1，节点5-6被分配给DB2，节点7-8被分配给DB3。如果节点3由于某种原因发生故障，系统将分配节点7或8给DB1，因为其比DB3有更高的重要性而且最小需要4台服务器，即使将导致DB3降到最小服务器水平以下。如果节点3被重新激活，将被立即分配给DB3以使数据库恢复到最小所需的服务器数。
如果第9个节点被添加到集群，将被分配给DB1，因为其重要性最高而且未满足最大服务器数。
Admin-Managed方式介绍
实际上上面的表述已经明确说明了，Policy-Managed和Admin-Managed方式的差别。让我们再回顾一下，在以往我们创建一个RAC数 据库大概是怎样的方法，我们在dbca的界面中会选择要将数据库实例运行在整个集群中的几台机器上，或者是2台或者是3台，甚或是更多，但是只要在安装的 时候选定几台机器，那么以后如果不做增减节点的操作，就始终会在这几台机器上运行。而且，通常会根据主机名称的排序自动将每台主机上的数据库实例依次命名 为dbname1到dbnameN。这些在管理员安装完毕以后，都不会再自动变化，这就是Admin-Managed方式。
管理员管理：DBA指定数据库资源运行的所有服务器，并且按需手动放置资源。这是之前版本Oracle数据库使用的管理策略。
Administrator-managed: Database administrators define the servers on which databases resource run, and place resources manually as needed. This is the management strategy used in previous releases.
Policy-Managed方式和Admin-Managed方式Service使用例子
1，如何检查是否Admin managed方式:
[grid@racdb01 ~]$ srvctl config database -d racdb
Database unique name: racdb
Database name: racdb
Oracle home: /app/product/oracle/11.2.0.4/db_1
Oracle user: oracle
Spfile: /app/product/oracle/11.2.0/db_1/dbs/spfileracdb1.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: racdb
Database instances: racdb1,racdb2
Disk Groups: ASM_DATA,ASM_FRA
Mount point paths:
Services: rac_first,rac_second
Type: RAC
Database is administrator managed
这就说明是以Admin Managed 来管理RAC。
2，下面举例子来说明如何检查和修改数据库服务器池及Service
A，添加服务器池mypool(最小数目0，最大数目2)
[oracle@racdb01 ~]$ srvctl add serverpool -g mypool -l 0 -u 2
将数据库加入到自定义的Server Pool 里面：
B，修改数据库racdb的服务器池
[oracle@racdb01 ~]$ srvctl modify database -d racdb -g mypool
C，检查RAC数据库racdb新的Policy
[grid@racdb02 ~]$ srvctl config database -d racdb
Database unique name: racdb
Database name: racdb
Oracle home: /app/product/oracle/11.2.0.4/db_1
Oracle user: oracle
Spfile: /app/product/oracle/11.2.0/db_1/dbs/spfileracdb1.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: mypool
Database instances:
Disk Groups: ASM_DATA,ASM_FRA
Mount point paths:
Services: rac_first,rac_second
Type: RAC
Database is policy managed
发现数据库已经使用Policy Managed 选项了。
特别提醒：
如果没有特别强烈需要就不用自定义加 Policy Managed ，Admin Managed 能兼容11g RAC 和之前的版本，更通用。
D，使用crsctl检查服务器池的状态
已变更为
[grid@racdb02 ~]$ crsctl status serverpool -p
NAME=Free
IMPORTANCE=0
MIN_SIZE=0
MAX_SIZE=-1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r-x
NAME=Generic
IMPORTANCE=0
MIN_SIZE=0
MAX_SIZE=-1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:grid:r-x,pgrp:oinstall:r-x,other::r-x
NAME=ora.mypool
IMPORTANCE=0
MIN_SIZE=0
MAX_SIZE=2
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r—
E，使用srvctl检查服务器池的状态
[grid@racdb01 ~]$ srvctl config serverpool -g Free
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Candidate server names:
[grid@racdb01 ~]$ srvctl config serverpool -g Generic
PRKO-3160 : Server pool Generic is internally managed as part of administrator-managed database configuration and therefore cannot be queried directly via srvpool object.
[grid@racdb01 ~]$ srvctl config serverpool -g mypool
Server pool name: mypool
Importance: 0, Min: 0, Max: 2
Candidate server names:
注意:MIN_SIZE属性指定资源的基数(数据库等)，假设min_size为2，数据库实例可以运行在服务器池的两台服务器上。
另一个重要的注意事项：使用crsctl添加服务器池到集群(警告：使用crsctl添加服务器池将对应用服务器等非数据库资源效力，对数据库资源，需使用srvctl创建服务器池，请参考文档 here)
F，添加服务器池
For non-database resources,
[grid@racdb02 ~]$ crsctl add serverpool sp1 -attr "MIN_SIZE=1, MAX_SIZE=1, IMPORTANCE=1" -f
CRS-2673: Attempting to stop 'ora.racdb.db' on 'racdb01'
CRS-2677: Stop of 'ora.racdb.db' on 'racdb01' succeeded
检查服务器池状态
[grid@racdb02 ~]$ crsctl status serverpool -p
NAME=Free
IMPORTANCE=0
MIN_SIZE=0
MAX_SIZE=-1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r-x
NAME=Generic
IMPORTANCE=0
MIN_SIZE=0
MAX_SIZE=-1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:grid:r-x,pgrp:oinstall:r-x,other::r-x
NAME=ora.mypool
IMPORTANCE=0
MIN_SIZE=0
MAX_SIZE=2
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
NAME=sp1
IMPORTANCE=1
MIN_SIZE=1
MAX_SIZE=1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r—
删除服务器池：
[grid@racdb02 ~]$ crsctl delete serverpool sp1
[grid@racdb02 ~]$ crsctl add serverpool sp2 -attr "MIN_SIZE=1, MAX_SIZE=1, IMPORTANCE=2"
删除服务器池：
注意：观察差异，当使用crsctl时，你不能指定个别的或你希望的主机，而当使用srvctl时可以。
G，查看服务器状态
[grid@racdb01 ~]$ crsctl status server -f
NAME=racdb01
STATE=ONLINE
ACTIVE_POOLS=Generic ora.racdb ora.racdb_rac_first
STATE_DETAILS=
NAME=racdb02
STATE=VISIBLE
ACTIVE_POOLS=Generic ora.racdb ora.racdb_rac_second
STATE_DETAILS=
转换Policy-Managed Database为Administrator-Managed Database
A，检查所有服务和数据库的当前配置(如果犯错需要恢复，那么你可以知道当你开始时配置如何)，如下:
[oracle@racdb01 ~]$ srvctl config database -d racdb
Database unique name: racdb
Database name: racdb
Oracle home: /app/product/oracle/11.2.0.4/db_1
Oracle user: oracle
Spfile: /app/product/oracle/11.2.0/db_1/dbs/spfileracdb1.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: mypool
Database instances:
Disk Groups: ASM_DATA,ASM_FRA
Mount point paths:
Services: rac_first,rac_second
Type: RAC
Database is policy managed
文档说：
你不能直接转换a policy-managed database为administrator-managed database。而是，你可以使用srvctl remove database和srvctl remove service 命令删除policy-managed配置，然后使用srvctl add database和srvctl add instance命令注册该数据库为一个administrator-managed database。一旦你注册了数据库和实例，必需使用srvctl add service 命令添加回服务。
1.使用SRVCTL工具删除数据库
[oracle@racdb01 ~]$ srvctl remove database -d racdb
PRKO-3141 : Database racdb could not be removed because it was running
如果数据库正在运行可以使用-f(force)删除正在运行的数据库。但是不推荐使用该方式。
停止数据库并删除
[oracle@racdb01 ~]$ srvctl remove database -d racdb
PRKO-3141 : Database racdb could not be removed because it was running
[oracle@racdb01 ~]$ srvctl stop database -d racdb
[oracle@racdb01 ~]$ srvctl status database -d racdb
Instance racdb_1 is not running on node racdb01
Instance racdb2 is not running on node racdb02
[oracle@racdb01 ~]$ srvctl remove database -d racdb
Remove the database racdb? (y/[n]) y
[oracle@racdb01 ~]$ srvctl status database -d racdb
PRCD-1120 : The resource for database racdb could not be found.
PRCR-1001 : Resource ora.racdb.db does not exist
2.添加administrator-managed数据库
[oracle@racdb01 ~]$ srvctl add database -d racdb -o /app/product/oracle/11.2.0.4/db_1 -y automatic
[oracle@racdb01 ~]$ srvctl config database -d racdb
Database unique name: racdb
Database name:
Oracle home: /app/product/oracle/11.2.0.4/db_1
Oracle user: oracle
Spfile:
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: racdb
Database instances:
Disk Groups:
Mount point paths:
Services:
Type: RAC
Database is administrator managed
3.添加数据库实例
[oracle@racdb01 ~]$ srvctl add instance -d racdb -i racdb1 -n racdb01
[oracle@racdb01 ~]$ srvctl add instance -d racdb -i racdb2 -n racdb02
[oracle@racdb01 ~]$ srvctl start database -d racdb
[oracle@racdb01 ~]$ srvctl status database -d racdb
Instance racdb1 is running on node racdb01
Instance racdb2 is running on node racdb02
[oracle@racdb01 ~]$ srvctl config database -d racdb
Database unique name: racdb
Database name:
Oracle home: /app/product/oracle/11.2.0.4/db_1
Oracle user: oracle
Spfile:
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: racdb
Database instances: racdb1,racdb2
Disk Groups: ASM_DATA,ASM_FRA
Mount point paths:
Services:
Type: RAC
Database is administrator managed
如果有非默认service需使用srvctl add service 命令添加回服务
4.你必需在最后一步配置Oracle Enterprise Manager
参考至：http://blog.itpub.net/14359/viewspace-1271366/
转载Oracle 11g RAC使用Manual和Policy Managed方法配置 - CzmMiao的博客生活 - ITeye博客
Policy-Managed Cluster在Oracle 11gR2中被引进，在Oracle 12c中使用dbca创建RAC数据库的时候，Policy-Managed选项已然成为默认值。
那么到底什么是Policy-Managed方式的集群和数据库呢？与以前的Admin-Managed方式有何区别？何种环境适合使用这种新的方式进行管理？本文尝试回答这些问题，并且做出简单的测试。
什么是POLICY-MANAGED方式？
基于策略的管理方式，是以服务器池（Server Pools）为基础的，简单地说，就是先定义一些服务器池，池中包含一定量的服务器，然后再定义一些策略，根据这些策略Oracle会自动决定让多少数据库实例运行在池中的几台机器上。数据库实例名后缀、数据库实例个数、所运行的主机，这些都是通过策略决定的，而不是数据库管理员事先定好的。
与ADMIN-MANAGED方式有何区别？
实际上上面的表述已经明确说明了，Policy-Managed和Admin-Managed方式的差别。让我们再回顾一下，在以往我们创建一个RAC数据库大概是怎样的方法，我们在dbca的界面中会选择要将数据库实例运行在整个集群中的几台机器上，或者是2台或者是3台，甚或是更多，但是只要在安装的时候选定几台机器，那么以后如果不做增减节点的操作，就始终会在这几台机器上运行。而且，通常会根据主机名称的排序自动将每台主机上的数据库实例依次命名为dbname1到dbnameN。这些在管理员安装完毕以后，都不会再自动变化，这就是Admin-Managed方式。
何种环境适合使用这种新的方式进行管理？
当管理大量的服务器集群，并且在这些集群中运行着多种不同重要程度，不同策略的RAC数据库时，为了简化管理，建议使用Policy-Managed方式，实际上Oracle也建议只有在超过3台的服务器的时候才使用Policy-Managed来管理整个数据库集群。想象一下使用Policy-Managed方式可以达到的效果：如果我们有10台服务器组成，根据不同的应用的重要性定义服务器池的关键程度，然后在其中某些机器意外停机的情况下，仍然可以自动地保持足够多的机器给重要的系统提供数据库服务，而将不关键的系统数据库服务器个数降低到最低限度。
那么POLICY-MANAGED方式到底长什么样？
在默认安装完Oracle 12c的RAC数据库之后，发现数据库实例始终只会启动在一个节点中。检查服务器池配置。
[oracle@dbserver2 ~]$ srvctl config srvpool Server pool name: Free Importance: 0, Min: 0, Max: -1 Category: Candidate server names: Server pool name: Generic Importance: 0, Min: 0, Max: -1 Category: Candidate server names: Server pool name: orcl_pool Importance: 0, Min: 0, Max: 1 Category: hub Candidate server names:
Free池和Generic池是默认存在的，orcl_pool池则是在dbca创建数据库的时候由我们自己定义的。其中Min: 0, Max: 1表示在这个池中最少允许有0台机器，最多允许有1台机器被使用。所以这也造成了使用这个服务器池的数据库实例始终只会启动在一个节点中，即使这在我们最初的定义中是一个RAC数据库。
当前的数据库实例启动在节点2中，比较一下节点1和节点2服务器使用情况的输出。
[grid@dbserver2 ~]$ crsctl status server dbserver1 -f NAME=dbserver1 MEMORY_SIZE=3954 CPU_COUNT=1 CPU_CLOCK_RATE=2 CPU_HYPERTHREADING=0 CPU_EQUIVALENCY=1000 DEPLOYMENT=other CONFIGURED_CSS_ROLE=hub RESOURCE_USE_ENABLED=1 SERVER_LABEL= PHYSICAL_HOSTNAME= STATE=ONLINE ACTIVE_POOLS=Free --此处显示未Free，表示节点1中不属于任何正在运行的服务器池资源。 STATE_DETAILS= ACTIVE_CSS_ROLE=hub [grid@dbserver2 ~]$ crsctl status server dbserver2 -f NAME=dbserver2 MEMORY_SIZE=3954 CPU_COUNT=1 CPU_CLOCK_RATE=2 CPU_HYPERTHREADING=0 CPU_EQUIVALENCY=1000 DEPLOYMENT=other CONFIGURED_CSS_ROLE=hub RESOURCE_USE_ENABLED=1 SERVER_LABEL= PHYSICAL_HOSTNAME= STATE=ONLINE ACTIVE_POOLS=ora.orcl_pool --此处显示节点2正运行在orcl_pool服务器池资源中。 STATE_DETAILS= ACTIVE_CSS_ROLE=hub
接下来需要修改一下配置，让RAC数据库以我们熟知的方式启动在多个节点上。 –修改orcl_pool池中最少运行一台机器，最多运行2台机器，
还记得我们前面说的关键程度吗？importance表示该池的关键程度，数字越大表示关键程度越高，越优先被考虑满足Min条件。
[oracle@dbserver2 ~]$ srvctl modify srvpool -serverpool orcl_pool -importance 5 -min 1 -max 2
–重新检查服务器池信息，可以看到已经修改成功，Min: 1, Max: 2
[oracle@dbserver2 ~]$ srvctl config srvpool Server pool name: Free Importance: 0, Min: 0, Max: -1 Category: Candidate server names: Server pool name: Generic Importance: 0, Min: 0, Max: -1 Category: Candidate server names: Server pool name: orcl_pool Importance: 5, Min: 1, Max: 2 Category: hub Candidate server names:
–查看当前服务器池的状态，可以看到orcl_pool池中激活的服务器包括了节点1和节点2两台机器。
[grid@dbserver1 ~]$ crsctl status serverpool NAME=Free ACTIVE_SERVERS= NAME=Generic ACTIVE_SERVERS= NAME=ora.orcl_pool ACTIVE_SERVERS=dbserver1 dbserver2
在修改完毕以后，节点1中的数据库实例就会自动启动，我们可以通过crsctl命令查看服务器的状态，其中STATE_DETAILS字段显示了正在启动资源，在正常启动完毕以后该字段会显示为空。
[grid@dbserver2 ~]$ crsctl status server dbserver1 -f NAME=dbserver1 MEMORY_SIZE=3954 CPU_COUNT=1 CPU_CLOCK_RATE=2 CPU_HYPERTHREADING=0 CPU_EQUIVALENCY=1000 DEPLOYMENT=other CONFIGURED_CSS_ROLE=hub RESOURCE_USE_ENABLED=1 SERVER_LABEL= PHYSICAL_HOSTNAME= STATE=ONLINE ACTIVE_POOLS=ora.orcl_pool STATE_DETAILS=STARTING RESOURCES ACTIVE_CSS_ROLE=hub
现在就出现了一个比较尴尬的情况（对于我们以前管理RAC的常识来说），由于dbserver1中的实例是后启动的，因此实例名后缀为2，而dbserver2中的实例名后缀是1，实际上，在Policy-Managed管理的RAC环境中，无需关注到底哪个实例启动在哪台机器上，我们需要的就是通过SCAN IP，通过Service名去访问数据库就好，而不需要通过实例名访问数据库。但是这里为了测试一下功能，还是决定1归1，2归2，我有说过我是完美主义者吗？
--先将dbserver1上的数据库服务资源reolocate到dbserver2中，这样实例2就运行回到了dbserver2中。 [grid@dbserver1 ~]$ crsctl relocate resource ora.orcl12c.db -s dbserver1 -n dbserver2 --再将dbserver1中的实例启动，因为实例2已经启动在dbserver2中，因此即使此时该实例是后启动的，但是仍然还是会命名为实例1。 [oracle@dbserver1 ~]$ srvctl start instance -db orcl12c -node dbserver1
最后将这个RAC数据库再改回到只会启动一个实例的默认状态。
[oracle@dbserver2 ~] srvctl modify srvpool -serverpool orcl_pool -min 0 -max 1
以后，无论是启动在哪台机器上，数据库的实例名永远会是dbname_1（注意，这里有一个下划线，这是Policy-Managed数据库实例的命名规则）。而我们访问数据库，则不应该指定实例名。比如：
sqlplus sys/passwd@db-cluster-scan:1521/orcl12c as sysdba
因为现在你已经无需关心到底实例是启动在哪台机器上了，后面是一个资源池，是不是有些熟悉这样的表述，是的，没错，Cloud! 我们也贴上了Cloud这个红到发紫的词，这就是Oracle私有云解决方案的构成组件之一。
