1.2.1 什么是高可用
高可用(HA)有两种不同的含义,在广义环境中,是指整个系统的高可用(High Availability)性,在狭义方面,一般指主机的冗余接管,如主机HA,如果不特殊说明,本书中的HA都指广义的高可用性。在高可用的解释方面,可以分为如下一些方面:
(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)
可见,高可用不仅仅包含了系统本身故障、应用层的错误、网络错误、人为错误等,还应当包括数据冗余、容灾及计划的维护时间,也就是说,一个真正的高可用环境,不仅仅能避免系统本身的问题,还应当能防止天灾人祸,并且有一个简单可靠的系统维护方法如微码升级、软件升级等计划停机维护。
本书定位在Oracle数据库层面上的高可用性,同时也会介绍一些如主机、存储、操作系统、分级存储、容灾方面的高可用性与业务连续性保证。除了应用层及中间层的高可用性仅仅是在本章后面有一定的描述以外,其他部分在本书其他章节都有一定的介绍。
高可用的计算方法一般以年在线率来计算,如规定整个系统一年之中的可用环境要达到99.95%,那么24*365*(1-99.95%)=4.38小时(包括计划内维护时间)。另外,子系统的可用性一定会高于整个系统的可用性,如承接前面规定整个系统的可用率为99.95%,那么对于数据库子系统,可用性很可能就是要求达到99.99%。高可用性的在线率(可用级别)与停机时间可以参考如图1-11所示的对照表:

图1-11 高可用级别对照表
基于以上的规定,假定一个系统一年之中故障时间是1小时(差不多99.99%),但是计划内维护时间却花了20小时,那么这个系统也不能算是一个满足设计要求的高可用环境。
现阶段使用环境中,基本没有真正的100%的在线环境,或者说,如果达到100%的在线能力,要付出非常大的代价,所以一般能达到99.9%以上的可用性的环境,一般都可以认为是比较高的可用环境了。
对于高可用性在线效率的计算,可以参考如图1-12所示的方法:

图1-12 收益与成本
在公司收益与投入成本计算方面取得一个平衡,则是最终所希望的在线效率,但是收益与成本的计算方法则是决策者与实施者需要着重考虑的问题了。本书的很多地方,其实也希望能提供一种思想,那就是怎样搭建最适合自己的高可用环境,而不是盲目地去追逐最高可用性。
1.2.2 Oracle最高可用性体系结构(MAA)
随着Oracle 9i/10g/11g的更多高可用特性的出现,Oracle也推出了它自己的高可用概念,那就是Oracle 最高可用性体系结构(Oracle Maximum Availability Architecture,MAA)。它是Oracle提供的全套的高可用解决方案,由Oracle已经在使用的高可用特性组成,目标是消除设计最优高可用性体系结构时的复杂性。
Oracle 的MAA从非计划宕机到计划内的停机维护说明了高可用的保证,在MAA体系结构中,可以分为如下4个部分。
u 非计划宕机
l 系统失败:RAC
l 数据异常:Data guard、ASM、Flashback、Rman、Streams
u 计划内停机
l 系统改变:在线修改配置,在线滚动补丁升级
l 数据变化:在线重定义
以上内容在本书都会有详细的描述,如第4章将专门介绍RAC与ASM;第5章专门介绍Data guard;第6章专门介绍Streams;第8章介绍了Flashback;第九章介绍了RMAN。
至于计划内停机的一些可用性,可以从如下几个方面考虑:
l 在线修改配置的特性,如ASM动态增加移动硬盘,Oracle内存或SGA的在线调整,RAC动态增加与删除节点。
l 在线滚动补丁升级的特性,如RAC环境的滚动升级,Data guard环境的滚动升级。
l 在线重定义特性,如在线重定义表,在线rebuild索引等等。
以上的这些特性,在本书不同的地方也有详细的描述。
因为本书不仅仅是基于Oracle本身的高可用特性,也包括Oracle数据库的辅助环境的高可用性,所以介绍的范围会更广泛,将包含存储、主机等很多辅助环境。
不过,Oracle推出MAA计划,也表示了它对高可用性方面的重视,特别是从Oracle 9i/10g/11g看来,很多特性都是为高可用性准备的。可以这么说,Oracle 8i/9i开始出现很多高可用的特性,而在Oracle 10g/11g中,它们更完善、更可靠了。图1-13是一个典型的Oracle MAA体系结构。

