构建Oracle高可用环境HA rac 4

构建Oracle高可用环境HA rac 4

构建Oracle高可用环境HA rac 4

oracle开发 2010-05-30 17:45:37 阅读151 评论0   字号：大中小 订阅

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的机制起源比较早，发展到现在已经日趋成熟，在实际案例中，使用还比较广泛，但是它必须有一半的资源处于等待状态，所以资源浪费比较严重。
除了数据库环境的高可用设计外，其他的高可用设计包括Oracle数据库高可用辅助环境设计、应用设计、数据库设计等方面。不过这些都不是本书的重点内容，本书只做一些简单的介绍，其中，第2章会比较详细地专门介绍高可用存储与主机的选择和设计，本章也会介绍一些简单的高可用网络设计知识、高可用应用设计及高可用数据库设计。
这里先介绍高可用的网络设计，存储与主机的高可用设计还是等到第2章介绍。可靠的网络环境在高可用环境中是必不可少的，网络环境主要可能考虑的是如下几个因素：
l           可靠性，包括链路与硬件冗余
l           高速性，包括响应速度与吞吐量（带宽）
l           健壮性，比如在Dos攻击时的表现
l           安全性，有很强的安全策略，防止别人侵入
如果一个网络能做到以上4点，那么这个网络基本可以被认为是一个高可用的网络了，复杂的网络环境，还可能涉及路由规划、DNS设置、城域或广域的高速互连。当然，在复杂的网络环境中，很多事情需要网络运营商的配合，而不是单个公司可以解决的。
1.3.1  简单网络
一个简单的高可用网络环境，可能就分布在一个公司内部或一个机房内部，图1-18是一个网络运营商（或者是IDC机房）内部的一个高可用局域网环境：

图1-18  简单网络设计
我们可以看到，这个结构可以简单的分为3个层次：
（1）网络出口层，即最上层的出口是网络运营商，如电信运营商或网通运营商。他们负责把内部网络的信息流和外部互联与传递。
（2）核心网络层，就是中间的主要网络设备，如主交换机、主路由器都采用了对称冗余的方式，在路由器与交换机之间，还存在冗余的负载均衡设备。
（3）应用网络层，网络的最下层就是内部应用层了，这里可能包括所有的应用服务器与数据库，还有一些内部的小的网络交换机与负载均衡设备。为了安全考虑，应用可能会根据不同的类型被分配到不同的子网里面去，如网络Vlan，不同的Vlan之间有不同的访问策略，这个可以通过网络层的策略与ACL来完成。
1.3.2  复杂网络
如果说简单的网络一般都是一个局域网环境，那复杂的网络一般都是城域网或广域网络了。在这样的网络环境中，设置将变得更复杂，不过，有一点是始终不变的，那就是冗余，没有冗余就没有网络的高可用。
图1-19是一个中等复杂的城域网络。

