沃趣科技高级数据库专家 魏兴华

RAC One Node

根据整合的数据库的SLA要求，还需要决定整合数据库所选用的数据库类型，在数据库的类型上，11GR2版本之前，要不是单实例要不是RAC，单实例不具有HA的功能，只能做冷的HA，通过使用类似HACMP之类的软件进行切换，有不可用时间，而且由于引入了第三方的HA软件，让整个架构、运维变得复杂，如果使用RAC架构，那么对于数据库整合来说，显得有点资源浪费，RAC要求至少是双节点，对于整合的数据库来说，一般都是非核心库，往往压力不大，对于高可用的需求也没有那么高，因此使用RAC显得有点浪费，那么有没有一种折中的方案呢？既然Oracle的ClusterWare一个很重要的功能就是为其上的资源提供监控、故障处理、故障切换服务，为什么不能在ClusterWare之上跑单节点的RAC，然后在发生故障后对资源进行尝试重启，如果重启不成功，在另外的节点再进行实例的拉起。RAC One Node就是这样一种技术，顾名思义，RAC One Node是单节点的RAC，它跑在GI之上，通过GI基础组件实现HA，借助于GI集群件，RAC One Node作为其上的资源在发生故障后，可以尝试进行重启或切换，这一切都会自动完成，而不需要人工干预。RAC One Node除了能做故障切换外，还可以实现有计划性的在线漂移。漂移过程中，会阶段性的存在2个实例，等旧实例上的事务都完成后会被关闭，然后新实例对外提供服务。客官可能会问，在线迁移有啥用？做了数据库的整合后，一台机器上可能跑的就是多个数据库实例了，如果发现某些机器上的负载比较高，那么就可以使用RAC One Node的在线迁移功能，把负载较高的主机上的一些实例在线的迁移到其他负载低的机器上。仔细想想，Oracle能做到这一点还挺不容易的，因为里面涉及到了一些技术细节，只是你还没认识到。11GR2之前，增加实例是一个复杂的过程：

在线漂移

数据库一旦做了整合，一个主机之上就可能会有多个实例，实例之间可能会互相影响性能，如果DBA发现某台主机上的负载较高，或者由于其他原因需要对RAC One Node进行节点迁移，就可以使用RAC One Node的在线漂移功能，DBA通过命令人为的把数据库实例迁移到其他机器上运行，在迁移过中，RAC One Node会等待旧的实例上的事务完成，同时在目标机器上启动一个新实例，在迁移这段时间内，会有两个实例以active-active双活的模式运行，当旧实例上的事务都完成后，这些连接会被转移到新的实例上来，一旦所有的连接转移工作都完成后，旧实例会被关闭，整个转移过程也完成了。

RAC One Node的在线漂移时间窗口默认为30分钟，在这段时间内，Oracle会等待旧实例上的事务完成，如果超过这个时间窗口后，还有事务未完成，那么会被强制取消，实例也会被强制关闭，可以通过srvctl命令增加-w参数来增加或减少这个默认的时间窗口。

漂移的命令是通过srvctl来完成的，具体用法如下：

srvctl relocate database -d

{[-n ] [-w ]|-a [-r]} [-v]

其中的参数机器说明如下

●    -d：数据库的名称

●    -n：目标节点

●    -w：等待旧实例事务完成的时间窗口

●    -a：放弃失败的在线漂移

下面给出一个在线漂移的例子，让读者更为直观的感受一下在线漂移的过程。本例中会把oltp8从节点RAC2迁移到目标节点RAC1.首先观察一下数据库的当前状态是否正常

srvctl status database -d oltp8

Instance oltp8_1 is running on node rac2Online relocation: INACTIVE

oltp8为RAC One Node只有一个实例oltp8_1，当前运行在节点RAC2上，在线漂移的状态为INACTIVE。接下来我们对RAC One Node进行在线漂移，这是通过srvctl的relocate语法来完成的

