Oracle数据库高可用方案原理介绍

1、 Oracle数据库高可用方案原理介绍AIX专家俱乐部 微信号 AIXchina功能介绍 AIX专家俱乐部是大中型企业IT运维主管技术交流社区，我们在此推送来自社区的原创干货文章及精选资源，包括企业IT基础架构选型、设计、系统集成、实施、测试、运维、合规、调优等。以及虚拟化、云计算、大数据等互联网技术的理论解读、趋势分析。一、概述Oracle作为业界第一的商用数据库，其高可用方案都已经非常成熟，主要有三种高可用方案，下边分别介绍一下。1 RAC（Real Application Clusters）多个Oracle服务器组成一个共享的Cache，而这些oracle服务器共享一个基于网络的存储。这

2、个系统可以容忍单机/或是多机失败。不过系统内部的多个节点需要高速网络互连，基本上也就是要全部东西放在在一个机房内，或者说一个数据中心内。如果机房出故障，比如网络不通，那就坏了。所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要，重要业务需要多机房来容忍单个机房的事故。2 Data Guard.（最主要的功能是冗灾）Data Guard这个方案就适合多机房的。某机房一个production的数据库，另外其他机房部署standby的数据库。Standby数据库分物理的和逻辑的。物理的standby数据库主要用于production失败后做切换。而逻辑的standby数据库则在平时可以分担p

3、roduction数据库的读负载。3 MAAMAA(Maximum Availability Architecture)其实不是独立的第三种，而是前面两种的结合，来提供最高的可用性。每个机房内部署RAC集群，多个机房间用Data Guard同步。二、三种高可用方式工作原理1、Oracle 11G RACRAC环境与单实例最主要的区别是:RAC的每个实例都有属于自己的SGA、后台进程。由于数据文件、控制文件共享于所有实例，所以必须放在共享存储中。联机重做日志文件：只有一个实例可以写入，但是其他实例可以再回复和存档期间读取。归档日志：属于该实例，但在介质恢复期间，其他实例需要访问所需的归档日志。a

4、lter和trace日志：属于每个实例自己，其他实例不可读写。RAC的主要组件包括： 共享磁盘系统 Oracle集群件 集群互联 Oracle内核组件oracle集群件：Oracle集群件能使节点能够互相通信，构成集群，从而这些节点能够像单个逻辑服务器那样整体运行。构成Oracle集群件的后台进程和服务是 crsd、ocssd、oprocd、evmd和ons。Oracle集群件由CRS服务使用OCR和votingdisk进行管理。OCR记录和维持集群及节点的成员资格信息，而votingdisk在通信故障时充当一个仲裁者。在集群运行期间，来自所有节点的一致性心跳信息都会发送给votingdisk

5、。CRS的组件包括，在Linux系统可以通过ps -ef来查看以下进程：crs守护进程crsdOracle集群同步服务守护进程ocssd事件管理器守护进程evmdOracle通知服务ons集群就绪服务：crsd为Oracle集群提供了高可用性的框架，并管理集群资源的状态：启动、停止、监视集群资源，并把发生故障的集群资源重定位到集群中的可用集群节点。集群资源可以是网络资源，如虚拟IP、DB实例、侦听器等。在对集群资源采取任何动作之前，crsd进程都会获取OCR中存储的集群资源配置信息。crsd还使用ocr来维护集群资源配置文件盒状态。每个集群资源都有一个资源配置文件，它存储在OCR中。集群同步服

6、务：ocssd提供节点之间的同步服务。它提供对节点成员关系的访问，并支持基本集群服务，包含集群组服务和集群锁定。ocssd的故障会导致计算机重新启动，以避免”脑裂“（如出现脑裂情况，集群的处理机制请看下面的votingdisk）。注： ”脑裂“ - 集群环境网络链路不能互通，但这些实例仍然正常运作，每个实例都认为其他实例已经挂掉，并尝试接管所有权。在共享存储环境下，如果出现此现象就会发生数据不一致的严重情况。事件管理进程：Event Management (EVM): A background process that publishes events that Oracle Clusterw

7、are creates.一个发布Oracle集群事件产生的进程。The background process that publishes Oracle Clusterware events. EVM scans the designated callout directory and runs all scripts in that directory when an event occurs.Oracle通知服务：在crs启动时会在每个集群节点上启动该进程。只要进群资源的状态发生改变，每个集群节点上的ons进程就会互相通信，并交换HA事件信息。crs触发这些HA事件，并将他们传到ons进程

