RAC 11.2 体系结构（三）

Standby数据库

 

       RAC主要是一个高可用和可扩展的解决方案，它的好处之一是在实例故障时，能保护系统不会因此导致服务丢失，这在单实例数据库中会导致非计划中断。

       然而，RAC一般不能防止灾难性的站点故障，除非是长距离的集群，这在安装中非常少见。同样的，通常人为的失误会导致数据库逻辑上的错误，比如以下的操作：删除表并禁用flashback table功能、使用不正确的where条件来update数据、把产品环境和开发或测试环境弄混了。

       没有standby数据库的情况下，在这样的事故发生时需要执行flashback database或按时间点的恢复。在现在的大型数据库系统中，按时间点恢复常常不能作为一个选项，因为这意味着全库restore和recovery需要大量的时间。补充一点，RAC被用在很多地方来提供高可用，这也说明了为什么数以小时计的停机时间是不能容忍的。在Oracle 10g中引入的Flashback Database特性大大降低了很多情况下的恢复时间。实际上，Flashback Database特性已经变得非常有用，不仅仅用做在线生产数据库的恢复，同样也用在Data Guard环境中。

 

Oracle Standby数据库的介绍

 

       为了避免站点故障或人为的失误，需要在RAC环境中增加一个额外的预防措施来提供容灾能力。Oracle企业版从7.3版本开始引入了一个特性来满足这个需求，叫做Oracle Data Guard。

       在Oracle 7和8/8i中，这个特性称作standby database。它的原理简单而有效：在一个远程的数据中心实体化一个与在线数据库(或主数据库)完全一样的拷贝。这个备用数据库一直处于介质恢复的状态中，除非以只读方式打开。有一点要注意的是，当该数据库以只读模式打开时，不能应用从主数据库接收到的变化，Oracle 11.1中引入的Active Data Guard选项除外。

       当本身没有问题的时候，变化没有应用会延长备用数据库转变需要的时间，这是因为需要应用额外的归档日志，除非你愿意丢失数据。如果不使用Active Data Guard，数据库需要在mount状态来进行恢复。mount状态会阻止拥有sysdba权限以外的用户连接到数据库，如果尝试连接，会出现ORA-1033 "Oracle initialization or shutdown in progress"的错误信息。

       当Oracle 7.3中引入了standby特性时，维护standby数据库需要大量的手动过程：数据库管理员负责将主数据库产生的归档日志传输到standby站点，使用类似rcp和ftp(rsync)的工具。当日志传输到standby站点后，备用数据库需要处于recovery模式。管理员唯一可能做的就是按顺序启用standby数据库，使其接管主库的角色。DBA拷贝日志的过程称作手动恢复(manual recovery)。

       Oracle 8i开始，standby数据库使用托管的恢复(managed recovery)来与主数据库进行同步。通过Oracle Net*8通讯，主数据库将变化传输到备用数据库，并随后应用到数据文件来保持系统的同步。可以推迟这些变更的实际应用，这样可以保护系统不受上面提到的用户失误的影响。备用数据库同样可以用作报表或备份数据，这样可以从主数据库中分担一些负载。

       Oracle 9i到达了另一个里程碑，它引入了逻辑standby数据库和switchover操作。另外standby数据库特性在Oracle 9i正式更名为Data Guard。Data Guard用户还拥有另一个传输redo信息到standby的选择：原来使用archiver进程来在redo日志归档后传输到standby数据库，现在log writer进程也可以达到这个目标。Standby redo log被引入来对应主数据库的online redo log。于是redo流可以写入到standby redo log中，不想原先需要等待完成归档的redo log，这降低了数据丢失的风险。Oracle 9i数据库还引入了Data Gurad Broker，它支持EM，还有命令行工具，来简化安装和管理standby database的操作。

       Oracle 10g中有一个显著的发展，实时应用特性集成到了数据库内核中。使用备用数据库服务器上的standby redo logs，传输到目的地的redo流可以马上应用到备用数据库中，而不用等待standby redo log归档后应用。它大大降低了数据丢失的可能性。

下图描述了Oracle 11g中的一个示意图，主库中用户活动产生的redo通过日志网络服务器进程(LNS0)——不像前面版本中用log writer——传输到standby数据库的远程文件服务器进程(RFS)中。RFS进程按照顺序将redo流写入到standby redo logs中。备用数据库上的管理恢复进程(MRP0)会立刻应用接收到的信息，当填满的时候，standby redo log会通过standby数据库的其中一个归档进程进行归档。

       这个图显示了11.1中配置为异步redo传输和实时应用的物理standby的示意图。注意11.2中使用NSAn代替LSNn来异步传输redo。

       Oracle 11.1中引入了对数据错误的支持。通过设置一个新的参数db_lost_write_protect可以防止写入丢失，Data Guard同样会在对物理standby应用redo时重新接收检测到的坏块，反之亦然。这个特性叫做自动块介质恢复(Automatic Block Media Recovery)。

       在Oracle 11g R2中，先前10个归档日志目的地(本地和远程)的限制，提升到了可以使用30个standby数据库。当主库是RAC11.2数据库时，将一个standby database中的redo传输到另一个standby数据库的级联standby数据库配置是不可用的(支持读)。

