Oracle 11g Data Guard Redo应用服务

本篇主要介绍物理STANDBY数据库使用Real-Time Apply应用Redo数据，使用介质恢复来保持主数据库和备用数据库的数据同步。

一 Real-Time Apply Service

LGWR进程同步传输Redo数据的过程如图，首先，用户将事务变化写入重做日志缓冲区，满足一定条件后启动LGWR进程将Redo数据写入本地在线重做日志文件，同时LGWR进程启动了LNSn（LGWR Network Server Process）进程把Redo数据传输到STANDBY数据库端，在STANDBY数据库端的RFS（Remote File Server）进程接收Redo并写入STANDBY重做日志文件，如果此时启用了实时应用则使用SQL应用或Redo应用将Redo数据应用到STANDBY数据库，如果没有启动实时应用，则将redo数据写入STANDBY重做日志文件，在redo数据写入STANDBY数据库前主数据库端的事务不会结束。

                

二 应用Redo数据至物理STANDBY数据库

默认情况下，重做数据通过归档重做日志文件被应用。当执行 Redo应用时，物理STANDBY数据库使用Real-Time Apply特性直接从通过RFS写入的STANDBY Redo log应用redo 。

1、启动Redo Apply

在物理STANDBY数据库上启动应用服务，需确保物理STANDBY数据库启动并处于Mount状态，然后使用Alter database recover managed standby database语句启动Redo应用。

可以指定Redo应用作为前台会话或者后台进程运行，并激活实时应用。

• 在前台启动Redo Apply

SQL> alter database recover managed standby database;

如果以前台会话启动，在恢复被另一个会话取消之前，控制权不会返回到命令提示符。

• 在后台启动Redo Apply

SQL> alter database recover managed standby database disconnect;Database altered.SQL> select process,status ,sequence# from v$managed_standby;PROCESS   STATUSSEQUENCE#--------- ------------ ----------RFS  IDLE0ARCH  CLOSING       67ARCH  CONNECTED0ARCH  CLOSING       74ARCH  CLOSING       73RFS  IDLE0MRP0  WAIT_FOR_LOG       75RFS  IDLE       758 rows selected.

这个语句启动一个独立的服务器进程，并立即将控制权返回给用户，当管理的恢复进程在后台进行恢复的时，执行恢复语句的前台进程可以继续执行其他任务，这并没有断开当前的SQL会话。

• 启动实时应用

SQL> alter database recover managed standby database using current logfile;

2、停止Redo Apply

SQL> alter database recover managed standby database cancel;Database altered.

3、监控Redo Apply

• V$database

SQL> select protection_mode,protection_level,database_role,switchover_status from v$database;PROTECTION_MODE      PROTECTION_LEVEL  DATABASE_ROLE    SWITCHOVER_STATUS-------------------- -------------------- ---------------- --------------------MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE  PHYSICAL STANDBY NOT ALLOWED

• V$managed_standby

SQL> select process,status,thread#,sequence#,block#,blocks from v$managed_standby;PROCESS   STATUS  THREAD#  SEQUENCE# BLOCK#     BLOCKS--------- ------------ ---------- ---------- ---------- ----------RFS  IDLE0   0      0  0ARCH  CLOSING1  75   2048       1792ARCH  CONNECTED0   0      0  0ARCH  CLOSING1  74  43008        625ARCH  CLOSING1  73      1        132RFS  IDLE0   0      0  0MRP0  APPLYING_LOG1  76   1869     102400RFS  IDLE1  76   1865  58 rows selected.

• V$archived_log

SQL> select thread#,sequence#,first_change#,next_change# from v$archived_log;   THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#---------- ---------- ------------- ------------ 1   74    1200127 1212597 1   75    1212597 1213494

• V$log_history

SQL> select thread#,sequence#,first_change#,next_change# from v$log_history;   THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#---------- ---------- ------------- ------------ 1    1     925702  956418 1    2     956418  956928 1    3     956928  971683

• V$dataguard_status

SQL> select message from v$dataguard_status;MESSAGE----------------------------------------------------------------------------------------------------------------------ARC0: Archival startedARC1: Archival startedARC2: Archival startedARC2: Becoming the 'no FAL' ARCHARC1: Becoming the heartbeat ARCHARC1: Becoming the active heartbeat ARCHManaged Standby Recovery starting Real Time ApplyRFS[1]: Assigned to RFS process 3134RFS[1]: Database mount ID mismatch [0xfd4b2aab:0xfd4be4d0] (4249561771:4249609424)RFS[1]: Not using real application clustersARC3: Archival started...........

• V$archive_dest

SQL> select dest_id,applied_scn from v$archive_dest where target='STANDBY';