图1-13 典型的Oracle MAA结构
在该体系结构中,数据库采用了RAC+ASM+STANDBY的结构体系,应用层采用Oracle自己的Application Server。用户通过负载均衡设备访问不同的Oracle应用服务器,而应用服务器通过自动负载均衡及Failover特性访问当前的主数据库。
当主站点出现故障的时候,Data guard可以手工或者是自动切换到备用端,应用服务器的访问也将自动被切换到备用站点,以保证系统的最大可用性与业务连续性。
1.2.3 Oracle高可用相关功能的产品概述
Oracle提供的高可用相关产品主要有下面几种:
(1)Oracle Parallel Server(8i)/ Real Application Cluster(9i/10g/11g)
(2)Oracle Standby Database(8i)/Oracle Data Guard(9i/10g/11g)
(3)Oralce Advanced Replication(8i)/Oracle Stream(9i/10g/11g)
(4)Oracle Server HA
(5)Other: Mv/RMAN/Oracle Log Miner/Oracle Flashback Query(9i/10g/11g)
等等。本章先对前4个主要的高可用特性进行简单介绍,为本书以后的章节做一个铺垫。
Oracle并行数据库OPS /RAC
OPS从Oracle 8开始提供,从Oracle 9i起开始称为RAC,作为本地环境高可用的典型代表,OPS/RAC设计初衷就是系统与应用的高可用(System/Application high availability)。与其他产品相比,OPS/RAC是多个服务器的Cluster,组成具有更大计算处理能力与故障处理能力的集群。Cluster里面不同的节点(node) 使用一个(一般是一个)或多个Oracle实例(instances)与一个数据库(database)连接,该数据库存放于多个节点的公用存储(Shared Storage)上。
提醒:因为OPS的技术不够完善,如果不作特殊指定,本书介绍的都是Oracle 9i以后的RAC环境。
主要的技术特点:
(1)Database 所有的Data files 是建立在共享存储(Shared Storage)上面的,一般可以采用RAW设备、共享文件系统或ASM(Oracle 10g以后开始提供)。在早期的版本中,对Cluster软件依赖性比较高,不过从9i/10g开始,Oracle也不断地开发了自己的Cluster软件与存储管理,如OCFS、CRS、ASM都是为RAC而准备的,并且不断地完善,也开始被广泛使用。
(2)RAC在共享存储方面并没有冗余保护,在共享存储阵列损坏的情况下不具备切换的能力,因此媒体介质损坏(Media failure)方面,要依靠RAID(redundant array of inexpensive disk) Subsystem、ASM、LV镜像(LV Mirror)、卷复制(Volume Replication)或Standby/Data guard来实现数据的冗余保护。
(3)该技术是Oracle近来主推的技术,特别是10g以后的网格计算与线型扩展能力,在电信、移动、银行等行业使用广泛。10g以后RAC的线形扩展能力,可以把负载均衡分布到多个节点实现共同计算,使RAC在数据仓库环境(OLAP)上也开始大量使用。如果还是老的OPS,则不建议使用,Oracle 9i的RAC也或多或少有一些问题,但是Oracle 10g以后的RAC技术逐渐成熟,基本可以大范围使用了。
不过,RAC在高可用环境下的管理成本与技术的复杂性,也是需要考虑的。
如图1-14所示,最理想的RAC环境,其实就是10g以后提出来的网格计算的概念,在存储层采用ASM实现可扩充性的存储网格计算。ASM在这里可以实现数据的分布、镜像及自动负载均衡等。