srvctl relocate database -d oltp8 -n rac1 -w 5

漂移过程中，另开一个会话观察漂移的状态

srvctl status database -d oltp8

Instance oltp8_1 is running on node rac2Online relocation: ACTIVESource instance: oltp8_1 on rac2Destination instance: oltp8_2 on rac1

输出的信息非常的详细，oltp8_1这个实例正运行在RAC2上，ACTIVE关键字说明在线漂移也正在进行中，漂移的源端为RAC2，目标端为RAC1，并且目标端的实例名发生了变化：oltp8_2。

漂移完成后再查看状态，在线漂移状态已经为INACTIVE，实例oltp8_2也已经运行在新的节点上了

srvctl status database -d oltp8

Instance oltp8_2 is running on node rac1Online relocation: INACTIVE

这里补充一个小细节，上面我已经提到过，这种在线漂移实例名是会发生变化，其实内部的操作就是在另外的节点帮我们自动的增加了一个实例，手工增加过实例的朋友都知道增加实例一般需要增加redo thread,增加undo表空间，那我们来看看，Oracle自动帮我们增加的实例有没有帮我们来搞定这些事

                  

TABLESPACE_NAME     TOTAL_MBYTES  USED_MBYTES  FREE_MBYTES     PCT_FREE------------------- ------------ ------------ ------------ ------------SYSAUX                   1080.00      1021.69        58.31         5.39UNDOTBS1               145.00        31.25       113.75        78.44USERS                     5.00         1.69         3.31        66.25SYSTEM                   810.00       802.81         7.19          .88UNDOTBS2               25.00         2.44        22.56        90.25WXH                        10.00         1.00         9.00        90.00                    ------------ ------------ ------------                         2075.00      1860.88       214.13

上面的内容显示，有2个undo表空间，undotbs1 是之前oltp8_1实例用的，而undotbs2是新增加的。不过遗憾的是，这个undo表空间比较小，一般难以满足我们的要求。这里告诉大家一个小技巧，可以创建完RAC One Node后，手工增加undo表空间和redo thread，Oracle非常的智能，下次做实例漂移，它会自动使用上你手工创建的这些redo thread和undo表空间了，而且大小也都符合你的要求。

SQL>select group#,thread# from v$Log;

    GROUP#    THREAD#---------- ----------     1      1     2      1     3      2     4      2SQL>select group#,member  from v$Logfile;    GROUP# MEMBER---------- -----------------------------------------------     2 +OCRVOTE/OLTP8/ONLINELOG/group_2.265.907239997     1 +OCRVOTE/OLTP8/ONLINELOG/group_1.256.907239995     3 +OCRVOTE/OLTP8/ONLINELOG/group_3.264.907240291     4 +OCRVOTE/OLTP8/ONLINELOG/group_4.263.907240291

同样,redo thread也都帮我们创建好了，包括对应的日志文件。

故障切换

RAC One Node不但可以做有计划性的在线漂移，同时对于主机等故障发生后，通过GI的HA组件把失败主机上的实例迁移到其他节点，不过这种迁移有不可用时间。 下面我们通过杀死CRS进程的方式，模拟主机故障，来观察RAC One Node的故障切换。

oltp8正在运行的节点1上，在节点1上杀掉CRS进程

ps -elf | egrep "d.bin|ohas|oraagent|orarootagent|cssdagent|\

cssdmonitor" | grep -v grep |awk '{print $4}' |xargs -n 10  kill -9

在RAC2节点上观察数据库的状态，实例已经为not running状态。

>srvctl status database -d oltp8

Database is not running.Online relocation: INACTIVE

通过crsctl stat命令查看故障切换是否已经发生

>crsctl stat res -t