图1-19  复杂网络设计
在以上网络环境中，通过一系列路由设备，把4个子网互联起来，每个子网可以相当于一个上面的简单网络设计中的环境。
从以上看来，网络基本就是一座桥梁，连接了最终的用户与应用，也连接了应用与数据。网络的速度、带宽、稳定性、安全性也就决定了这座桥梁的高可用性。所以，骨干网络的设备都是多重冗余并且是可接管的。
在更复杂的远程网络环境中，涉及的路由设备可能会更多，可靠性与安全性设计也会更复杂。
1.4.1  高可用应用设计技术
高可用应用设计这几年发展得很快，新的技术也层出不穷，但是，主要包含如下三项技术，或者是这三项技术的组合：它们是分布式技术、Cache技术与Search技术。
u          分布式技术
应用服务器相对数据库服务器来说是更廉价的，所以，应用设计最根本的一点就是分布。应用服务器可以采用几百台，几千台甚至几万台来做分布式计算，用户行为与应用服务器之间采用负载均衡设备，这样的情况下，即使坏掉几台服务器，对整个应用构架也是没有任何影响的。分布式技术现在已经从网格（grid）计算技术扩展到云（cloud）计算技术，并进一步走向虚拟化。
u          Cache技术
除了分布，高可用应用设计最核心的技术是Cache，所谓Cache就是高速缓存，而应用层Cache，就是利用服务器内存，把数据缓存到内存中，利用内存的高访问速度，提高应用的访问速度。当今时代，Cache无处不在，如存储有Cache，主机有Cache，数据库有 Cache，应用也有Cache。这里主要介绍的是应用的Cache，数据库的Cache就是上面所说到的SGA，至于其他的一些Cache方式，如存储 Cache，本书第2章也会有详细介绍。
Cache在内存中的数据，可以采用定时更新或者是实时更新。在定时更新中，数据同步一般有一个延迟；如果是实时（real time）更新，如被Cache的数据发生了变化，就更新Cache服务器，或者是通知Cache服务器来获取最新的数据。
当然，Cache也有很多变化，如分布式Cache，把分布技术与Cache技术有效结合，让Cache数据分布在多个应用服务器上面，而且任何一个数据可能被Cache多份。分布式Cache的最大的好处就是，如果单个机器的损坏，对整个Cache环境没有任何影响。
Cache技术还可以扩展到内存文件系统、内存索引、内存数据库等不同的领域与方式。如分布式的内存文件系统，结合了文件系统的优点，又实现了分布与快速响应，可以快速返回文件数据，如图片文件的存放与读取。内存数据库则结合了数据库的特点与Cache的快速，如 Oracle公司的timesten内存数据库，既可以实现数据库的事务型应用，又可以实现数据的快速响应。
u          Search技术
除了分布式与Cache技术，现在还有一个发展很迅速，使用很广泛的技术，那就是Search技术。其实Search也是基于Cache的，不过，Search还有自己的很多技术特点，如Build技术，分词技术等等。
一般的Build技术采用定时Build，因为在数据量非常巨大的情况下，很难做到实时（real time）的Build。如Google、Baidu基本上都是每天定时更新一次数据，所以，在更新以前，怎么搜索都是相同的结果。当然，在一些特定的情况下，也需要采用实时Build，如电子商务网站eBay，希望每个商品的改变都能立即显示出来。实时Build会要求每个改变都能立即通知到Build 服务器，然后同步到Search的特定内存索引上。
1.4.2  典型应用构架结构
因为以上的几项技术并不是单独存在的，而且，不同的应用可能在不同的层次上，我们可以对应用做一个简单的层次模型（如图1-20）来观察这些技术。

图1-20  应用设计
在典型的应用设计体系结构图中，可以分为3个层次，每个层次之间还可分为多个子层。层次之内的模块是独立的，没有业务关联关系，但是，层次之间存在一定的交互关系。
（1）用户层，代表了用户的所有请求，以及活动行为。
（2）应用层，首先是包括各种各样的产品与功能，如交易系统、财务系统等，然后通过下        层的各种核心服务，如一些公共通用性服务接口，直接访问下层数据，为搜索引擎提供数据等。
在核心的服务之下，就是应用服务接口API，这些代用业务性质的API可以被上层的服务直接调用，也可以开放给外部客户，供他们访问。在应用服务接口API之下，就是应用层的分布式Cache，提供被访问数据的缓冲。
（3）数据层，从应用服务接口API访问的数据，可能直接被应用层的Cache返回，直接返回的叫Cache命中，如果不能命中的，则需要从数据库，或者是从文件系统上返回。数据库与文件系统也可能是分布式的，通过数据调用接口API统一控制。
数据调用接口API中，主要包括路由技术与队列技术。
路由技术则是封装了数据库的位置，甚至是数据库的类型，如有两个不同的数据库，Oracle与Mysql，甚至是Oracle与文件系统，它们分布在不同的物理位置，但是路由技术知道从什么位置、什么数据库中获得必要的数据，而不需要应用层来关心。
队列技术则是一种同步技术，如分布式的数据库中，经常有一个事务需要跨数据库来运行，这种情况下，可以先写队列，由队列同步到不同的数据库中。
在上面介绍了很多Oracle数据库的高可用产品，它们也是数据库设计中非常重要的一个环节。虽然它们是本书的重点，也是保证Oracle高可用环境的不可缺少的部分，但是，除了这些，另外也还需要考虑一下数据库的应用设计或者是叫Schema设计。
数据库的Schema设计的时候，也是需要有丰富的设计经验，才可以设计出来一个高效的高可用数据库的。好的数据库设计，可以保证数据库的可扩充性与良好的性能。下面就范式设计、反范式设计与数据库分布设计说一下数据库Schema设计。
1.5.1  数据库范式设计
对于数据库范式设计，一般在设计时，只需要了解到第三范式即可，后面的范式没有必要过于计较，前三种范式在数据库设计中还是非常重要的。
u          第一范式（1NF）：在关系模式R中的每一种具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是第一范式的关系。
第一范式简单的说，就是要求属性具有原子性，不可再分解。表1-1是一个最简单的例子。
表1-1
编号 姓名 选修科目
001 张三 语文，数学，英语
002 李四 物理，化学
003 王五 历史，地理，生物