图1-14 RAC网格计算
在中间层实现了数据库的可伸缩性,例如可以根据负载情况增加或减少节点个数,可以根据业务情况划分业务的资源分配,可以根据每台机器的负载实现负载均衡,可以充分利用每个节点的资源实现分布计算。
最上层就是应用的分布计算了,应用分布对比数据库分布要容易得多,一般采用廉价的PC服务器就可以实现线形扩展。不过,在高可用的RAC及网格计算模式下,多个应用在一个RAC环境中,更有利于资源的合理分配。比如,在特定时期,可以让财务系统使用更多的机器实现财务对账计算,在另外一个时期,可能让其他业务系统使用更多的资源计算。
所以,理想的RAC以及网格计算,不需要关心数据库是放在什么位置,数据库是怎么运行的,只需要发出一个需求,让网格返回一个结果而已,就像我们用电一样,插上插头,电灯就可以亮了。
Oracle备用数据库Standby/Data Guard
Standby database/Data guard是Oracle推出的一种高可用性数据库方案,在主节点与备用节点间通过日志同步来保证数据同步,备用节点作为主节点的备份,可以实现快速切换与灾难性恢复。
Oracle从7.3才开始支持Standby database。从9i开始,发展为Data guard,并支持Maximize protection、Maximize availability、Maximize performance三种保护模式,可以实现自由的手工主备切换,实现高可用的条件。如果配置合理,可以部分实现自动切换。
从Oracle 9iR2开始,除了原来的物理备用数据库(Physical Standby),也开始支持逻辑备用数据库(Logical Standby),逻辑备用数据库能够实现在数据同步的时候可读写。另外,从Oracle 11g开始,Oracle也开始推出物理备用数据库可以在Open read only模式下实时(real time)同步日志。
提醒:如果不做特殊说明,本书中介绍的Standby都是Oracle 9i以后的Data guard环境,即使名称叫Standby,其实也是指Data guard。
主要的技术特点:
(1)可以实现数据库主机以及共享存储的完全冗余保护,该冗余甚至可以跨地域,做成容灾保护,是Oracle主推的容灾产品。在Standby中,主节点必须运行在归档模式下,并且可能要强制归档(Force Logging),以保证备用节点的数据正确性,因此,该特性在一定方面并不适合数据仓库。
(2)Standby主备用节点对OS的环境要求比较高,一般要求是相同或者是相近的OS环境(Oracle 11g以后这个条件有所放松),而且数据库版本也有特定的要求。如不能做Oracle 9i到Oracle 10g的Standby。
(3)除了最大保护模式外,其他模式下如果主站点的存储损坏而导致备用站点进行失败切换的时候,需要注意数据的丢失问题,务必保证当前环境联机日志的多重冗余保护,并且在切换之前,完全同步主站点当前的联机日志。
(4)在Oracle 11g以前,物理备用节点的主机与存储基本不能提供访问,仅仅能提供只读查询,所以该技术也有严重的资源浪费,不过该技术因为成本比较低,管理方便,技术成熟,所以被广泛使用。在Oracle 11g以后,物理Standby也可以在应用日志的时候就提供只读查询,大大的提高了物理Standby的可用性。
(5)从Oracle 9i开始提供的逻辑Standby,可以在应用SQL同步的时候,提供读写操作。但是,Oracle 9i的逻辑Standby问题比较多,Oracle 10gR2以后的逻辑Standby可以适当使用,也是一个读写分离的好方法。
如图1-15所示,备用Standby如果是逻辑Standby,或者是Oracle 11g以后的物理Standby,则可以在应用日志(SQL)的时候提供读操作,做到读写分离。当可读的Standby很多时,如一个主数据库能够连接很多可以提供读操作的备用Standby,读写分离的效果将更明显。

图1-15 Standby读写分离
另外,在主数据库发生故障的时候,可以选择切换到其中一个Standby上,在做设计的时候,为了成本考虑,可以选择一个Standby的硬件环境跟主库相近,提供切换,另外的Standby仅仅是提供读查询,硬件环境也可以相对差一些,不提供切换。
为了保证Standby的更高可用性,可以将RAC与Standby结合使用,就如上面提到过的Oracle MAA体系结构,主库与备用库都是RAC。另外,如果需要,选择一些单节点的机器,提供非接管性的查询服务。
Oracle高级复制与流(Advanced Replication/Streams)
Advanced Replication/Streams 的设计目的是更灵活地实现数据分布,这种技术可以将一个数据库中的表,用户(Schema),表空间(Tablespace)或者整个数据库复制到另一数据库中,甚至是双向同步。 Advanced Replication是基于内部触发器的技术,而Streams采用挖掘日志的方式,对主系统的压力将更小。
从Oracle 9iR2开始,Oracle更倾向使用Streams的技术,但是也不是说Oracle不再发展高级复制了,只不过是Streams将更适合于高可用环境的复制。而且本书将不介绍高级复制,只介绍Streams或与其原理相同的Quest share plex/dsg realsync。
在Oracle 10g/11g中,Streams技术又得到了很大的强化和扩展,如10g以后开始DownStream、DownStream real time捕获等,对主系统的影响就更小了。甚至可以通过在异地对归档日志/联机日志的挖掘,在对主系统基本没有任何压力的情况下,实现对数据库的表对象、用户、表空间甚至整个数据库的同步。从11g起,Streams还可以支持实时的数据捕获。
Streams主要的技术特点如下:
(1)Streams最大的特点就是灵活,可以跨平台对单独的表对象、用户、表空间或者整个数据库进行复制。而且复制的压力更小,如在主库之外的机器上分析日志,将对主库没有任何额外压力,著名的复制软件Share plex就是采用类似的技术进行数据复制的。
(2)Streams还能实现双向复制,或者多源复制(见图1-16),可以根据应用的特点,自定义复制方式,这个是Standby或者其他容灾软件所不能做到的。
(3)可以实现数据库主机及共享存储的完全冗余保护,甚至是跨地域容灾保护,在很多比较大型的在线系统中,如eBay购物网站,采用该技术(share plex)实现系统的读写分离,通过该技术把写站点的数据复制到多个读站点,大大提高系统的可用性、扩展性与安全性。
因为Streams在Oracle 10gR2以前,问题还比较多,导致该技术没有被广泛使用,但是其对应软件share plex使用还是很广泛的,不过因为其昂贵的价格,则是需要考虑其搭建成本的。不过,Oracle 10gR2以后,Streams还是值得期待的。