Standby数据库的类型

       你可以选择四种不同类型的standby数据库：Physical standby database, Snapshot standby database, Logical standby database, Transient logical standby database

Physical Standby Database

       物理standby数据库是第一个可用的standby数据库选项。在所有方面，物理standby数据库都是主数据库完全的、比特到比特的的拷贝。所有的schema结构、数据库用户和段都在块的层面上和主库完全一样。

       物理standby数据库通过应用redo(称作redo apply)来与生产库保持同步。这个过程与数据库管理员在数据库发生介质故障后进行的恢复是一样的。除了用在灾难恢复情况外，standby数据库还能用来做报表和备份。通过少量的手工步骤，物理standby数据库还能用来测试生产系统中棘手的升级。你可用通过将standby数据库停止日志接收并以read-write模式启动来打到上述的目的。当测试(在与生产库的数据完全一样的备库上进行的升级测试)完成以后，可以通过flashback database特性来将它还原到打开以前的那个时间点，并变回物理standby。这个过程的缺点就是，当standby数据库以read-write访问模式打开时，它不会从主库继续接收归档的日志，当它转变回物理standby数据库后，会产生大量的网络流量。

Snapshot Standby Database

       Snapshot standby数据库能打到physical standby数据库以read-write打开做测试一样的效果，而且，snapshot数据库不需要管理员来担心那些细节。Snapshot standby会从生产库中接收归档日志，显著降低了解决gap问题的开销。当时，在snapshot standby 数据库转变回physical standby数据库以后，接收到的归档日志才会被应用。因此standby数据库回到与产品库同步的状态需要的时间与需要应用的redo的数量是成比例的。

       当升级一个有对应standby的数据库时，redo传输机制会在主库执行catalog upgrade脚本时确保字典的改变能传播到所有的目的地。这对physical和snapshot standby数据库配置都有效。你需要确保的是standby服务器上的Oracle二进制文件(软件)与主库中的二进制文件完全对应。

       你可以为你的灾难恢复解决方案选择单实例的standby数据库或多节点的RAC系统。但是，要确保你的standby数据库能承当所有的工作负载。建议对生产环境和standby环境使用相同的硬件配置。如果你这么做了，那么你的standby数据库也是一个RAC数据库，所有实例都能从主库中接收redo，从而分担了负载。但是，只有一个实例能够应用redo。

Logical Standby Database

       逻辑standby数据库和物理standby不同，它不是主库严格的1:1的拷贝。逻辑standby数据库配置初期和物理standby是一样的，但它可以以read-write方式打开。在这个阶段，主库和逻辑备库就不一样了。物理(和snapshot)standby数据库通过应用redo日志来和主库保持同步，与此不同的是，逻辑standby数据库通过执行与主库相同的sql语句来实现同步。这个机制一般称作SQL Apply。

       SQL Apply使用log miner特性来从redo流中抽取SQL语句，然后将该SQL语句(而不是redo)应用到standby数据库中。因此，逻辑standby数据库和主库有相同的数据结构，但在物理上很可能是不同的。主库中支持的数据类型是有限制的，这个类型列表随着版本而不断扩大。

       物理和逻辑standby数据库的另一个显著的不同在于逻辑standby数据库常常以read-write方式打开的同时还能从生产库中接收变化。逻辑standby数据库一般不是用作灾难恢复的用途，它主要是用来提供一个做报表的环境，从生产库中分担负载。它提供了数据的高度准确性。事实上，逻辑standby数据库常以read-write方式打开意味着类似索引和物化视图的数据结构可以被额外地创建，来提高查询的速度（这在主库中的维护成本可能会太高）。

       最后，逻辑standby数据库可以用在主库升级版本或应用补丁的过程中，几乎没有停机时间。这个技术在Oracle文档中称作滚动升级(rolling upgrade)。

Transient Logical Standby Database

       Oracle意识到很少有业务愿意只为了滚动升级数据库而配置一个逻辑standby数据库。配置一个逻辑standby数据库不是一个简单的任务，并且维护逻辑standby数据库需要密切关注是否所有事务都被应用。因此，Oracle 11.1提供了将一个物理standby数据库暂时转变为逻辑standby的功能，用于滚动升级数据库。在升级结束后，逻辑standby数据库会转变回最初的物理standby数据库的角色。

       这个类型的standby数据库不在文档中以transient logical standby的名称列出来，但是，它在Oracle Data Guard Concepts and Administration Guide中的第12章中提到，包含了怎么执行数据库的滚动升级。滚动升级的步骤与在升级过程中使用逻辑standby数据库相同，但是，这种逻辑standby数据库的安装被大大简化了。