8、，然后ons进程将这一HA事件信息发布到中间层。为了在中间层使用ONS，对于任何一台主机，只要上面有需要与FAN集成的客户端应用程序，就需要再这台主机上安装ONS。应用程序会出于各种不同原因而使用这些高可用性事件，特别是用于快速检测故障。解决和发布高可用性事件的整个过程称为“快速应用程序通知FAN”。高可用性事件也可称为FAN事件。Oracle 11g r2的集群件启动进程：在R2中Oracle引入了“Oracle高可用性服务”守护进程OHASD，它启动所有其他Oracle集群件守护进程。在安装GI期间，Oracle向/etc/inittab文件配置内容：/etc/init.d/init.oh

9、asd run /dev/null 2&1 set wrap offSQL select process,status,thread#,sequence#,client_pid from v$managed_standby;PROCESS STATUS THREAD# SEQUENCE# CLIENT_PID - - ARCH CONNECTED 0 0 240ARCH CONNECTED 0 0 196ARCH CONNECTED 0 0 1944ARCH CONNECTED 0 0 3956MRP0 WAIT_FOR_LOG 1 30843 N/ARFS RECEIVING 1 30838

10、 2620RFS RECEIVING 1 30837 2612RFS RECEIVING 1 30833 2652RFS ATTACHED 1 30841 2628RFS ATTACHED 1 30835 2604RFS ATTACHED 1 30842 2608已选择11行。（二）数据保护模式Data Guard 允许定义3钟数据保护模式，分别是最大保护（Maximum Protection），最大可用（Maximum Availability）和最大性能（Maximum Performance）。1. 最大保护（Maximum Protection）这种模式能够确保绝无数据丢失。要实现这一

11、步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs，还要同时写入到Standby数据库的Standby Redologs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话（比如网络中断），Primary数据库会被Shutdown，以防止数据丢失。使用这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Stand

12、by Database.2. 最高可用性（Maximum availability）这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保护模式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求Stan

13、dby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.3. 最高性能（Maximum performance）缺省模式。这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时，系统的

14、默认保护模式。这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现，Standby Database也不要求使用Standby Redo Log。4. 修改数据保护模式步骤1）关闭数据库，重启到Mount 状态，如果是RAC，需要关闭所有实例，然后只启动一个实例到mount状态。2）修改模式：语法：ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION | AVAILABILITY | PERFORMANCE;如：SQLALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROT

15、ECTION;3) 打开数据库：alter database open;4) 确认修改数据保护模式：SQLselect protection_mode,protection_level from v$database;（三）自动裂缝检测和解决当Primary Database的某些日志没有成功发送到Standby Database，这时候发生了归档裂缝（Archive Gap）。缺失的这些日志就是裂缝（Gap）。 Data Guard能够自动检测，解决归档裂缝，不需要DBA的介入。这需要配置FAL_CLIENT， FAL_SERVER 这两个参数（FAL: Fetch Archive Log）

16、。从FAL 这个名字可以看出，这个过程是Standby Database主动发起的“取”日志的过程，Standby Database 就是FAL_CLIENT. 它是从FAL_SERVER中取这些Gap， 10g中，这个FAL_SERVER可以是Primary Database，也可以是其他的Standby Database。如：FAL_SERVER=PR1,ST1,ST2;FAL_CLIENT和FAL_SERVER两个参数都是Oracle Net Name。 FAL_CLIENT 通过网络向FAL_SERVER发送请求，FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。但是这

17、两个连接不一定是一个连接。因此FAL_CLIENT向FAL_SERVER发送请求时，会携带FAL_CLIENT参数值，用来告诉FAL_SERVER应该向哪里发送缺少的日志。这个参数值也是一个Oracle Net Name，这个Name是在FAL_SERVER上定义的，用来指向FAL_CLIENT.当然，除了自动地日志缺失解决，DBA 也可以手工解决。具体操作步骤如下：1）查看是否有日志GAP：SQL SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;SQL SELE

