RAC 11.2 体系结构（一）

这一部分我们在RAC上应用的高可用设计的层面上，讨论一些Oracle数据库的特性。我们同时也会指出，什么地方可用性会被限制，比如打补丁和重要的数据库升级。然后我们将视线转移到站点间的可用性，讨论Data Guard(灾备)和Oracle Streams(信息共享与复制)。RAC解决方案不是孤立的，很多组件扮演一个角色、很多技术被利用来搭建一个健壮的、高可用的、可扩展的应用。

可用性

很多用户选择RAC解决方案，因为他们需要他们的应用对客户持续可用，且可以容忍一些类型的故障而不会中断服务。在这个应用多层、面向网络的时代，可用性和应用的可扩展性事保证用户基础的关键。调查发现，如果用户在浏览器访问一个web页面，如果在大约十秒钟以内不能完全出现结果，那么他们会很烦躁，常常会离开很少还会回来。

会损害系统的可用性的中断从根本上分为两类：计划和非计划。Oracle技术提供了大量互补的技术，可以避免几乎所有类型的中断。下面两个表分别列出非计划中断的挽救措施和避免中断的技术。

节点数的决策

很多RAC系统都只有两个节点。你可以常常在英国的Oracle用户会议的举手投票中得到这样的结果。这样的系统常常用在类似active/passive集群中，RAC完全为了高可用而部署。

适当的节点数的讨论不应该局限在在线生产系统。在用户适应RAC以前，他们很可能在类似展示和质量保证的生产前环境中考虑过节点数量，也可以用作容灾方案。由于很多原因，有一个与生产环境一样的生产前的环境是很有益处的，否则你可能会在代码发布以后经历不愉快的体验。你可以在一个与生产环境完全一样的拷贝中进行测试——如果你的数据与生产环境不同步；所有的测试都有可能出错。一个非生产的RAC集群是必要的，用来在生产库里应用补丁前先在非生产库里测试，以避免非计划中断或Oracle程序文件的损坏。

如果没有多余的硬件或预算来创建一个用来测试RAC系统，你可以在一个服务器上创建一个虚拟的RAC系统。Oracle VM是一个免费的虚拟机管理软件。

灾难恢复(DR)站点的性能应该与生产站点相同；当发生危机需要启用DR站点时的最后一件事，是确保DR站点能承载工作量。将老的生产环境回收来作为DR是不推荐的。

双节点RAC集群

两节点的RAC有一些优势：首先，购买许可的成本比较低；第二，只有两个节点可以使全局缓存转移得到简化，因为不会出现三向的通讯。标准版RAC的许可条件看起来不允许超过2个装备了新型处理器的节点，因此你的拓扑不如企业版的灵活。

当设计和实施这样的安装，每个单独的节点需要在发生节点故障时承担所有的负载。或者在这样的情况下，通知用户只进行必要的操作来使工作量降低。单独的RAC节点的处理能力可能会随着时间而降低，那时候会有更大的问题，因此这些安装必须能承受大于全部工作量的负载。

Oracle RAC One Node

在Oracle 11.2中，引入了一种介于RAC和active/passive中间的混合RAC，它叫做RAC One Node。当你需要扩展到完全的RAC时，这种转换将比较简单。RAC One Node的主要目的之一是允许计划停机，例如，运行中的数据库实例可以使用omotion工具移动到另一台主机上而对应用没什么影响，然后可以在原先运行实例的主机中进行维护操作。与RAC系统不同，它只有一个实例来为用户连接服务；不过，它还是需要以RAC数据库的方式创建。

这个实例注册在Oracle Grid Infrastructure、元数据仓库和集群高可用框架中。通过这种方法，RDBMS实例可以从Grid Infrastructure提供的高可用选项中获益，也就是故障检测和保护、在线滚动打补丁和在线滚动升级。

RAC One Node发布的第一个版本是在11.2.0.1，只能用在Linux系统中。它不支持Data Guard，在默认的安装中也不可用。对RAC One Node感兴趣的用户必须下载My Oracle Support补丁9004119。其他平台的管理员想使用的话需要等待第一个补丁集的发布。用户指南还提示RAC One Node将不支持第三方集群软件，比如Veritas Storage Foundation for RAC或者HP Serviceguard。一旦RAC数据库在一个节点上创建，一些工具将作为上面提到的补丁的一部分安装，允许用户将系统转换成RAC One Node数据库。这个转换通过raconeinit命令来进行，当它执行完毕后，你会发现数据库实例被重命名为instanceName_1。