Active Data Guard

       运行在远程灾难恢复数据中心的standby数据库大部分都是等待被激活的物理standby，很多用户都认为资源没有得到最好的利用。如果使用standby数据库来做备份，当问题发生时，必须从DR站点将磁带转移到主站点中；在另一种情况下，使用standby数据库来做报表和不能在主库上做的特殊查询，也有缺点：当数据库以read-only模式打开，归档日志不能被应用，会导致主备数据库间的不同步，数据变得陈旧。

       从11.1开始，Oracle通过Active Data Guard选项来解除了这个忧虑。购买了企业版以后，这个选项提供了下面的好处：

• • read-only模式中的物理standby数据库可以启用恢复管理，这使得用户可以将对当前产品数据的查询放到备库中，将两者都利用起来。Oracle将这个特性称作实时查询(Real Time Query)。
  • 通过这个选项还能在standby数据库中使用块变化追踪来进行更快的增量备份。

      Active Data Guard还能用作基于网络环境的扩展工具。打个比方，多个standby数据库通过Active Data Guard选项来以read-only方式打开，为web服务器提供实时数据查询。这显著扩展了数据访问。只能在主库上通过一个受控的用户接口来更新数据，然后这些更改会通过Real-Time Query马上呈现给用户。

角色转换

       Data Guard支持两种类型的角色转换：switchover和failover。在switchover操作过程中，主库通过日志切换并等待redo应用到standby中来确保没有数据丢失，然后它才会自己转变为standby数据库。此时，Data Guard配置中的所有数据库都是物理standby数据库，管理员可以选择其它standby数据库中的一个来充当主库的角色。

       当进行如下的维护操作时，Switchover是一个很好的解决方案来最小化需要的时间：

• • 更新硬件
  • 迁移到另一种存储方式中，比如ASM
  • 迁移到另一个存储阵列
  • 转移数据中心
  • 更改数据库的字长
  • 升级数据库和集群版本
  • 升级操作系统

       尽管不能完全取消停机时间，switchover在执行这些任务中的作用经过了验证。

************************************************************************************************************************************************************************************************

switchover的一个典型案例

       在一个硬件升级项目中，我们成功部署了一个switchover。在一个案例中，我们把集群节点数从2个增加到3个，升级了操作系统，修改了底下的存储，还改变了数据库的字长。

       这个要替换的系统由双节点组成，32位的红帽3.9，10.2.0.3的RAC，使用了OCFS第一版。新的系统有3个节点，集群软件和ASM及RDBMS的版本为10.2.0.4，运行在64位的RHEL5.3上。我们使用ASM来代替了OCFS1.同时，远程数据中心的拥有与主库服务器相同配置的standby数据库也可以使用了。

       算上准备工作和健康检查的时间，整个过程只用了一个多小时。

************************************************************************************************************************************************************************************************

       failover用在更严重的情况下，通常是主库已经不能做switchover，可能是因为站点故障或者后端数据丢失。在这种情况下，管理员应该尝试挽救尽可能多的归档日志。DBA同样应该在将standby数据库以read-write模式打开前尽量减少或消除gap。根据使用的Data Guard配置的保护模式，可能会有数据丢失。

       在引入flashback database特性以前，激活standby数据库通常意味着主库需要通过从备份中restore来完全重建。现在，如果发生故障的主数据库启用了flashback，如果启动不会出现问题，重启实例化数据库的时间和工作会少得多。举个例子，如果一个故障数据库在数据中心断电以后重启，可以将其flashback到激活新的主库之前的一个scn。在这里，数据库转变成物理standby只需要很少的命令，当问题解决以后，原来的主库就可以通过一次switchover，就像故障切换发生以前那样来提供服务。

       根据standby数据库的类型(逻辑或是物理)，角色转换到primary会有轻微不同，每个数据库管理员都应该熟悉这些不同的角色转换需要的步骤。应该进行常规的灾难恢复测试，来确保灾难恢复中心的standby数据库和依赖它的整个基础架构(比如负载均衡和应用服务器)能够承担工作量。易懂的文档也很重要，因为它能帮助更多的没什么经验的人员来实现这个目标，并在关键时刻保持冷静。

       提示：涉及到RAC的switchover操作时，在执行switchover命令以前，通常只能留下一个实例，其他的需要关闭。这个限制直到Oracle 11.2才被部分解除。

