1.1.2  Policy-Managed方式介绍

Policy-Managed Cluster在Oracle 11gR2中被引入，在12c中使用DBCA创建RAC DB时，Policy-Managed选项已经是默认值(12c之前版本默认都是Admin-Managed)。

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.
 
         基于Policy的管理方式，是以服务器池（Server Pools）为基础的，简单地说，就是先定义一些服务器池，池中有一定量的服务器，然后再定义一些策略，根据这些策略Oracle会自动决定让多少数据库实例运行在池中的哪几台机器上。数据库实例个数、所运行的主机，这些都是通过策略决定的，而不是数据库管理员事先定好的。也就是不存在还需要管理员去选择节点的动作，都是系统在池子中自动分配 。 


          在DBCA的Database Identification步骤中，Configuration Type选择Policy-Managed，输入global database name及service name，然后是为这个数据库创建新的server pool，其中有对server pool的解释：server pool is a group of servers that collectively work together to host database workload ，输入Server Pool Name, 以及Cardinality (基数：主机台数)，或者也可选择已经存在的Server Pool，这种情况下，active的实例在哪台主机上，是否还遵循在local node上的原则，还需验证 。 Server Pool中已知的一些原则是：一台主机只能属于一个server pool，一个server pool中可以创建多个数据库。 

Server Pool建好了，那么策略呢 ？  

          Server Pool逻辑上分配一个cluster到多个组(servers组成)来提供数据库或应用服务。它的属性控制着这些数据库或应用的scalability(扩展性)及availability(可用性)，你可以配置每个server pool的max size及min size, 这个属性决定pool的扩展性；Oracle Clusterware在server pools之间管理可用性， 还可以在server pool中通过设置importance value(重要性)来管理availability 。 

        当管理大量的服务器集群，并且在这些集群中运行着多种不同重要程度，不同策略的RAC数据库时，为了简化管理，建议使用Policy-Managed方式，实际上Oracle也建议只有在超过3台的服务器的时候才使用Policy-Managed来管理整个数据库集群。想象一下使用Policy-Managed方式可以达到的效果：如果我们有10台服务器组成，根据不同的应用的重要性定义服务器池的关键程度，然后在其中某些机器意外停机的情况下，仍然可以自动地保持足够多的机器给重要的系统提供数据库服务，而将不关键的系统数据库服务器个数降低到最低限度。 策略管理：DBA指定数据库资源运行在哪个服务器池(排除generic or free)。Oracle Clusterware负责将数据库资源放在一台服务器。

Oralce Clusterware使用服务器池的重要性决定分配服务器次序：
按重要性次序分配服务器给所有服务器池，直到满足服务器池的最小数目要求
按重要性次序分配服务器给服务器池，直到它们满足服务器池的最大数目要求
默认，任何剩下的服务器加入FREE服务器池
策略管理数据库背后的目标是删除到1个特定实例或服务 服务的硬编码
数据库可以和1个服务器池关联(而不是特定的节点集)。服务器池决定被资源(数据库，服务，第三方应用程序)所需的最小和最大服务器数目。
数据库实例将运行在已被分配给服务器池的服务器上。(使用min_size决定数据库必需运行在哪些服务器，以及必需运行在多少服务器上)
既然被分配给服务器池的服务器可以动态地变更，这允许Oracle基于集群可用的服务器总数动态地交付服务。
数据库实例将启动在足够多的服务器上(受制于服务器的可用性)。无需硬编码规定数据库实例运行在哪些服务器上。
数据库的任何实例可以运行在任何节点上。在实例号和节点之间无固定的映射关系。
当服务器被释放/添加/删除时，他们按之前提及的规则被分配到存在的服务器池中。

例子： 
如果1个集群，由8个节点组成，支撑3个RAC数据库。每个数据库将定义服务器的最小和最大数目(注意只是定义个数，而不是指定服务器名)。
假设数据库ERP定义最小4台、最多6台服务器(重要性为10)，
假设数据库WMS定义最小2台、最多3台服务器(重要性为7)，
假设数据库HRMS定义最小2台、最多3台服务器(重要性为5)。
初始8节点将被配置成节点1~4被分配给数据库ERP，节点5~6被分配给数据库WMS，节点7~8被分配给数据库HRMS。如果服务器节点3由于某种原因发生故障，系统将分配节点7或8给ERP，因为ERP比HRMS有更高的重要性且最小需要4台服务器，即使将导致HRMS降到最小服务器水平以下(1个节点)，也必须先满足ERP的需求。如果节点3被重新激活，将被立即分配给HRMS以使数据库恢复到最小所需的服务器数(2个)。  如果第9个服务器节点被添加到集群，将被分配给ERP，因为其重要性最高而且未满足最大服务器数(6个)。

备注： 如果没有特别需要就不用Policy-Managed ，Admin-Managed 能兼容11g RAC 和之前的版本，相对更通用。普通RAC，RAC One Node都可以选择以上两种不同类型的Server Pool, Single Instance没有这种选项。