就像上面提到的，一个新的工具叫omotion允许用户将一个RAC One Node实例转移到集群中的另一个节点上。当需要对节点做一个计划维护，或者你的集群节点用完了所有资源，容纳不下数据库的时候，移动实例会很有用途。为了减轻应用上对用户的影响，需要使用TAF或FCF。如果不使用的话，正在执行的事务会在某个用户可定义窗口中完成；然后，接下来用户连接将会被断开，并出现ORA-3113"End of line on communication channel"错误。这个错误是由宽限期后开始的数据库实例的关闭导致的。

如果需要将一个RAC One Node转变为"full" RAC，另一个工具racone2rac可以用来简化这个过程。只需要从一个文本菜单中选择你的RAC One Node数据库，然后让这个工具将其转换为RAC数据库。转换的结果看起来与使用policy-managed数据库的结果类似。policy-managed数据库是11.2中引入的新特性，标志了传统RAC数据库的一个转变，以前数据库管理员需要负责管理RAC数据库的所有方面，比如初始化参数、在线redo线程和其他结构上的改变。通过policy-managed数据库，DBA只需要定义数据库节点的数量，Oracle会接管剩下的工作(增加/删除节点)。所有需要而当前没有的组件都会自动创建。

多节点RAC系统

当单个节点发生故障时，多节点的系统比双节点集群更容易支撑所有的工作量。一个正确设计的RAC系统应该有足够的冗余来保证应用可以继续运行，产生尽量小的中断。因此很多企业采用了超过2个节点的RAC。在这种情况下，设计一个n节点的集群时，这个集群应该在只有n-1节点工作时支持全部的工作量。这意味着集群中有一个节点可以作为冗余，这个冗余的节点也不需要处于闲置状态。比如，它可以用来做备份和报告；唯一的要求是，它能在短时间内为集群提供它的处理能力。

从Oracle 10.1开始，当确定当前集群的节点数不足以支持工作量时，可以在线添加节点到集群中。在Oracle 11.2中，引入了网格即插即用和策略管理的数据库使这个过程得到了改进和简化。

在线维护和打补丁

不管一个新的系统在上线前经过了多么仔细的测试，它迟早需要打补丁。这有多个原因，通常主要原因如下：一个内部错误导致应用不可用；当前使用的版本马上要不被支持。例如，Oracle在2010年不再主要支持10g r2（但Oracle将服务免费延长一年），这可能会是将数据库升级到下一个版本的原因；一个关键的安全补丁需要应用；合同要求履行预定的维护工作。

打补丁会对可用性产生影响，虽然Oracle通过在线打补丁和滚动补丁应用机制改进了这种状况。Oracle中补丁应用的主要工具是opatch。但是，关键的版本审计不能通过opatch来执行，你需要使用OUI来来达到这个目的。

（有一点很重要，在高可用系统中，不要为了打补丁而打补丁。）

所有的补丁应用都是有风险的，不管你事先做了多少测试。几乎所有的DBA都可以讲述一个因为应用补丁导致的错误。打补丁同时意味着在一个节点中修改二进制文件时，需要提供这个节点的停机时间。

在Oracle数据库领域里，有一些不同种类的补丁，下表做一个介绍：

使用opatch为RAC打补丁

过去，系统打补丁大多都意味着要停机。但是现在，opatch支持集群的滚动升级，最小化服务可用性的中断。在尝试打任何补丁之前，确定Oracle Inventory中包含了集群中所有节点和它们补丁级别的元数据没有损坏是很重要的。全局目录在所有补丁操作期间都被维护，它列出了RAC集群中的可用的Oracle目录。运行opatch工具带lsinventory参数来确定目录没有损坏，比如$ORACLE_HOME/OPatch/opatch lsinventory

你会在接近输出底部的地方发现一些重要信息；opatch工具可以正确找出RAC的节点，同样可以正确检测到命令运行在哪个本地节点上。如果opatch报告的信息是错误的，不要继续打补丁，因为opatch不能把补丁信息正确注册到全局目录中。