18、CT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;2）如果有，则拷贝过来3）手工的注册这些日志：SQL ALTER DATABASE REGISTER LOGFILE 路径;（四）指定日志发送对象1VALID_FOR属性指定传输及接收对象LOG_ARCHIVE_DEST_n参数中的VALID_FOR属性，用来指定传输的内容。从字面理解VALID_FOR就是基于那谁有效，该属性有两个参数值需要指定：REDO_LOG_TYPE和DATABASE_ROLE，我们基本上可以将其理解为：发送指定角色生成的指定类型的日志文件，该参数的

19、主要目的是为了确保，一旦发生角色切换操作后数据库的正常运转。其中，REDO_LOG_TYPE和DATABASE_ROLE两个参数可供选择的参数值如下：REDO_LOG_TYPE：可设置为ONLINE_LOGFILE、STANDBY_LOGFILE、ALL_LOGFILES。DATABASE_ROLE：可设置为PRIMARY_ROLE、STANDBY_ROLE、ALL_ROLES。注意：VALID_FOR参数默认值是：VALID_FOR=（ALL_LOGFILES,ALL_ROLES）。推荐手动设置该参数而不要使用默认值，在某些情况下默认的参数值不一定合适，如逻辑Standby在默认情况下就处于

20、OPEN READ WRITE模式，不仅有REDO数据而且还包含多种日志文件（Online Redologs、Archived Redologs及Standby Redologs）。默认情况下，逻辑Standby数据库生成的归档文件和接收到的归档文件在相同的路径下，这既不便于管理，也极有可能带来一些隐患。建议对每个LOG_ARCHIVE_DEST_n参数设置合适的VALID_FOR属性。本地生成的归档文件和接收到的归档文件最好分别保存于不同路径下。2通过DB_UNIQUE_NAME属性指定数据库DB_UNIQUE_NAME属性是10g版本新增加的一个关键字，在之前版本并没有这一说法。该属性的作

21、用是指定唯一的Oracle数据库名称，也正因有了DB_UNIQUE_NAME，REDO数据在传输过程中才能确认传输到DBA希望被传输到的数据库上。当然要确保REDO数据被传输到指定服务器，除了在LOG_ARCHIVE_DEST_n参数中指定正确DB_UNIQUE_NAME属性之外，还有一个初始化参数LOG_ARCHIVE_CONFIG也需要进行正确的配置。该参数除了指定Data Guard环境中的唯一数据库名外，还包括几个属性，用来控制REDO数据的传输和接收：SEND：允许数据库发送数据到远端。RECEIVE：允许Standby接收来自其他数据库的数据。NOSEND,NORECEIVE：自然

22、就是禁止喽。例如，设置Primary数据库不接收任何归档数据，可以做如下的设置：LOG_ARCHIVE_CONFIG=NORECEIVE,DG_CONFIG= (PRI,ST) 如果做了如上的设置，如果该服务器发生了角色切换，那它也没有接收REDO数据的能力（五） Data Guard环境应配置的初始化参数下列参数为Primary角色相关的初始化参数DB_NAME注意保持同一个Data Guard中所有数据库DB_NAME相同例如：DB_NAME=DaveDB_UNIQUE_NAME为每一个数据库指定一个唯一的名称，该参数一经指定不会再发生变化，除非DBA主动修改它例如：DB_UNIQUE_N

23、AME=DavePreLOG_ARCHIVE_CONFIG该参数用来控制从远端数据库接收或发送REDO数据，通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME（含Primary数据库和Standby数据库），以逗号分隔，SEND/NOSEND属性控制是否可以发送，RECEIVE/NORECEIVE属性控制是否能够接收例如：LOG_ARCHIVE_CONFIG=DG_CONFIG=(DavePre,DaveDG)LOG_ARCHIVE_DEST_n归档文件的生成路径。该参数非常重要，并且属性和子参数也特别多(可以直接查询Oracle官方文档。Data Gu

24、ard白皮书第14章专门介绍了该参数各属性及子参数的功能和设置)。例如：LOG_ARCHIVE_DEST_1=LOCATION=l:/oracle/oradata/Dave VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DavePreLOG_ARCHIVE_DEST_STATE_n是否允许REDO传输服务传输REDO数据到指定的路径。该参数共拥有4个属性值，功能各不相同。REMOTE_LOGIN_PASSWORDFILE推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有DB服务器SYS密码相同以下