图1-16 Streams复制
如果说Standby主要用在容灾设计上,Streams则主要用于Standby所不能完成的,灵活的数据同步。它可以是:
l 跨平台,跨版本等迁移。
l 可以灵活配置,如只同步一部分数据,甚至可以相互同步。
l 可以跨数据库同步,如从Oracle数据库同步到MS SQL Server数据库。
l 两边的数据库可以同时读写。
以上一些特点,在很大程度上,主要用来弥补Standby的一些不足,当然,特别是Oracle 11g以后,Standby与Streams走得越来越近,但是,Streams的一些优势,如部分数据同步、自定义规则的同步、多源同步等问题,Standby还实现不了。
主机相关HA
Oracle主机HA(Server HA)就是上面说的狭义HA,是基于OS的技术,采用OS支持的Cluster Soft来保证主机的冗余保护,可以在主机错误、网络错误时实现自动的保护切换。但是,跟RAC一样,它使用共享存储,所以不能保证共享存储的高可靠性。
它的基本架构共分两种模式:双机互备援(Dual Active)模式和双机热备份(Hot Standby)模式。对于双机互备模式,双机都是正常工作的,但是工作业务不同,在一个主机故障时,切换到另外一个主机上;双机热备模式则只有一个机器工作,另外一个机器处于接管状态。不过,它们的最终原理还是active/standby机制。
不管是哪种模式,Cluster软件都可以正确检测到系统异常并自动进行失败切换,如果是双机互备模式,则需要注意当两个业务都切换到一个Server上的时候,该机器是否能承载双份的压力。
主要的技术特点:
(1)与RAC一样,Database 所有的数据文件(Data files)是建立在共享存储上面的,存储的冗余保护则需要依赖其他技术,如RAID、存储复制、卷复制等等。
(2)HA的技术简单成熟,所以在实际使用中,也能被广泛采用,但是,对主机资源的浪费也最为严重,基本上要保证有对等的资源处于等待状态。
HA很类似于RAC,需要两个或两个以上的主机系统。 因此,在主机失败,或者是一个主机的网络失败的情况下,都可以提供某种程度的恢复,保持系统可用。HA与RAC最大的差别是,一个是OS 上的active/standby解决方案,一个是Oracle的提供的active/standby的解决方案:

图1-17 主机HA
如图1-17所示的是一个典型的主机HA双机解决方案,主机采用双机互备模式,也就是典型的active/standby方式。如果主机发生故障,业务可以自动切换到备用机上。另外,因为共享存储本身不提供保护功能,这里采用存储镜像技术复制到另外一台存储上面,提供数据,包括在必要的时刻提供数据查询以及存储失败的接管。
主机HA的最大好处就是可以解决服务器的单点故障问题,如机器故障,与RAC一样,它并不能解决磁盘故障问题或阵列故障问题。所以HA也必须采用附加的备份机制,如存储同步与异步复制技术、LV镜像与复制技术、数据备份策略等,也可以配套使用Oracle Data guard来实现数据保护。
主机HA的机制起源比较早,发展到现在已经日趋成熟,在实际案例中,使用还比较广泛,但是它必须有一半的资源处于等待状态,所以资源浪费比较严重。