-------------------------------------------------------------------Name           Target  State        Server      State details-------------------------------------------------------------------Local Resources-------------------------------------------------------------------ora.DATADG.dg               ONLINE  ONLINE       rac2        STABLE               ONLINE  ONLINE       rac3        STABLE               ONLINE  ONLINE       rac4        STABLE-------------------------------------------------------------------Cluster Resources-------------------------------------------------------------------ora.LISTENER_SCAN1.lsnr      1        ONLINE  ONLINE       rac4        STABLEora.MGMTLSNR      1        ONLINE  ONLINE       rac2        169.254.198.57 192.1                                                68.100.2,STABLEora.cvu      1        ONLINE  ONLINE       rac2        STABLEora.oltp8.db      2        ONLINE  OFFLINE      rac2        STARTING-------------------------------------------------------------------

从crsctl stat res -t的输出可以清楚看到，集群正在RAC2节点上尝试拉起实例。过2分钟再次查看，数据库已经完成故障切换，整个过程不到五分钟，非常的棒！

>crsctl stat res -t

---------------------------------------------------------------------Name           Target  State        Server        State details---------------------------------------------------------------------Local Resources---------------------------------------------------------------------ora.DATADG.dg               ONLINE  ONLINE       rac2          STABLE               ONLINE  ONLINE       rac3          STABLE               ONLINE  ONLINE       rac4          STABLE---------------------------------------------------------------------Cluster Resources---------------------------------------------------------------------ora.oltp8.db      2        ONLINE  ONLINE       rac2          Open,STABLE---------------------------------------------------------------------

虽然RAC One Node的HA是Cold Failover的，但是对于一些边缘、测试、开发环境，对于可用性要求不是那么高的环境，它都是一种非常好的整合方案。试想，有几个客户会把自己最为核心的数据库来进行整合呢？

RAC One Node扩展性

RAC和RAC One Node之间可以通过srvctl命令轻松的做转换，我们以把RAC One Node扩展成多个节点的RAC。这里给出转换的示例：

查看当前RAC One Node的运行状态

srvctl status database -d oltp8

Instance oltp8_1 is running on node rac2Online relocation: INACTIVE

运行在RAC2节点上，运行状态正常。

使用srvctl convert命令进行转换，-c参数代表了要把RAC One Node扩展成标准的RAC。

srvctl convert database -d oltp8 -c RAC

转换完成后，查看数据库的实例状态

srvctl status database -d oltp8

Instance oltp8_1 is running on node rac1Instance oltp8_2 is running on node rac2

非常好，Oracle帮我们自动增加了实例，而且增加的实例已经启动。需要注意，笔者的测试环境为12C，如果为11GR2，增加的实例需要DBA手工去启动。

就这样轻松的完成了RAC One Node到RAC的转化。

同样我们看如何来“缩”，把RAC 转化为RAC One Node，同样通过srvctl 命令来完成，-c参数代表了把RAC“收缩”为RAC One Node.

srvctl convert database -d oltp8 -c raconenode

PRCD-1154 : Failed to convert the configuration of cluster database oltp8 into its equivalent RAC One Node database configuration because cluster database is running on more than one server [rac1, rac2]

提示有2个实例在运行，看来需要关闭一个实例才能进行RAC到RAC One Node的转化

srvctl stop instance -d oltp8 -i oltp8_1 -f

srvctl convert database -d oltp8 -c raconenode

转换完成后，再次查看数据库实例的状态

srvctl status database -d oltp8

Instance oltp8_2 is running on node rac2Online relocation: INACTIVE

oltp8已经只有一个实例在运行了。

从上面的实验过程中可以看出，RAC One Node具有非常好的可用性、伸缩性，而且这一切的操作都非常的简便。

到这里你已经对RAC One Node有了一定了解，由于是以单实例的状态运行，而且还具有非常高的可用性，那么用来做数据库的整合太合适了，整合的密度可以很大，适用于那些对于可用性要求没有那么的高的开发、测试、QA、边缘系统。

12C CDB