25、参数为与Standby角色相关的参数（建议在Primary数据库的初始化参数中也进行设置，这样即使发生角色切换，新的Standby也能直接正常运行）FAL_SERVER指定一个Net服务名，该参数值对应的数据库应为Primary角色。当本地数据库为Standby角色时，如果发现存在归档中断的情况，该参数用来指定获取中断的归档文件的服务器例如：FAL_SERVER=DavePre提示：FAL是Fetch Archived Log的缩写FAL_SERVER参数支持多个参数值的哟，相互间以逗号分隔FAL_CLIENT又指定一个Net服务名，该参数对应数据库应为Standby角色。当本地数据库以Pri

26、mary角色运行时，向参数值中指定的站点发送中断的归档文件例如：FAL_CLIENT=DaveDGFAL_CLIENT参数也支持多个参数值，相互间以逗号分隔。DB_FILE_NAME_CONVERTStandby数据库的数据文件路径与Primary数据库数据文件路径不一致时，可以通过设置DB_FILE_NAME_CONVERT参数的方式让其自动转换。该参数值应该成对出现，前面的值表示转换前的形式，后面的值表示转换后的形式例如：DB_FILE_NAME_CONVERT=f:/oradata/DavePre,l:/oradata/DaveDGLOG_FILE_NAME_CONVERT使用方式与上相

27、同，只不过LOG_FILE_NAME_CONVERT专用来转换日志文件路径例如：LOG_FILE_NAME_CONVERT=f:/oradata/DavePre,l:/oradata/DaveDGSTANDBY_FILE_MANAGEMENT如果Primary数据库数据文件发生修改（如新建、重命名等）则按照本参数的设置在Standby数据库中作相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理例如：STANDBY_FILE_MANAGEMENT=AUTO对于归档失败的处理，LOG_ARCHIVE_DEST_n参数有几个属性，可以用来控制归档过程中出现故障时应该采取的措施。1R

28、EOPEN 指定时间后再次尝试归档使用REOPEN=seconds（默认为300秒）属性，在指定时间重复尝试向归档目的地进行归档操作，如果该参数值设置为0，则一旦失败就不会再尝试重新连接并发送，直到下次REDO数据再被归档时会重新尝试。例如，设置REOPEN为100秒：LOG_ARCHIVE_DEST_2=SERVICE=DavePrimary LGWR ASYNC REOPEN=1002ALTERNATE 指定替补的归档目的地ALTERNATE属性定义一个替补的归档目的地，所谓替补就是一旦主归档目的地因各种原因无法使用，则临时向ALTERNATE属性中指定的路径写。例如：LOG_ARCHIV

29、E_DEST_1=LOCATION=/disk1 ALTERNATE=LOG_ARCHIVE_DEST_2LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_2=LOCATION=/disk2LOG_ARCHIVE_DEST_STATE_2=ALTERNATE上述参数设置归档路径为/disk1，当/disk1路径下无法成功归档时，自动尝试向/disk2路径下归档文件。从功能上来看，REOPEN与ALTERNATE是有一定重复的，不过需要注意一点，REOPEN属性比ALTERNATE属性的优先级要高，如果你指定REOPEN属性的值0，则LGWR（或AR

30、Cn）进程会首先尝试向主归档目的地写入，直到达到最大重试次数，如果仍然写入失败，才会向ALTERNATE属性指定的路径写。3MAX_FAILURE 控制失败尝试次数用REOPEN指定失败后重新尝试的时间周期，MAX_FAILURE则控制失败尝试的次数。例如，设置LOG_ARCHIVE_DEST_1在本地归档文件时，如果遇到错误，则每隔100秒尝试一次，共尝试不超过3次，设置如下：LOG_ARCHIVE_DEST_1=LOCATION=E:/ora10g/oradata/jsspdg/ REOPEN=100 MAX_FAILURE=3（六）物理Standby 和逻辑Standby 的区别Stan

31、dby数据库类型分为两类：物理Standby和逻辑Standby。1物理Standby我们知道物理Standby与Primary数据库完全一模一样，DG通过REDO应用来维护物理Standby数据库。通常在物理Standby没有执行REDO应用操作的时候，可以将物理Standby数据库以READ ONLY模式打开，如果数据库中指定了Flashback Area的话，甚至还可以被临时性的置为READ WRITE模式，操作完之后再通过Flashback Database特性恢复回READ WRITE前的状态，以便继续接收Primary端发送的REDO并应用。REDO应用。物理Standby通过RE