从表中可以看到，在课程选修表中，选修科目设计为一个字段，选修的科目内容用逗号分开，看起来是好像没有什么问题，但是，如果想统计哪些人选修了哪门科，将变得非常困难，如想统计哪些人选修了化学，可能需要用到如下的SQL
SQL>select count(*) from course where subject like ‘%化学%’;
除了这个影响，更新的影响也非常大，如，上面的李四现在想在选修科目中增加一门生物，他必须先读出以前的科目，然后在科目后面合并一个生物，这个表就不满足第一范式。
那么，为了满足第一范式，可以做一点简单的修改（见表1-2）。
表1-2
编号 姓名 选修科目
001 张三 语文
001 张三 数学
001 张三 英语
002 李四 物理
002 李四 化学
003 王五 历史
003 王五 地理
003 王五 生物

作了以上修改就可以满足第一范式了，如果想统计哪些人选修了化学，SQL语句可以修改为。
SQL>select count(*) from course where subject = ‘化学’
如果想给李四增加一门生物选修课，只要insert一个新行即可。
u       第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R是属于第二范式的。
第二范式简单地说，就是每个表有个主键，其他字段完全依赖于该主键。
还是以上面的表为例，现在满足了第一范式，但是，不满足第二范式，也就是没有可以唯一确定的主键，如果王五同学想把课程地理修改成天文学，他不得不把所有的字段作为查询条件来更新该记录。那好，我们增加一个主键ID（PK），如表1-3所示：
表1-3
ID(PK) 编号 姓名 选修科目
1 001 张三 语文
2 001 张三 数学
3 001 张三 英语
4 002 李四 物理
5 002 李四 化学
6 003 王五 历史
7 003 王五 地理
8 003 王五 生物

有了主键，如果能确定哪一行需要修改，用主键就可以定位该行。如王五同学想把课程地理修改成天文学，那么更新语句可以是根据主键来更新。
SQL>update course set subject = ‘天文学’ where id=7;
这样，以上的表符合第二范式了吗，其实还没有，我们可以看到，编号依赖于ID，但是姓名是依赖于编号的，没有唯一的主键，还不符合第二范式，那会有什么问题呢？如张三要换一个名字，就要更改这个表中的三条记录，如果涉及1万条记录呢，那就需要更新1万条记录。
这也仅仅是其中一个问题，还有，假如要统计有多少个学生，从课程表中是很难获得的，因为可能有的学生没有选修课程，就是全部选修了，也要distinct，大大影响了性能。
基于以上很多影响，可以修改为如表1-4和表1-5的父子表：
表1-4为父表——学生表，表1-5为子表——课程表。
表1-4
编号(PK) 姓名 来源地
001 张三 北京
002 李四 上海
003 王五 广州

表1-5
ID(PK) 学生编号(FK) 选修科目
1 001 语文
2 001 数学
3 001 英语
4 002 物理
5 002 化学
6 003 历史
7 003 地理
8 003 生物