12C出现了容器数据库CDB，虚拟化整合方案共享了宿主机，多实例整合方案共享了宿主机和OS，而12C的容器数据库共享了宿主机、OS和实例，共享的层次越多，内耗越少，性能越高，整合的密度就可以越大，但隔离性上会弱一些，一旦实例层面出现问题，所有的PDB都会出问题。Oracle通过在12C增强了Resource Manager的功能来进一步提供PDB之间的资源隔离实现。由于PDB的创建可以基于模板和克隆，因此资源供应速度上得到了很大的提升。12CR1版本，一个容器数据库最多支持252个PDB,到了12CR2版本已经增强到4096个。笔者所在公司-沃趣科技也一直在研发12C的相关数据库平台和产品，就我们的使用测试情况来看，12CR1版本的BUG还比较多，有些BUG在MOS上还没有记录，因此建议不要着急上12C，等12CR2发布后再做决定。

资源快速供应

资源快速供应是DBaaS出现之后延伸出来的一个概念，意在用户通过自服务的方式去快速的获取资源。以前数据库简直就是世界的中心，想申请一个数据库资源从项目的立项到最终获得资源，要经过相对漫长的时间，所有人都要围着它转，而DBaaS做为一个大的数据库平台，有着“无限”大的可用性能、可用容量，因此只需要用户在云平台之上点点鼠标，就能完成资源的获取，Oracle 12C出现的容器数据库让资源的获取更加的快速和便捷，它本身通过数据库的模板来快速提供PDB。要实现资源的快速供应，你需要：

●  有一个强大的硬件平台，比如一体机产品

●  有一个云平台，开发、测试、QA可以便捷的在云平台之上完成资源的申请和获取

●  决定使用何种技术提供资源，PDB？SCHEMA？DB？

目前我们沃趣科技也是在研发DBaaS云平台产品DBPool，在其上可以方便的完成资源的申请、获取、使用、下线，资源的整个生命周期都可以在平台之上完成，可以极大提升获取资源的敏捷性，为企业的数据库提供一个标准化的操作平台。

服务质量管理QoS

数据库做了整合之后，面临着几个问题

●  资源隔离如何做，如果不做资源隔离，就难以保证数据库对外的服务质量，实例之间、PDB之间会互相影响

●   可不可以对资源进行灵活的调配，以满足不同业务，不同时间段的对资源的需求情况

CPU资源隔离技术Instance Caging

Alt text

我们首先来看第一个问题，资源隔离如何做，如果资源是无限的，就不需要对他们进行管理，资源隔离是DBaaS里一个非常重要的概念，也是每一个DBaaS平台都需要去解决的核心问题。

以前使用Oracle的方式大多都是一台机器跑一个实例，但是数据库一旦进行整合，一台机器可能就不是跑一个实例了，而是多个实例，实例一多，一个现实的问题摆在面前：资源隔离如何做？

为了保证每个数据库实例的服务质量，你需要提前对每个实例分配资源，在它的整个活跃周期内都不能跑出给它分配的数据库资源。如果资源不加以不加限制，就可能出现这样的情况：一个优先级非常低的业务由于应用程序BUG进而导致侵占了主机上的绝大部分CPU资源，最终导致主机上其他重要度高的应用受到非常大的影响，业务被降级。如下图：

Instance Caging就是这样的技术，用于CPU资源的管控，它能够管理CPU在实例间的分布，确保每个实例可以使用的CPU资源不跑出它的一亩三分地。

Instance Caging相对于其他资源管理的技术，例如操作系统的Cgroup，它具有一些天然的优势

●  Instance Caging是11GR2自带的功能，不需要额外安装软件

● 它是免费的，不需要支付额外的licence费用

● 由于是自带的功能，因此它能与Oracle数据库库高度的集成，可以感知到数据库内部的负载

● 最为重要的一点，它的使用特别的简便，请看下一节

12C版本可以利用数据库的参数processor_group_name结合LINUX Cgroup来一起使用，这部分内容本文不做详细介绍。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28218939/viewspace-2107530/，如需转载，请注明出处，否则将追究法律责任。