32、DO应用来保持与Primary数据库的一致性，所谓的REDO应用，实质是通过Oracle的恢复机制，应用归档文件（或Standby Redologs文件）中的REDO数据。恢复操作属于块对块的应用。如果正在执行REDO应用的操作，Oracle数据库就不能被Open。READ ONLY模式打开。以READ ONLY模式打开后，可以在Standby数据库执行查询或备份等操作（变相减轻Primary数据库压力）。此时Standby数据库仍然能够继续接收Primary数据库发送的REDO数据，不过并不会应用，直到Standby数据库重新恢复REDO应用。也就是说在READ ONLY模式下不能执行RED

33、O应用，REDO应用时数据库肯定处于未打开状态。如果需要的话，你可以在两种状态间转换，如先应用REDO，然后将数据库置为READ ONLY状态，需要与Primary同步时再次执行REDO应用命令，切换回REDO应用状态。呵呵，人生就是循环，数据库也是一样。提示：Oracle 11g版本中增强物理Standby的应用功能，在11g版本中，物理Standby可以在OPEN READ ONLY模式下继续应用REDO数据，这就极大地提升了物理Standby数据库的应用场合。READ WRITE模式打开。如果以READ WRITE模式打开，那么Standby数据库将暂停从Primary数据库接收REDO

34、数据，并且暂时失去灾难保护的功能。当然，以READ WRITE模式打开也并非一无是处，如你可能需要临时调试一些数据，但又不方便在正式库中操作，那就可以临时将Standby数据库置为READ WRITE模式，操作完之后将数据库闪回到操作前的状态（闪回之后，Data Guard会自动同步，不需要重建物理Standby，不过如果从另一个方向看，没有启动闪回，那就回不到READ WRITE前的状态了）。物理Standby特点如下：（1）灾难恢复及高可用性。物理Standby提供了一个健全、高效的灾难恢复，以及高可用性的解决方案。更加易于管理switchover/failover角色转换及在更短的计划内

35、或计划外停机时间。（2）数据保护。使用物理Standby数据库，DG能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理Standby是基于块对块的复制，因此与对象、语句无关，Primary数据库上有什么，物理Standby数据库端也会有什么。（3）分担Primary数据库压力。通过将一些备份任务、仅查询的需求转移到物理Standby数据库，可以有效节省Primary数据库的CPU及I/O资源。（4）提升性能。物理Standby所使用的REDO应用技术使用最底层的恢复机制，这种机制能够绕过SQL级代码层，因此效率最高。2逻辑Standby逻辑Standby也要通过Primary数据库

36、（或其备份，或其复制库，如物理Standby）创建，因此在创建之初与物理Standby数据库类似。不过由于逻辑Standby通过SQL应用的方式应用REDO数据，因此逻辑Standby的物理文件结构，甚至数据的逻辑结构都可以与Primary不一致。与物理Standby不同，逻辑Standby正常情况下是以READ WRITE模式打开，用户可以在任何时候访问逻辑Standby数据库，就是说逻辑Standby是在OPEN状态执行SQL应用。同样有利也有弊，由于SQL应用自身特点，逻辑Standby对于某些数据类型及一些DDL/DML语句会有操作上的限制。可以在视图DBA_LOGSTDBY_UNSU

37、PPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。逻辑Standby 的读写打开可以使它做报表系统，这样减轻系统的压力。除了上述物理Standby中提到的类似灾难恢复、高可用性及数据保护等特点之外，逻辑Standby还有下列一些特点：（1）有效地利用备机的硬件资源。除灾难恢复外，逻辑Standby数据库还可用于其他业务需求。如通过在Standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要；又如创建新的SCHEMA（该SCHEMA在Primary数据库端并不存在），然后在这些SCHEMA中执行那些不适于在Primary数据库端执行的DD

38、L或者DML操作等。（2）分担Primary数据库压力。逻辑Standby数据库可以在保持与Primary同步时仍然置于打开状态，这使得逻辑Standby数据库能够同时用于数据保护和报表操作，从而将主数据库从报表和查询任务中解脱出来，节约宝贵的 CPU和I/O资源。（3）平滑升级。可以通过逻辑Standby来实现如跨版本升级，为数据库打补丁等操作。应该说应用的空间很大，而带来的风险却很小（前提是如果你拥有足够的技术实力。另外虽然物理Standby也能够实现一些升级操作，但如果跨平台的话恐怕就力不从心了，所以此项没有作为物理Standby的特点列出），我个人认为这是一种值得可行的在线的滚动的平滑