有了上面的两张表，现在，清晰多了，学生信息直接从学生表中获得，课程信息直接从课程表中获得。
u          第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。
第三范式是很重要的，表示了不要存在值的依赖关系，比如还是上面的课程表，现在增加了选修课成绩等级（见表1-6）。
表1-6
ID(PK) 编号 选修科目 成绩 等级
1 001 语文 60 及格
2 001 数学 87 良好
3 001 英语 57 不及格
4 002 物理 43 不及格
5 002 化学 99 优秀
6 003 历史 90 优秀
7 003 地理 74 及格
8 003 生物 81 良好

这里，相信大家都能看出来问题在哪里，因为等级是直接依赖于成绩的值的，现在假定某个人的成绩从60修改成50，那么不得不修改对应的等级，如果修改失误，则可能造成数据的异常（不对应），这就不符合第三范式。
除了上述3种范式，还有很多其他范式，这里不再一一列举，这三种范式比较重要，所以，在这里列了出来，供大家在设计数据库的时候参考。
注意：数据库的设计的好坏，将可能影响到应用的性能，数据库设计得好，可以为高可用的环境打下良好的根基。
1.5.2  反范式数据库设计
数据库设计要严格遵守范式，这样设计出来的数据库，虽然思路很清晰，结构也很合理，但是，有的时候，却要在一定程度上打破范式设计。
这里其实并不矛盾，因为范式越高，设计出来的表可能越多，关系可能越复杂，但是性能却不一定会很好，因为表一多，就增加了关联性。特别是在高可用的OLTP数据库中，这一点表现得很明显。
最明显的打破范式的设计方法就是冗余法，以空间换取时间的做法，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联。
还是用上面的例子，学生表与课程表，假定课程表要经常被查询，而且在查询中要显示学生的姓名，查询语句则为：
SQL>select code,name,subject from course c,student s where s.id=c.code where code=?
这个语句如果被大范围、高频率执行，可能会因为表关联造成一定程度的影响，现在，假定评估到学生改名的需求是非常少的，那么，就可以把学生姓名冗余到课程表中，又变回了如表1-7所示：
表1-7
ID(PK) 编号 姓名 选修科目
1 001 张三 语文
2 001 张三 数学
3 001 张三 英语
4 002 李四 物理
5 002 李四 化学
6 003 王五 历史
7 003 王五 地理
8 003 王五 生物

注意：我这里并没有省略学生表，不过是把学生姓名冗余在了课程表中，如果万一有很少的改名需求，只要保证在课程表中改名正确即可。
那么，修改以后的语句可以简化为：
SQL>select code,name,subject from course c where code=?
1.5.3  数据库分布技术
除了应用更容易采用分布式技术以外，数据库也是可以采用分布技术的，而且是有必要采用分布式技术的，特别是访问量很高的应用，如果不采用分布技术，再高配置的服务器也可能承载不了业务的需求。
数据库的分布技术，大致可以分为如下几类：
u          主机角度的分布技术
数据库的分布技术，主要是为了解决单个数据库服务器成为瓶颈，而不能承载业务的情况。这时，只要把数据库运行在多个主机上即可，Oracle RAC或者是网格计算就是一种很好的解决方案，它们可以保证在多个主机上运行数据库业务。
另外，读写分离也是一种有效的解决方案，读写分离就是在一个数据库中写入数据，然后把写入的数据同步到多个站点，在其他的站点上读取数据，这样也可以把应用的负载分布在多个不同的数据库站点上面。如果写的数据库失败，可以找一个读的数据库来接管，从Oracle技术角度来说，Logical standby、Streams、Oracle 11g的可只读Physical standby都可以实现这样的需求；从非Oracle技术角度来说，复制软件如quest share plex/dsg realsync也可以实现这样的需求。
u          应用角度的分布技术
数据库也可以从应用的角度考虑分布，从应用角度的分布一般有两种解决方案，垂直分割与水平分割技术（见图1-20）。
垂直分割，表示按照应用来分割，如应用1与应用2是可以独立出来的完全不同的应用，则把它独立出来，分割在两个不同的数据库服务器上，这样就实现了垂直分割。这种情况下，如果一个应用故障，就不会影响到其他应用。
水平分割，一般是数据量的分割，如有一个用户表，可以按照一定规则，把用户表分割成两个表，再分布在两个不同的数据库中，当特定的用户访问数据库的时候，根据规则就可以知道它在哪个数据库中，然后访问该数据库即可。这种情况下，如果一个库失效，受影响的只是这个库存放的特定的用户。