Opatch操作模式

OPatch在RAC中可以在四种不同的模式下操作：All node patch；Rolling patch；Minimum Downtime patch；Local patch

All Node Patch模式

Opatch对待集群就像在单实例中一样，在数据库停止的时候对所有的节点打补丁。这个补丁模式对可用性的影响最大，只能在一个约定的停机窗口中执行。否则这个模式不真正适用于RAC系统。

Rolling Patch模式

集群中的所有节点都打上补丁，但一次只有一个，以避免停机。第一个节点将被停下来打补丁，打完补丁以后，它会重新启动。OPatch会询问你是否要继续下一个节点，直到所有节点都打完补丁。由于至少会有一个节点保持在线为用户提供服务，因此没有停机。

不幸运的是，不是所有的补丁都支持这种模式。你可以使用opatch的query选项来确定是否支持，例如：

[grid@london1 PSU1]$ $ORACLE_HOME/OPatch/opatch query \
> -is_rolling_patch 9343627/
Invoking OPatch 11.2.0.1.2
Oracle Interim Patch Installer version 11.2.0.1.2
Copyright (c) 2010, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/grid/product/11.2.0/crs
Central Inventory : /u01/app/oraInventory
from : /etc/oraInst.loc
OPatch version : 11.2.0.1.2
OUI version : 11.2.0.1.0
OUI location : /u01/app/grid/product/11.2.0/crs/oui
Log file location : /u01/.../opatch/opatch2010-06-14_16-41-58PM.log
Patch history file: /u01/.../cfgtoollogs/opatch/opatch_history.txt
---------------------------------------------------------------------------
Patch is a rolling patch: true
OPatch succeeded.

Minimum Downtime Patch模式

在这种策略下，你将集群的节点分成两部分。打补丁的时候，第一个节点集会关闭实例并开始打补丁，当打完补丁时，第二个节点集将关闭。这时候第一批打补丁的节点已经启动了。当第二部分的节点也打完补丁，这些家电将重新启动，整个集群都已经应用完补丁了。

Local Patch模式

最后，集群中的单个节点可以在opatch中指定-local来打补丁。可以使用这种方法来实现与rolling patch类似的功能。最后，你要确认补丁信息在每个节点的Oracle inventory中正确记录了。

使用哪一种模式来打补丁取决于可用性需求和用户或业务的需要。Minimum downtime模式和rolling patching是类似的，使用让集群部分可用的方式来进行。一些业务可以拥有周末的停机时间，因此他们可以选择all-node补丁方式，更节省时间和资源。

RAC中的实例恢复

另一个影响RAC系统可用性的角色就是实例恢复。先前提到过，实例故障不会像单实例Oracle中一样导致应用的完全中断，立即变得不可用，用户也会感觉到这个故障。在单实例情况下，构建了SGA的内存结构会马上消失，并且需要在实例再次启动是重新构建。如果这种情况发生，系统监控进程(SMON)必须执行实例恢复来使数据库回到一致状态，并对用户可用。不幸运的是，这会花些时间。

RAC中的实例恢复和单实例情况中有很大的不同，并且它不会导致中断。集群中的另一个实例将会检测到一个实例的故障，一旦检测到，后台进程会在集群内remaster故障的资源，用户会感觉到短暂的停顿。系统不可用或局部不可用的时间窗口取决于系统的活跃程度、故障实例所master的块的数量、和故障节点持有的(比如队列)全局资源数。

任意一个其他实例将代替故障的实例管理实例恢复。有两个工作流程需要完成：

队列Remastering：全局队列服务监控需要恢复诸如队列(主要有TX何TM事务和表级修改的队列)和buffer cache中的缓存资源之类的全局资源。

数据库恢复：SMON进程执行数据库恢复，就像它在单实例情况下做的一样。

这些操作中有一些是可以并行执行的。

Enqueue Remastering

实例恢复的第一步就是remaster全局队列，由全局队列服务(GES)来执行。你可以把队列看做全局锁，实例崩溃会导致全局资源目录中维护的一些队列的元数据丢失，它必须由同时工作的存活的实例来恢复。LMON全局队列服务监控进程负责这项工作。