39、的升级方式，如果你的应用支持创建逻辑Standby的话。（七） Log应用服务（Log Apply Services）Data Guard通过应用REDO维持Primary数据库与各Standby数据库之间的一致性，在后台默默无闻地支撑着的就是传说中的Log应用服务。Log应用服务又分以下两种方式：REDO应用：物理Standby数据库专用，通过介质恢复的方式保持与Primary数据库的同步。SQL应用：逻辑Standby数据库专用，核心是通过LogMiner分析出SQL语句在Standby端执行。因此物理Standby在应用REDO数据时必须是MOUNT状态，而逻辑Standby则是以REA

40、D WRITE模式打开并应用REDO数据，不过被维护的对象默认处于只读状态，无法在逻辑Standby端直接修改。7.1 Log应用服务配置选项默认情况下，Log应用服务会等待单个归档文件全部接收之后再启动应用，如果Standby数据库配置了Standby Redologs，就可以打开实时应用（Real-Time Apply），这样Data Guard就不需要再等待接收完归档文件，只要RFS进程将REDO数据写入Standby Redologs，即可通过MRP/LSP实时写向Standby数据库。7.1.1REDO数据实时应用启动实时应用的优势在于，REDO数据不需要等待归档完成，接收到即可被应

41、用，这样执行角色切换时，操作能够执行得更快，因为日志是被即时应用的。要启动实时应用也简单，前提是Standby数据库端配置了Standby Redologs物理Standby要启用实时应用，要在启动REDO应用的语句后附加USING CURRENT LOGFIE子句，例如：SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE ;逻辑Standby要启用实时应用，只需要在启动REDO应用的语句后附加IMMEDIATE子句即可，例如：SQL ALTER DATABASE START LOGICAL STA

42、NDBY APPLY IMMEDIATE;7.1.2REDO数据延迟应用有实时就有延迟，某些情况下你可能不希望Standby数据库与Primary太过同步，那就可以在Primary数据库端发送REDO数据的相应LOG_ARCHIVE_DEST_n参数中指定DELAY属性（单位为分钟，如果指定了DELAY属性，但没有指定值，则默认是30分钟）。注意：该属性并不是说延迟发送REDO数据到Standby，而是指明归档到Standby后，开始应用的时间。例如：设置LOG_ARCHIVE_DEST_3的DELAY属性为15分钟：SQL ALTER SYSTEM SET LOG_ARCHIVE_DEST_

43、3=SERVICE=DavePrimary ARCH VALID_ FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=Dave DELAY=15;不过，如果DBA在启动REDO应用时指定了实时应用，那么即使在LOG_ ARCHIVE_DEST_n参数中指定了DELAY属性，Standby数据库也会忽略DELAY属性。另外，Standby端还可以在启动REDO应用时，通过附加NODELAY子句的方式，取消延迟应用。物理Standby可以通过下列语句取消延迟应用：SQL ALTER DATABASE RECOVER MANAGED STANDBY

44、 DATABASE NODELAY;逻辑Standby可以通过下列语句取消延迟应用：SQL ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;一般设置延迟应用的需求都是基于容错方面的考虑，如Primary数据库端由于误操作，数据被意外修改或删除，只要Standby数据库尚未应用这些修改，你就可以快速从Standby数据库中恢复这部分数据。不过自Oracle从9i版本开始提供FLASHBACK特性之后，对于误操作使用FLASHBACK特性进行恢复，显然更加方便快捷，因此DELAY方式延迟应用已经非常少见了。7.2 应用REDO数据到Standb

45、y数据库7.2.1物理Standby应用REDO数据物理Standby启动REDO应用，数据库要处于MOUNT状态或是OPEN READ ONLY状态，启动REDO应用的命令相信大家已经非常熟悉了。前台应用：SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;语句执行完成后，不会将控制权返回到命令行窗口，除非你手动中止应用。在这种情况下如果还需要对数据库进行操作，只能新开一个命令行连接，在Oracle 8i刚推出Standby特性时（那时不叫Data Guard），只提供了这种方式。后台应用：SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;这是现在比较通用的方式，语句执行完后，控制权自动返回到当前的命令行模式，REDO应用以后台进程运行。启动实时应用，附加USING CURRENT LOGFILE子句即可：SQL