Oracle Policy-Managed Cluster – Growing for DBaaS
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…