图1-21  数据库分布技术
如图1-21，拿两个最简单的应用做比较，在垂直分割技术中，论坛与博客是两个不同的数据库，论坛访问论坛的数据库，博客访问博客的数据库。这种情况下，如果论坛坏了，不会影响博客，反之亦然。所以，这种方式，影响的是一个特定的应用。
另外一种分割技术中，把一半用户的论坛与博客数据存放在一个数据库，另外一半存入另外一个数据库，两个库基本一样，都是保存接近1/2的论坛+博客数据。这种情况下，如果一个库坏了，就有一半的用户不能访问论坛，也不能访问博客，而另外一半用户是正常的。这种分法不一定是分成2个数据库，也可以水平分割成n个数据库，如果出现问题，影响的是部分的用户群，如1/n的用户。
其实，在很多情况下，也不完全是单纯的垂直分割或者是水平分割，而往往是混合型分割，如先根据业务来垂直分割数据库，如果单个业务在单个数据库中都不能承载，则可以考虑对这个应用再水平分割，把这个应用分割成多个数据库。然后，再结合RAC技术以及读写分离技术实现数据库的可扩展性与高可用性。
1.5.4  区别OLTP还是OLAP
在数据库的设计中，就算完全掌握了以上的方法，但是，在不同的数据库类型上，使用起来也是大有差别的，这就需要设计者弄清楚自己的业务类型。如果没有正确地识别自己的业务类型，就盲目地开始设计数据库，或者是盲目地寻求优化方法，则往往是把OLAP的方法使用在OLTP上，或者是把OLTP的方法使用在OLAP上。如果这样，很可能会适得其反。
u          什么是OLTP
OLTP，也叫联机事务处理（Online Transaction Processing），表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的 Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。
注意：如果不特殊指定，本书中的高可用数据库都是指OLTP类型的数据库。
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。
CPU出现瓶颈常表现在逻辑读总量与计算性函数或者是过程上，逻辑读总量等于单个语句的逻辑读乘以执行次数，如果单个语句执行速度虽然很快，但是执行次数非常多，那么，也可能会导致很大的逻辑读总量。设计的方法与优化的方法就是减少单个语句的逻辑读，或者是减少它们的执行次数。另外，一些计算型的函数，如自定义函数、decode等的频繁使用，也会消耗大量的CPU时间，造成系统的负载升高，正确的设计方法或者是优化方法，需要尽量避免计算过程，如保存计算结果到统计表就是一个好的方法。关于逻辑读与CPU处理能力的详细计算方法，在第12章还有详细介绍。
磁盘子系统在OLTP环境中，它的承载能力一般取决于它的IOPS处理能力，关于IOPS，在第2章中有详细介绍。因为在 OLTP环境中，磁盘物理读一般都是db file sequential read，也就是单块读，但是这个读的次数非常频繁。如果频繁到磁盘子系统都不能承载其IOPS的时候，就会出现大的性能问题。另外，在第2章中，还会详细介绍存储子系统的IOPS承载力的计算问题。
OLTP比较常用的设计与优化方式为Cache技术与B-tree索引技术，Cache决定了很多语句不需要从磁盘子系统获得数据，所以，Web cache与Oracle data buffer对OLTP系统是很重要的。另外，在索引使用方面，语句越简单越好，这样执行计划也稳定，而且一定要使用绑定变量，减少语句解析，尽量减少表关联，尽量减少分布式事务，基本不使用分区技术、MV技术、并行技术及位图索引。因为并发量很高，批量更新时要分批快速提交，以避免阻塞的发生。
u          什么是OLAP
OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。关于磁盘子系统的带宽承载量计算，在第2章也将有详细介绍。
在OLAP系统中，常使用分区技术、并行技术。如分区技术可以使得一些大表的扫描变得很快（只扫描单个分区），而且方便管理。另外，如果分区结合并行的话，也可以使得整个表的扫描会变得很快。并行技术除了与分区技术结合外，在Oracle 10g中，与RAC结合实现多节点的同时扫描，效果也非常不错，可把一个任务，如select的全表扫描，平均地分派到多个RAC的节点上去。
在OLAP系统中，不需要使用绑定（BIND）变量，因为整个系统的执行量很小，分析时间对于执行时间来说，可以忽略，而且可避免出现错误的执行计划。但是OLAP中可以大量使用位图索引，物化视图，对于大的事务，尽量寻求速度上的优化，没有必要像OLTP要求快速提交，甚至要刻意减慢执行的速度。
u          分开设计与优化
以上描述了OLTP与OLAP的特点，在设计上要特别注意，如在高可用的OLTP环境中，不要盲目地把OLAP的技术拿过来用。如分区技术，假设不是大范围地使用分区关键字，而采用其它的字段作为where条件，那么，如果是本地索引，将不得不扫描多个索引，而性能变得更为低下。如果是全局索引，又失去分区的意义。
并行技术也是如此，一般在完成大型任务时才使用，如在实际生活中，翻译一本书，可以先安排多个人，每个人翻译不同的章节，这样可以提高翻译速度。如果只是翻译一页书，也去分配不同的人翻译不同的行，再组合起来，就没必要了，因为在分配工作的时间里，一个人或许早就翻译完了。
位图索引也是一样，如果用在OLTP环境中，很容易造成阻塞与死锁。但是，在OLAP环境中，可能会因为其特有的特性，提高OLAP的查询速度。MV也是基本一样，包括触发器等，在DML频繁的OLTP系统上，很容易成为瓶颈，甚至是Library Cache等待，而在OLAP环境上，则可能会因为使用恰当而提高查询速度。
1.6.1  美国eBay高可用环境分析
eBay（www.ebay.com）是世界上最大的C2C电子商务网站，到2007年年底，该网站的注册用户数量达到2.48亿，并存有10亿张以上的图片，该网站每天要支撑10亿次的PV，有合计2P（1P=1024T）的数据量，这么庞大的一个系统，还能整体上保证99.94%以上的高可用性。
那么，eBay是怎样保证这么大的系统，还有这么高访问量的高可用呢，这里先看看他们的规模与高可用构架结构（见图1-22）。
l           为了支撑这么多的业务量，有16000台以上的Web服务器，运行J2EE，以及1000台以上的逻辑数据库分布在400个不同的物理主机上，实现了良好的水平扩展性，每天的SQL执行量超过了440亿次。
l           数据库运行在Oracle上，应用服务器采用websphere。每个数据库至少有3个在线的备份，分布在8个不同的数据中心。数据库中没有存储过程，只有少量的触发器，把很多 CPU密集型的任务从数据库迁移到Web服务器上，因为数据库更容易成为瓶颈，而Web服务器是廉价可扩展的。数据库采用多点复制，可负载均衡，不采用分布式事务。
l           应用构架方面，采用连接池，应用层采用多层结构。eBay最大的成功在于解决了两个关键性的技术：分布式的数据库与实时的Search。

