1. Apply服务介绍
Apply服务自动应用redo到备数据库来保持与主数据库的同步和允许事务一致性访问数据。
缺省情况下，Apply服务等待备redo日志文件进行归档，然后再应用归档日志文件包含的redo。然而，可以启用实时Apply，允许当前的备redo日志文件在写入的同时Apply服务应用它包含的redo。
Apply服务使用以下方法来维护物理和逻辑备数据库：
1）Redo Apply（适用物理备数据库）
使用介质恢复来保持主备物理数据库同步。
2）SQL Apply（适用逻辑备数据库）
从主数据库收到的redo中重构SQL语句，然后在逻辑备数据库上执行SQL语句。
2. Apply服务配置
2.1. 使用实时Apply来立即应用redo数据
当启用实时Apply特性时，备数据库收到redo数据时Apply服务可以立即应用redo数据，不需要等待当前备redo日志文件归档后再进行。
这样就可以更快地进行正常切换（switchover）或故障切换（failover），因为在正常切换或故障转换开始时备redo日志文件已经应用到备数据库上。它也在Oracle Active Data Guard备库上通过与主数据库紧密地同步来启用实时报告（real-time reporting）功能。
使用ALTER DATABASE语句可以启用实时Apply特性，如下：
1） 对于物理备数据库，使用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE。（从Oracle Database 12.1版本开始，子语句USING CURRENT LOGFILE被弃用，不再需要来启动实时Apply）。
2） 对于逻辑备数据库，使用ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE语句。
实时Apply要求备数据库上配置了一个备redo日志，并且处于ARCHIVELOG模式。
下图显示Oracle Data Guard配置了一个本地目标和一个备目标。当远程文件服务器（RFS）进程将redo数据写到备数据库上的备redo日志文件时，Apply服务可以从正在写入的备redo日志中恢复（recover）redo。
MRP：managed redo process
LSP：logical standby process
2.2. 指定时间延迟来应用归档redo日志文件
在某些情况下，你可能想要在从主站点接收到redo数据和应用redo到备数据库之间增加一个时间延迟。可以指定一个时间间隔（分钟）来避免应用损坏或错误的数据到备数据库。当设置一个DELAY间隔时，不会延迟传输redo数据到备数据库。当备目标上的redo数据完全归档后指定的时间间隔开始计算。
注：如果为启用了实时apply的目标定义延迟时间，延迟会被忽略。如果按照以下的方法来定义延迟，那么必须使用USING ARCHIVED LOGFILE子语句来启动Apply。
指定时间延迟
可以在主和备数据库上使用初始化参数LOG_ARCHIVE_DEST_n的属性DELAY=minutes来延迟应用归档redo日志文件到备数据库。缺省情况下，没有时间延迟。如果设置DELAY属性但没有指定具体的数值，那么缺省的延迟间隔是30分钟。
取消时间延迟
可以使用以下方法取消指定的延迟间隔：
1） 对于物理备数据库，使用以下语句：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
2） 对于逻辑备数据库，使用以下语句：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
这些命令让Apply服务在指定时间间隔到期前立即开始应用归档redo日志文件到备数据库。
2.2.1. 使用闪回数据库作为备选来设置时间延迟
作为备选方案来设置时间延迟，可以使用闪回数据库从应用了损坏或错误数据的备数据库中恢复。
闪回数据库可以快速和容易地闪回备数据库到任意的时间点。
查看Oracle Data Guard Scenarios章节展示如何在Oracle Data Guard中使用闪回数据库。
3. 应用redo数据到物理备数据库
当执行Redo应用时，物理备数据库可以使用实时Apply特性直接应用从远程文件服务器（RFS）进程写入的备redo日志文件中的redo。
3.1. 启动Redo Apply
为了在物理备数据库上启动Apply服务，确认物理备数据库已启动到mount状态，然后再启动Redo Apply。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
如果备数据库配置了备redo日志并且处于ARCHIVELOG归档模式，命令会自动启用实时Apply。
Redo Apply可以作为前台会话或后台进程运行，上面的语句让Redo Apply在前台会话启动，控制将不会返回到命令提示符直到恢复被其他会话取消为止。
为了让Redo Apply在后台启动，在SQL语句中包括DISCONNECT关键字。
实时应用：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
或
使用归档日志来应用：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING ARCHIVED LOGFILE DISCONNECT;
语句会启动一个分离的服务器进程，立即将控制权返回给用户。当管理恢复进程在后台执行恢复时，发出RECOVER语句的前台进程可以继续执行其他任务。命令不会断开当前的SQL会话。
注：当在还没有从主数据库接收redo数据的物理备数据库上启动Redo Apply时，可能会返回消息ORA-01112。这预示Redo Apply不能确定介质恢复的开始序号（sequence number）。如果出现这个消息，从主数据库手工检索归档redo日志文件，然后在备数据库上注册，或者等待redo传输服务开始，然后再启动Redo Apply。
3.2. 停止Redo Apply
使用以下语句停止Redo Apply：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
3.3. 监控Redo Apply
3.3.1. 视图V$DATABASE
使用视图V$DATABASE来显示数据保护模式，数据保护级别，数据库角色，正常切换状态和快速启动（fast-start）故障切换状态等信息。
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 PRIMARY TO STANDBY
以下查询显示快速启动故障切换状态：
SQL> SELECT FS_FAILOVER_STATUS “FSFO STATUS”, FS_FAILOVER_CURRENT_TARGET TARGET, FS_FAILOVER_THRESHOLD “THRESHOLD”, FS_FAILOVER_OBSERVER_PRESENT “OBSERVER PRESENT” FROM V$DATABASE;
FSFO STATUS TARGET THRESHOLD OBSERVE
------------- -------------- ---------- -------
DISABLED 0
3.3.2. 视图V$DATAGUARD_PROCESS
视图V$DATAGUARD_PROCESS显示每个当前运行的Oracle Data Guard进程。
视图V$DATAGUARD_PROCESS替代V$MANAGED_STANDBY，从12.2.0.1版本开始，V$MANAGED_STANDBY已被弃用。
SQL> SELECT ROLE, THREAD#, SEQUENCE#, ACTION FROM V$DATAGUARD_PROCESS;
ROLE THREAD# SEQUENCE# ACTION
------------------------ ---------- ---------- ------------
recovery apply slave 0 0 IDLE
RFS async 2 50 IDLE
RFS async 1 72 IDLE
archive redo 0 0 IDLE
RFS ping 1 72 IDLE
archive redo 0 0 IDLE
archive redo 0 0 IDLE
archive local 0 0 IDLE
redo transport timer 0 0 IDLE
gap manager 0 0 IDLE
RFS ping 2 50 IDLE
redo transport monitor 0 0 IDLE
log writer 0 0 IDLE
managed recovery 0 0 IDLE
recovery logmerger 1 72 APPLYING_LOG
recovery apply slave 0 0 IDLE
recovery apply slave 0 0 IDLE
recovery apply slave 0 0 IDLE
3.3.3. 视图V$MANAGED_STANDBY
使用视图V$MANAGED_STANDBY查询Redo Apply和redo传输状态。
注：从12.2.0.1版本开始，该视图已过时。
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
------- ------------ ---------- ---------- ---------- ----------
RFS ATTACHED 1 947 72 72
MRP0 APPLYING_LOG 1 946 10 72
示例显示远程文件服务器RFS进程完成归档了序号为947的redo日志文件，Redo Apply正在应用序号为946的归档日志文件。Redo Apply正在恢复含有72个数据块的归档日志文件的数据块10。
3.3.4. 视图V$ARCHIVED_LOG
使用视图V$ARCHIVED_LOG查询从主数据库接收到的物理备数据库或快照备数据库的归档redo日志文件的信息。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG;
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 945 74651 74739
1 946 74739 74772
1 947 74772 74795
3.3.5. 视图V$LOG_HISTORY
使用视图V$LOG_HISTORY查询归档日志历史信息。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$LOG_HISTORY;
3.3.6. 视图V$DATAGUARD_STATUS
使用视图V$DATAGUARD_STATUS查询导致信息被写到告警日志或者服务器进程跟踪文件的Oracle Data Guard事件。
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
3.3.7. 视图V$ARCHIVE_DEST
查询视图V$ARCHIVE_DEST来显示每个redo传输目标的状态和上次应用主数据库的redo到备数据库的SCN。
SQL> SELECT DEST_ID, STATUS, APPLIED_SCN FROM V$ARCHIVE_DEST WHERE TARGET=‘STANDBY’;
DEST_ID STATUS APPLIED_SCN
---------- --------- -----------
2 VALID 6096818
4. 应用redo数据到逻辑备数据库
SQL Apply将归档redo日志或备redo日志转换成SQL语句，然后在逻辑备数据库上执行这些SQL语句。因为逻辑备数据库保持打开的状态，维护的表可以同时被其他任务（如报告，统计和查询等）使用。
4.1. 启动SQL Apply
使用以下语句启动SQL Apply：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
在逻辑备数据库上启动实时应用来立即应用备redo日志文件中的redo数据：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
4.2.停止SQL Apply
使用以下语句在逻辑备数据库上停止SQL Apply：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
当发出语句时，SQL Apply等待直到已经提交正在应用过程中的所有完成的事务为止，因此，命令不会马上停止SQL Apply进程。
4.3.监控SQL Apply
4.3.1.视图DBA_LOGSTDBY_EVENTS
视图DBA_LOGSTDBY_EVENTS记录了SQL Apply操作中发生的事件。
缺省的情况下，视图记录了最近的10,000个事件。可以调用DBMS_LOGSTDBY.APPLY_SET() PL/SQL存储过程来更改记录事件的数量。如果SQL Apply异常停止，问题的原因也记录在视图中。
注：事件也保存在ALERT.LOG文件中，“LOGSTDBY”关键字包含在文本里。当查询视图时，可以使用EVENT_TIME_STAMP，COMMIT_SCN和CURRENT_SCN来对事件进行排序。
视图可以自定义来包含其他信息，例如应用了哪些DDL事务，哪些被忽略。例如：
SQL> ALTER SESSION SET NLS_DATE_FORMAT = ‘DD-MON-YY HH24:MI:SS’;
SQL> COLUMN STATUS FORMAT A60
SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS ORDER BY EVENT_TIMESTAMP, COMMIT_SCN, CURRENT_SCN;
EVENT_TIME STATUS
----------------------------------------------------------------------------
EVENT
----------------------------------------------------------------------------
23-JUL-02 18:20:12 ORA-16111: log mining and apply setting up
23-JUL-02 18:25:12 ORA-16128: User initiated shut down successfully completed
23-JUL-02 18:27:12 ORA-16112: log mining and apply stopping
23-JUL-02 18:55:12 ORA-16128: User initiated shut down successfully completed
23-JUL-02 18:57:09 ORA-16111: log mining and apply setting up
23-JUL-02 20:21:47 ORA-16204: DDL successfully applied
create table hr.test_emp (empno number, ename varchar2(64))
23-JUL-02 20:22:55 ORA-16205: DDL skipped due to skip setting
create database link link_to_boston connect to system identified by change_on_inst
4.3.2.视图DBA_LOGSTDBY_LOG
视图DBA_LOGSTDBY_LOG提供SQL Apply正在处理的归档日志的动态信息。
SQL> COLUMN DICT_BEGIN FORMAT A10;
SQL> SET NUMF 99999999;
SQL> SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS F_SCN#, NEXT_CHANGE# AS N_SCN#, TIMESTAMP, DICT_BEGIN AS BEG, DICT_END AS END, THREAD# AS THR#, APPLIED FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
FILE_NAME SEQ# F_SCN N_SCN TIMESTAM BEG END THR# APPLIED
----------------------- ---- ------- ------- -------- --- --- --- ---------
/oracle/dbs/hq_nyc_3.log 3 101588 142065 11:02:02 NO NO 1 YES
/oracle/dbs/hq_nyc_4.log 4 142065 142307 11:02:10 NO NO 1 YES
/oracle/dbs/hq_nyc_5.log 5 142307 142739 11:02:48 YES YES 1 YES
/oracle/dbs/hq_nyc_6.log 6 142739 143973 12:02:10 NO NO 1 YES
/oracle/dbs/hq_nyc_7.log 7 143973 144042 01:02:11 NO NO 1 YES
/oracle/dbs/hq_nyc_8.log 8 144042 144051 01:02:01 NO NO 1 YES
/oracle/dbs/hq_nyc_9.log 9 144051 144054 01:02:16 NO NO 1 YES
/oracle/dbs/hq_nyc_10.log 10 144054 144057 01:02:21 NO NO 1 YES
/oracle/dbs/hq_nyc_11.log 11 144057 144060 01:02:26 NO NO 1 CURRENT
/oracle/dbs/hq_nyc_12.log 12 144060 144089 01:02:30 NO NO 1 CURRENT
/oracle/dbs/hq_nyc_13.log 13 144089 144147 01:02:41 NO NO 1 NO
在BEG和ENG列的YES值代表LogMiner字典在序号5日志文件开始创建。最近的归档日志文件序号是13，在逻辑备数据库上的接收时间是01:02:41。APPLIED列代表SQL Apply已经应用SCN在144057之前的所有redo。因为事务会跨越多个归档日志文件，多个归档日志文件可能会在APPLIED列显示为CURRENT。
4.3.3.视图V$DATAGUARD_STATS
视图V$DATAGUARD_STATS提供关于故障切换特性相关的信息。
1）故障切换需要的时间（apply finish time）
Apply finish time是预估应用所有接收到的但没有应用完成的redo需要的时间。预估基于redo可以以最大速度应用的假设。实际需要应用所有剩余的redo的时间取决于redo的类型和redo应用的速度。
2）提交的数据当前应用延迟的时间（apply lag）
3）在发生灾难的情况下潜在的数据丢失（transport lag）
SQL> COL NAME FORMAT A20
SQL> COL VALUE FORMAT A12
SQL> COL UNIT FORMAT A30
SQL> SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;
NAME VALUE UNIT
-------------------- ----------------- ------------------------------
apply finish time +00 00:00:00 day(2) to second(1) interval
apply lag +00 00:00:00 day(2) to second(0) interval
transport lag +00 00:00:00 day(2) to second(0) interval
4.3.4.视图V$LOGSTDBY_PROCESS
视图V$LOGSTDBY_PROCESS提供了SQL Apply的各种进程的当前状态。
SQL> COLUMN SERIAL# FORMAT 9999
SQL> COLUMN SID FORMAT 9999
SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS;
SID SERIAL# SPID TYPE HIGH_SCN（进程处理的最大的redo记录）
----- ---- ----- ----------- ----------
48 6 11074 COORDINATOR 7178242899
56 56 10858 READER 7178243497
46 1 10860 BUILDER 7178242901
45 1 10862 PREPARER 7178243295
37 1 10864 ANALYZER 7178242900
36 1 10866 APPLIER 7178239467
35 3 10868 APPLIER 7178239463
34 7 10870 APPLIER 7178239461
33 1 10872 APPLIER 7178239472
SQL> COLUMN STATUS FORMAT A40
SQL> SELECT TYPE, STATUS_CODE, STATUS FROM V$LOGSTDBY_PROCESS;
TYPE STATUS_CODE STATUS
---------- ----------- -----------------------------------------
COORDINATOR 16117 ORA-16117: processing
READER 16127 ORA-16127: stalled waiting for additionaltransactions to be applied
BUILDER 16116 ORA-16116: no work available
PREPARER 16116 ORA-16117: processing
ANALYZER 16120 ORA-16120: dependencies being computed for transaction at SCN 0x0001.abdb440a
APPLIER 16124 ORA-16124: transaction 1 13 1427 is waiting on another transaction
APPLIER 16121 ORA-16121: applying transaction with commit SCN 0x0001.abdb4390
APPLIER 16123 ORA-16123: transaction 1 23 1231 is waiting for commit approval
APPLIER 16116 ORA-16116: no work available
输出显示SQL Apply运行的快照。在挖掘侧，进程READER正在等待额外的空闲内存以读取更多，进程PREPARER正处理redo记录，进程BUILDER没有可做的工作。在应用侧，进程COORDINATOR正在分配更多的事务给APPLIER进程，进程ANALYZER正在计算SCN 7178241034的依赖，一个进程APPLIER没有可做的工作，两个进程APPLIER有未满足的未完成的依赖。
4.3.5. 视图V$LOGSTDBY_PROGRESS
视图提供了SQL Apply取得的进度信息。包含以下：
1）所有在主数据库上提交的事务已经应用到逻辑备数据库的SCN和时间（applied_scn，applied_time）
2）SQL Apply在重启时将开始读取redo记录的SCN和时间（restart_scn，restart_time）
3）在逻辑备数据库上接收到的最近的redo记录的SCN和时间（latest_scn，latest_time）
4）进程BUILDER处理的最近的记录的SCN和时间（mining_scn，mining_time）
SQL> SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN LATEST_SCN MINING_SCN RESTART_SCN
----------- ----------- ---------- -----------
7178240496 7178240507 7178240507 7178219805
SQL> ALTER SESSION SET NLS_DATE_FORMAT=‘yy-mm-dd hh24:mi:ss’;
Session altered
SQL> SELECT APPLIED_TIME, LATEST_TIME, MINING_TIME, RESTART_TIME FROM V$LOGSTDBY_PROGRESS;
APPLIED_TIME LATEST_TIME MINING_TIME RESTART_TIME
----------------- ----------------- ----------------- -----------------
05-05-12 10:38:21 05-05-12 10:41:53 05-05-12 10:41:21 05-05-12 10:09:30
4.3.6. 视图V$LOGSTDBY_STATE
视图提供SQL Apply的当前状态概要。
1）主数据库的DBID（primary_dbid）
2）分配给SQL Apply的LogMiner会话ID（session_id）
3）SQL Apply是否在实时应用（realtime_apply）
SQL> COLUMN REALTIME_APPLY FORMAT a15
SQL> COLUMN STATE FORMAT a16
SQL> SELECT * FROM V$LOGSTDBY_STATE;
PRIMARY_DBID SESSION_ID REALTIME_APPLY STATE
------------ ---------- --------------- ----------------
1562626987 1 Y APPLYING
4.3.7. 视图V$LOGSTDBY_STATS
视图显示SQL Apply应用的统计数字，当前状态和状况。当SQL Apply不运行时视图没有行返回。
SQL> ALTER SESSION SET NLS_DATE_FORMAT=‘dd-mm-yyyy hh24:mi:ss’;
Session altered
SQL> SELECT SUBSTR(name, 1, 40) AS NAME, SUBSTR(value,1,32) AS VALUE FROM V$LOGSTDBY_STATS;
NAME VALUE
---------------------------------------- --------------------------------
logminer session id 1
number of preparers 1
number of appliers 5
server processes in use 9
maximum SGA for LCR cache (MB) 30
maximum events recorded 10000
preserve commit order TRUE
transaction consistency FULL
record skipped errors Y
record skipped DDLs Y
record applied DDLs N
record unsupported operations N
realtime apply Y
apply delay (minutes) 0
coordinator state APPLYING
coordinator startup time 19-06-2007 09:55:47
coordinator uptime (seconds) 3593
来源：《Oracle Data Guard Concepts and Administration, 19c》
1245
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
