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   STATUS	SEQUENCE#
--------- ------------ ----------
RFS	  IDLE			0
ARCH	  CLOSING	       67
ARCH	  CONNECTED		0
ARCH	  CLOSING	       74
ARCH	  CLOSING	       73
RFS	  IDLE			0
MRP0	  WAIT_FOR_LOG	       75
RFS	  IDLE		       75

8 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	  IDLE			0	   0	      0 	 0
ARCH	  CLOSING		1	  75	   2048       1792
ARCH	  CONNECTED		0	   0	      0 	 0
ARCH	  CLOSING		1	  74	  43008        625
ARCH	  CLOSING		1	  73	      1        132
RFS	  IDLE			0	   0	      0 	 0
MRP0	  APPLYING_LOG		1	  76	   1869     102400
RFS	  IDLE			1	  76	   1865 	 5

8 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 started
ARC1: Archival started
ARC2: Archival started
ARC2: Becoming the 'no FAL' ARCH
ARC1: Becoming the heartbeat ARCH
ARC1: Becoming the active heartbeat ARCH
Managed Standby Recovery starting Real Time Apply
RFS[1]: Assigned to RFS process 3134
RFS[1]: Database mount ID mismatch [0xfd4b2aab:0xfd4be4d0] (4249561771:4249609424)
RFS[1]: Not using real application clusters
ARC3: Archival started
...........

• V$archive_dest

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