所有的集群节点在它们的SGA中共同维护全局资源目录(GRD)。需要访问资源的集群操作需要同步，而这正是GRD要干的。GRD由全局缓存服务进程和全局队列服务进程维护，它们负责管理共享SGA中的块和全局锁。集群中的每个资源都由一个指定的实例来master，其它的所有实例都知道一个资源的resource master是哪一个实例。

全局队列的恢复时间与系统工作量、故障实例数和挂起的工作有关。在一个繁忙的系统中，你往往会发现TM和TX队列(表/分区修改队列和事务队列)的remaster花费的时间最长。在过去(那时还是Oracle Parallel Server)，用户尝试将初始化参数dml_locks设置为0，你偶尔还能在英特网上看到这个建议，但是要小心！当这个设置起作用并禁用了队列，会remaster一个快速进程，同样会强制添加一些限制，使得这个方法不适用于现在的环境。特别是，将dml_locks设为0会导致下面的限制：

• 你不能使用drop table或create index表达式
• 显式的lock表达式将不被允许。比如，你不能使用LOCK TABLE表达式
• 你不能在任何实例上使用企业管理器。

不值得花时间来做这个参数的试验。像先前提到过的一样，RAC实例恢复会对你的应用产生影响。所以，你要在将其投入生产之前彻底地测试你的应用在实例故障时的情况。

实例恢复的第二步是remaster全局缓存资源，它们是buffer cache中的块。全局缓存服务进程GCS，负责这个工作。为了提高这个过程的速度，只有那些失去了master的资源会被remaster。这种方法是从以前的版本中演变过来的，在以前，所有的资源会被remaster，显然，早先的方法会花更多的时间来完成这个过程。当资源正在remaster的时候，LMS全局缓存服务进程不会处理额外的访问buffer cache中块的请求。那些足够幸运获得处理、且不需要请求更多资源(块)的会话，将会继续工作。其它的所有会话必须等待到市里恢复过程结束。

数据库恢复

当全局缓存资源(数据库块)正在remaster时，服务器监控进程启动恢复集的建立。恢复集(recovery set)是需要恢复的块的集合，SMON服务器监控进程需要将所有线程的在线redo日志进行合并，来完成这个恢复集。

SMON同样执行实例恢复的下一步步骤。前面由SMON决定的需要用于恢复的资源，恢复集，在它们等待恢复的时候要预防其它实例来访问它们。

在这个步骤中，全局资源目录会被解冻。全局资源已经被remaster(分布在存活的集群节点中)，恢复需要的所有数据块被锁住，使得SMON可以对它们应用redo。现在可以准备继续了，buffer cache中的所有其它块都可以让用户访问，系统处于部分可用的状态。和单实例Oracle中一样，一些块脏了，因为它们的对应的事务还没有结束。这些块上的更改应该通过应用undo信息来回退。当恢复集中的所有块都被恢复，且相应的资源被释放后，系统将重新变得完全可用。

这个漫长的讨论阐述了为什么你可能想让实例恢复过程越短越好的原因。首先，也是最主要的，你更愿意保持用户连接和应用继续工作。不幸运的是，RAC中并没有像单实例Oracle中用来在数据库崩溃后控制实例启动时间的参数fast_start_mttr_target。这个参数取代了log_checkpoint_interval、log_checkpoint_timeout和fast_start_io_target。设置fast_start_mttr_target允许Oracle填充V$INSTANCE_RECOVERY视图，可以给管理员一个关于实例恢复大概时间的一个参考。

在恢复的场景中，你可以设置recovery_parallelism为一个非默认的值来增加恢复过程中的从属进程来加快恢复速度(需要parallel_max_servers>0)。

Oracle 10g引入了一个下划线参数叫_fast_start_instance_recovery_target，它能让你影响执行实例恢复需要的时间。和任何一个下划线参数一样，你需要先从Oracle support中了解设置这个参数是否会造成什么不良影响。_fast_start_instance_recovery_target参数控制实例恢复开始到前滚完毕间的最大时间，换句话说，它控制了系统不可用时的时间间隔。

摘自 Pro Database 11g RAC on Linux