数据保护模式

       Data Guard提供了三种不同类型的数据保护模式。根据业务的需求，Data Guard可以设置为最大性能模式，不会对主库上的操作造成影响；或者，可以设置为保护数据零丢失。下面是这三种选项的优缺点。

操 作 模 式	描述
最 大 保 护	这个模式提供了最大级别的保护，确保当主库发生故障时没有数据丢失。为了达到这个保护级别，standby数据库必须确认主库中的事务产生的redo已经写入到它的standby redo log中，主库的对应事务才能提交。如果主库不能往备库的standby redo log中写入，它就会关闭以防止数据丢失。数据零丢失的代价是昂贵的：应用的提交时间比其它保护模式中要高，当出现网络问题时，可能会导致主库关闭。
最 大 性 能	这个模式下，standby数据库不会影响主库的性能和可用性。这是默认的保护级别，主备库之间不存在redo写的依赖性，换句话说，主库的事务提交与standby无关。因此，很多业务通过初始化参数ARCHIVE_LAG_TARGET在主库上进行定期的、强制的日志切换。
最 大 可 用	这是在另外两种模式中进行平衡的一个混合模式。主库中提交事务时，至少一个同步的standby数据库必须在它的standby redo log中接收到redo。如果所有的备库都无法接收到redo流，主库会以最大性能模式的方式运行。

Data Guard Broker

       Data Guard broker是构成复制框架的一个主要部分，它可以让你定义Data Gurad配置，包括所有类型的standby数据库。它由RDBMS二进制文件默认安装。它在Oracle 9i中被引入，它很成熟却很少被使用。从用户的角度来看，Data Guard broker 简化了对Data Guard配置的安装、维护和监控，角色切换也是如此，当然，完全支持RAC。集成到企业管理器(EM而非DBConsole)后，安装物理/逻辑standby数据库只需要简单移动鼠标，和少量的键盘输入即可。整合了broker的企业管理器的可用性要比命令行更高。企业管理器功能更加丰富，但需要更多的基础设施。

       在使用的时候，Data Guard broker 通过自己的二进制配置文件和其它后台进程来配置实例启动的相关初始化参数；在这个配置中，它同样会监控数据库。在RAC中，这个配置文件需要存放在共享存储上。ASM、裸设备和集群文件系统可以用来存储这些文件。你不需要将这个配置复制到每个数据库中。相反的，broker会通过将更改复制到所有相关的数据库来自动维持Data Guard配置的单一镜像视图(single image view)。你不用去尝试通过sqlplus输入命令来修改Data Guard配置，因为这些更改可能会在下次Data Guard broker启动时被覆盖掉：一旦成为broker，就一直会是broker。

       概念上，Data Guard broker操作的主要对象是配置、数据库、实例和属性。开始的时候，会创建一个只有主库的配置，然后可以添加多达30个standby数据库，除了他们各自的属性。Data Guard broker会自动检测到数据库是否由多个实例组成，并将它们注册到数据库中。当所有数据库都添加进去之后，管理员会对这次安装感到满意，配置可以启用了。这时，由broker来管理Data Guard环境。

       数据库对象包含一些属性，已经相关的状态信息。根据早些时候的提示，我们不再直接修改初始化参数。作为替代，你可以更改数据库的状态来启用/禁用日志传输或者恢复管理。随着Data Guard的演变，你可以读取和修改的数据库属性在不断增加。下面是你可以修改的一些重要属性：

• Synchronous和asynchronous。同步/异步传输redo到standby
• redo应用到standby数据库中的延迟；这个设置在多standby数据库的环境中防止人为导致的数据错误很有用处。
• redo的压缩。从11.1开始，归档日志可以在gap解决过程中被压缩。Oracle 11.2引入了redo流的压缩，但需要高级压缩选项的license。
• 数据文件名的转换
• 日志文件名的转换
• RAC中应用的首选实例
• 并行应用

       当使用企业管理器的时候，你不需要记住这些属性的名称，而是使用图形用户接口(GUI)来管理Data Guard配置。

       Data Guard broker 包含了对RAC和单实例中修改redo传送和应用服务的支持。另一个好处是，它允许你设置一个无人值守的Data Guard配置来实现自动故障切换。它被称作快速启动故障切换(Fast Start Failover)。通过这个特性，运行在数据库服务器以外的观察进程可以监控主数据库，在一些情况下，可以配置来自动故障切换到standby中。在RAC环境中，只要有一个进程能响应用户请求，broker就认为RAC数据库是可用的。从Oracle 11.1开始，通过DBMS_DG包中可以控制Fast Start Failover选项。在故障切换完成后，Data Guard broker会发出一个FAN时间来指明新的猪数据库已经可以使用了。FAN使用ONS进程来发布时间，因此数据库需要是一个RAC，或是使用了Oracle Restart的单实例数据库。