文章摘要
24*7（有些叫法也为24*7*365）的高可用系统越来越多的受到广泛重视与应用，那是因为在实际环境中，不间断的系统代表的就是不间断的义务收入。但是
◆怎么样搭建与治理24*7的高可用环境？
◆各种各样的高可用环境之间到底有什么差别？
◆我们是否适合于哪种环境？
◆现在高可用环境的主要方式以及以后的发展趋势是什么？
这些话题，都是决策者与实施者都应当考虑的，也是本文所探讨的，我们需要搭建一个怎么样的高可用环境，才能真正做到最适合。
一、什么是高可用(High Availability)
在高可用的解释方面，有人给出了如下的诠释：
(1)系统失败或崩溃 (system faults and crashes)
(2)应用层或者中间层错误 (application and middleware failures)
(3)网络失败 (network failures)
(4)介质失败，一般指存放数据的媒体故障 (media failures)
(5)人为失误 (Human Error)
(6)容灾 (Disasters and extended outages)
(7)计划宕机与维护 (Planned downtime, maintenance and management tasks)
可见，高可用不仅仅包含了系统本身故障，应用层的错误，人为错误等等，还应当包括数据冗余、容灾以及计划的维护时间，也就是说，一个真正的高可用环境，不仅仅是能避免系统本身的问题，还应当能防止天灾人祸，以及有一个简单可靠的系统维护方法（如微码升级、软件升级等等计划停机维护）。
现在高可用的计算方法一般以年在线率来计算，如规定一年之中的可用环境要达到99.95%，那么24*365*(1-99.95%)=4.38小时（包括维护时间）。那么假定一个系统本身一年之中故障时间是1小时，但是计划维护时间却花了20小时，那么这个系统也不能算是一个满足设计要求的高可用环境。
现阶段使用环境中，基本没有真正的100%的在线环境，或者说，假如达到100%的在线能力，将花费非常多的代价，所以一般能达到99.95%以上的可用性的环境，一般都可以认为是高可用环境。
对于高可用性在线效率的计算，我们可以参考如下方法：
图1
在公司收益与投入成本计算方面取得一个平衡，则是我们所希望的在线效率，但是收益与成本的计算方法则是决策者与实施者需要着重考虑的问题了，也是我们下面希望能试图解释的问题。
二、Oracle高可用相关功能的产品概述
因为高可用的范围定义太广泛，本文我们只讨论与Oracle数据库有关系的高可用设计，如数据库主机的错误，数据所在的存储错误，介质损坏以及主机与数据的冗余保护等等，并不讨论应用层的设计，Oracle 提供支持high availability 相关产品主要有下面几种：
(1) Oracle Parallel Server(8i)/ Real Application Cluster(9i/10g)
(2) Oracle Standby Database(8i)/Oracle Data Guard(9i/10g)
(3) Oralce Advanced Replication(8i)/Oracle Stream(9i/10g)
(4) Oracle Server HA
(5) Other: Mv/RMAN/Oracle Log Miner/Oracle Flashback Query(9/10gi)
等等，还有其他很多小的功能，如在线表的重定义，新的安全审计功能等，也都是为在线系统而设计的，但是，我们这里主要只考虑构架方面的高可用设计，也就是与成本有关系的高可用设计，怎么样达到成本与收益的最大平衡。
所以，我们将主要讨论的是Oracle OPS/RAC、Standby/Ddata guard、Advanced Replocation/Stream以及与Oracle Server相关的OS HA（双机）。
1、OPS /RAC
OPS/RAC 最原始的设计初衷就是system/application high availability。与其他产品相比较： OPS/RAC 是多个服务器的cluster，组成具有更大计算处理能力与故障处理能力的集群。cluster 里面不同的 node 使用一个(一般是一个)或多个oracle instances 与一个database 连接（Shared Storage）。
主要的技术特点：
(1) database 所有的data files 是建立在共享存储（Shared Storage）上面的，一般可以采用raw设备，共享文件系统或者是ASM（10g提供），因此在技术方面对OS 的设置有很高的依靠性，需要有OS支持的cluster软件。
(2) OPS/RAC在共享存储方面并没有冗余保护，不具备在共享存储阵列损坏的情况下具有切换的能力，因此 media failure 方面，要依靠RAID (redundant array of ineXPensive disk) Subsystem、LV镜相(LV Mirror)、卷复制（Volume Replication）或者是Standby/Data guard来实现数据的冗余保护。
(3)该技术是Oracle近来主推的技术，非凡是10g以后的网格计算与线型扩展能力，在电信、移动、银行行业使用广泛。假如还是老的OPS，则不建议再使用，但是9i以后的Rac技术逐渐成熟，可以使用在高可用环境下，但是其治理成本与技术的复杂性，则也是需要考虑的。 2、Advanced Replication /Stream
Advanced Replication 的设计初是分散异地的application access database locally。这种技术可以将一个数据库中的objects复制到另一数据库中。假如是整个数据库的复制，也可用于高可用环境。
从Oracle 9i开始，Oracle更倾向使用Stream的技术，通过对归档日志的挖掘，可以在对主系统没有任何压力的情况下，实现对数据库的objects甚至整个数据库的同步。
主要的技术特点：
(1)技术相对灵活，可以对单独的object，或者是整个数据库进行复制，而且作为stream，复制的压力更小，对主库没有压力，闻名的复制软件share plex就是采用类似的技术进行数据的复制的。
(2)可以实现数据库主机以及共享存储的完全冗余保护，甚至是跨地域的容灾保护，在很多比较大型的在线系统中，可以用该技术实现系统的读写分离，通过该技术把写站点的数据复制到多个读站点，大大提高系统的可用性与安全性。
(3)因为Advanced Replication与Stream的不成熟性与技术复杂性，该技术没有被广泛的使用，但是其对应软件share plex使用还是瞒广泛的，不过因为其昂贵的价格，则是需要考虑其搭建成本的。
3、Standby/Data Guard
Standby database/Data guard是ORACLE推出的一种高可用性数据库方案，在主节点与备用节点间通过日志同步来保证数据的同步，备用节点作为主节点的备份，可以实现快速切换与灾难性恢复。
Oracle从7.3才开始支持standby database。在9i开始，发展为data guard，并支持MAXIMIZE PROTECTION、MAXIMIZE AVAILABILITY、MAXIMIZE PERFORMANCE的三种保护模式，可以实现自由的手工主备切换，实现高可用的条件，假如配置合理，可以实现部分的自动切换。
从Oracle 9i开始，也开始支持逻辑standby，逻辑standby的原理跟Stream复制相差不大，可以归结到Stream中。
主要的技术特点：
(1)可以实现数据库主机以及共享存储的完全冗余保护，该冗余甚至可以跨地域，做成容灾保护，另外，主节点必须运行在归档模式下，并且可能要force logging，保证备用节点的数据正确性。
(2)主备用节点对OS的环境要求比较高，必须要是相同的OS环境（相差一定的beta版本一般关系不大），而且数据库环境最好也一致。
(3)除了最大保护模式外，其它模式下假如主站点的存储损坏而导致备用站点进行失败切换的时候，需要注重数据的丢失问题，务必同步完主站点当前的联机日志。
(4)备用节点的主机与存储基本不能提供访问，仅仅能提供只读查询，所以该技术也有严重的资源浪费，不过该技术因为成本比较低，治理方便，技术成熟，所以被广泛使用。
4、OS相关HA
Oracle Server HA是基于OS的技术，采用OS支持的Cluster Soft来保证主机的冗余保护，跟Rac一样，不能保证共享存储的高可靠性。
它的基本架构共分两种模式：双机互备援（Dual Active）模式和双机热备份（Hot Standby）模式，对于Dual Active模式，双机都是正常工作的，但是工作业务不同，在一个主机故障时，切换到另外一个主机上；Hot Standby模式则只有一个机器工作，另外一个机器处于接管状态。
不管是哪种模式，Cluster都可以正确的检测到系统异常并自动进行失败切换，假如是Dual Active模式，则需要注重当两个业务都切换到一个server上的时候，该机器是否能承载双份的压力。
主要的技术特点：
(1)与Rac一样，database 所有的data files 是建立在共享存储上面的，存储的冗余保护则需要依靠其它技术。
(2)HA的技术简单成熟，所以在实际使用中，也能被广泛采用，但是，对主机资源的浪费也最为严重，基本上要保证有对等的资源处于等待状态。
三、Oracle高可用相关功能的具体说明
1、OPS/RAC
OPS/RAC通过两个或多个节点的cluster，多个节点之间，采用高速通信链路连接，来解决数据库的高可用性，在OPS/RAC中，每个节点都可以被应用端访问并可以自动负载平衡。
假如其中一个节点发生故障，所有的节点将自动切换到另外一个（或几个）节点上。可以实现动态应用的切换以及数据库服务器及时的失败处理，在server的高可用方面提供最高保护。
但是OPS/RAC并不对磁盘，阵列提供保护的特性，假如发生介质的物理损坏，将可能导致服务器的宕机。所以我们可以对OPS/RAC进行进一步的保护，如采用好的RAID方式(如RAID 10)，也可以在OS层面上对逻辑卷做镜相或者复制，甚至采用RAC+DATA GUARD双重保护。
Rac已经被广泛使用在高可用环境，但是，除了硬件成本，cluster软件成本，我们还需要考虑治理成本。
如以下的一个4节点的Rac结构中，4个节点可以同时被访问，假如其中一个出现故障，该节点上的应用将被自动切换到其它3个节点上，另外，通过SAN的存储网络，实现数据的冗余保护。
图2
2、Advanced Replication /Stream
Advanced Replication/Stream用于高可用，一般是指对数据库的整个复制，假如数据库在异地，也还可以用于容灾，所以，假如该技术用的好，是一个非常不错的选择。
图3
如上图的结构中，主站点可以在城东，被复制站点可以在城西或者更远的地方，数据通过城市网络传向被复制站点，在stream中，传送的可以是被分析过的LCR anydata数据结构，到目标数据库的时候再解析成对应的DML语句实现同步。
这样的话，主站点与被复制的站点可以分别的被应用访问，虽然被复制站点可能比主站点的数据要延迟一些。
正因为Advanced Replication/Stream既实现了高可用，又实现了容灾，在大型的在线电子商务网站中，一般使用成熟的share plex软件实现读写分离，读的站点可以分布在世界各地，既大大提高了网站系统的可用性，又大大提高了数据的安全性。
3、Standby/Data Guard
Standby/Data guard因为技术简单成熟，成本低廉（Oracle自带的功能，不需要单独购买），是广泛采用的一种数据库的高性能与容灾方案，假如采用不同保护级别可能会有不同的性能结果，如想不丢失数据，则可能会影响性能，假如想最好的性能，则一定注重保证在主节点完全故障的时候，备用节点不会丢失数据。
图4
备用数据库可以认为是一个主数据库的镜相，一个处于不断恢复日志中的主数据库。从9i开始，备用数据库又分为物理备用数据库与逻辑备用数据库，我们这里只讨论物理备用数据库。
Standby/Data guard实现了数据库的高可用以及数据的异地容灾，与Advanced Replication/Stream不一样的是，备用站点不能实时的被访问，降低了资源的利用程度，而且假如主站点故障，一般需要手工切换。
但是，正因为其方便的治理，成熟的技术，低廉的价格，所以也被广泛的使用在数据的容灾上面，假如与RAC结合，RAC+Data Guard可以实现一个良好的高可用，高性能的数据库。
4、OS相关HA
HA很类似于RAC，两种方式，都需要两个Server，一个闲置。 在主机crash 的情况下，都可以提供某种程度的恢复，保持系统可用。 不过一个是OS Vendor的solution,一个是Oracle的solution，如，在一个 一备三 的系统结构中：
图5
在以上的结构中，正在被使用的数据库服务器有3台，其中3台中任何一台发生故障，可以被一台备用主机接管，等待发生故障的机器修复，再手工切换会原来的结构。
HA的最好好处就是可以解决服务器的单点故障的问题，如机器故障，与Rac一样，并不能解决磁盘故障问题或者是阵列故障问题。所以HA也必须采用附加的备份机制如LV镜相与卷复制，或配套使用oracle standby。
HA的机制起源比较早，发展到现在已经日趋成熟，在实际安例中，使用还是比较广泛的，但是它必须有一半的资源处于等待状态，所以资源浪费跟standby一样，比较严重。
四、Oracle高可用相关功能的对比说明与方案选择
通过以上的具体说明，我们描绘了Oracle数据库在高可用性方面可以达到的效果以及特性，并且从原理上与构架上，我们也可以分析到其成本（包括治理成本），再加上其技术的成熟程度以及使用程度，我们以一张表格来对照一下：
图六
注①：这里指单独的使用该功能，但是假如与LV Mirror/ Volume Replication/Data guard等功能结合起来，是可以实现数据保护与容灾功能的，假如设计合理，在灾难切换时，也可以保证不丢失任何数据，但是也需要为以上功能付出更多的成本。
②：对于Advanced Replication /Stream，现阶段的确不太成熟，还没有广泛的使用起来，但是类似这样功能的软件，如Share plex已经比较成熟了，在全球范围内还是被广泛验证过了的。
③：在一定条件下，可以配置成自动切换。
④：假如主站点完全故障，可能会导致数据丢失（主要是当前联机日志），不过可以考虑把当前联机日志分布到各地地点的方法避免该问题的出现。
⑤：假如在非最大保护模式下，与④有相同的结果与预防处理方式。
我们通过该表格的对比可以发现，没有最好，只有看我们自己的最适合了，每一种方式都有自己的缺陷有优点。而且，在实际的使用中，真正的高可用环境也很少单独来使用这些技术的，一般都是结合来使用，如：
1、有的电子商务使用Rac + Share plex (或Stream)的技术实现读写分离的技术，可以实现高可用+容灾。
2、有的电信行业用远程Rac +远程 LV Mirror，可以实现本地与远程应用的动态切换，实现主机的异地冗余保护与数据的异地容灾
3、有的电子商务采用本地HA+远程Standby，实现数据库服务器与存储的双重冗余，分别实现不同级别的主机冗余与数据的异地容灾。
4、有的银行行业采用本地Rac+ 远程vvr（Veritas Volume Replication），实现本地系统的主机冗余与远程系统数据的异地容灾。
总结
该文具体描叙了oracle在高可用环境中可能用到的技术，以及该技术的具体描述，并且通过其构架分析，原理了解，技术成熟度分析，我们可以大致估算到其成本。
而且，在实际的使用环境中，没有最好的技术，只有最适合于自己的技术，使自己的成本与收益能达到一个最合适的平衡，这个，就是我们最终需要达到的目的。
以上的技术与方案，仅供参考。
