本篇主要介绍物理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';