图1-22  EBay高可用体系结构
可以看到，eBay最核心的技术就是分布，首先Web服务器是分布的，存在16000台以上的Web服务器，相对于比较集中的数据库来说，Web服务器更容易扩展。为了保证数据库的负载最小，eBay采用了很多策略，把负载从数据库转移到可扩展的Web服务器上。
在数据库上面，eBay是先把数据库按照应用在一定程度上垂直分割，然后采用sheard plex水平分割，实现读写分离的分布策略。数据库分布在多个数据中心，应用通过数据层与负载均衡设备访问数据库，根本不必要关心数据库的位置在哪里。
另外，因为数据分布在多个数据中心，而这些数据中心并不在一个地点，也就实现了数据的容灾保护。当写站点发生故障的时候，只要切换到其他一个备用站点即可。
1.6.2  Myspace构架分析
上面分析了eBay的案例，再来看另外一个案例，那就是Myspace（www.myspace.com），从目前的情况来看，Myspace的月访问量超过400亿，并超越了YAHOO。
Myspace采用的是Ms SQL Server，但是，能做到这么好的性能与访问量，是很不容易的，这里分析一下它的高可用发展历程。
u          读写分离分布技术
Myspace最初只有两台老式的Web服务器与一个Dell 双CPU，4GB内存的PC Server数据库服务器，数据库是SQL Server。当2004年Myspace有50万用户的时候，数据库服务器实在不能满足当时的需求，Myspace采用3台SQL Server服务器，一个为主，所有的数据都向它提交，再由它复制到另外两个数据库上，实现了最简单的读写分离。
u          垂直分割技术
在2004中，Myspace用户达到1~2百万，存储成为当时最大的瓶颈，因为IO的响应时间过长，导致用户无法完成自己的请求。这个时候，Myspace对数据库采用垂直分割的技术，不同的数据库运行不同的业务，存储也采用了SAN存储网络技术，提高了系统的性能与可靠性。
u          水平分割技术
在用户越来越多的情况下，当用户继续增加到3百万后，采用以上垂直分割的技术也出现了问题，如一项单独的业务在一个数据库中都可能成为瓶颈。最初为了适应单个业务的增长，Myspace采用了更好的机器，但是，更好的机器并不能解决数据量增长问题，马上又达到新的瓶颈。这个时候，Myspace采用了分布计算与水平分割技术，按照用户进行水平分割，一个数据库大致保存200万个左右的用户以及对应用户信息。
u          虚拟化技术与Cache技术
水平分割解决了数据库主机的问题，但是，有些特定数据库上的用户可能数据量特别巨大，但是有些数据库上的用户数据量可能又很小，导致存储设备使用严重不均衡。这个时候，Myspace采用了3PARdata的虚拟化存储技术，让存储设备统一管理，这样整个SAN被当作一个巨大的存储池，不再要求某个特定的存储设备为特定应用服务。
当用户越来越多，压力越来越大，Myspace启用了新的策略以减轻存储系统的压力，增加数据缓存层——位于Web服务器和数据库服务器之间，其在内存中建立被频繁访问的数据副本，以前100个用户查询同一数据，需要查询数据库100次，现在只需要1次。如果页面变化，缓存中的数据将从内存中擦除，然后重新从数据库获取。
现在，Myspace已经超过2600万用户，设备已升级到SQL Server 2005版，因为可以支持64位系统，这样可以支持更大的内存，2006年后每台机器的标准配置是64GB内存。
从以上的情况来看，Myspace采用了高可用环境中的必需的几项技术：
首先就是分布式计算架构，包括应用与数据库，先是简单的读写分离，当读写分离不能适应需要的时候，采用了垂直分割技术，当垂直分割技术也不能适应需要的时候，最后采用了按照用户水平分割的技术。
然后，当存储过于分散的时候，存储系统出现了空间与负载使用的不均衡，他们又采取了虚拟存储的策略，把所有的存储整合成一个存储池，解决了存储设备使用不均匀的问题。
最后，当分布技术与虚拟存储也解决不了问题的时候，Myspace采用了Cache技术，这个才是它最终能承载那么大流量的关键，Cache技术可以快速地响应请求，大大地减少数据库压力。
 
本章的内容比较多，作为全书的一个导读，先介绍了Oracle的体系结构，包括内存结构、后台进程、物理对象与逻辑对象。
然后，介绍了Oracle的最高体系结构（MAA）与Oracle的典型高可用产品，为本书后面进一步介绍这些特性打下基础。
接下来，介绍了设计高可用性数据库的一些要点，如应用设计、网络设计、数据库设计等，并描述了在不同的数据库模式下，不同的设计方法。
最后，通过两个案例描述了典型的高可用设计的方法，读者或设计者可以根据这些设计方法或者是案例，得到一些设计自己所需要的高可用体系的启发。
光看本章，可能得到一些启发性的东西，但是具体的技术实现，则需要通过后面的章节来了解。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/guoli0813/archive/2008/09/17/2943578.aspx