概述
1、间隔的产生与自动处理
每当LNS进程停止将重做数据传输到备用数据库，而主数据库却继续提交事务时，就会出现日志文件间隔。每次网络或备用数据库失效时，将
可能产生这种情况，具体取决于DataGuard配置的实现方式。在此状态下，主数据库LGWR进程继续写入到当前ORL，填满ORL后，会切换到一个新ORL，
此时归档进程ARCH会在本地归档已填满的ORL。在繁忙系统中，在主备之间的连接还原前，此虚幻会重复多遍，从而生成很大的日志文件间隔。
在中断期间，DataGuard在主数据库上使用ARCH进程连续ping备用数据库来确定其状态。当还原与备用数据库的通信后，ARCH ping进程会查询
备用控制文件（通过其RFS进程），来确定备用数据库从主数据库收到的最后一个完整日志文件。Data Guard确定需要哪些日志文件来重新同步备用
数据库，然后立即开始使用其他ARCH进程传输相应文件。在接下来执行日志切换时，LNS会试图连接备用数据库，成功后开始传输当前重做数据，而
ARCH进程在后台处理间隔。一旦备用应用进程能赶上当前重做记录的进度，应用进程就自行转换，不再读取归档重做日志，改而读取当前SRL。
最后需要注意的一点是，从DataGuard10g开始，主数据库的一个ARCH进程一直专门负责本地归档，从而确保在处理间隔期间，远程归档操作不影响
主数据库回收其ORL。
自动处理间隔的性能至关重要。主备数据库之间处于非同步状态的时间越久，故障发生时损失数据的风险越大。为使备用数据库赶上进度，
主数据库必须以远超平时生成重做数据的速度传输数据。DataGuard架构允许使用多个后台ARCH进程来快速处理间隔，于此同时，LNS进程像通常
一样执行当前日志流的SYNC或者ASYNC传输。
2、间隔自动处理测试
测试环境：主库为2节点rac，物理备库为单实例
查询主库：
SQL> select process,client_process,thread#,sequence#,status from v$managed_standby;
PROCESS CLIENT_P THREAD# SEQUENCE# STATUS
--------- -------- ---------- ---------- ------------
ARCH ARCH 1 116 CLOSING
ARCH ARCH 1 117 CLOSING
ARCH ARCH 1 118 CLOSING
ARCH ARCH 1 118 CLOSING
LNS LNS 1 116 WRITING
SQL> select thread#, sequence#,status from v$log;
THREAD# SEQUENCE# STATUS
---------- ---------- ----------------
1 119 CURRENT
1 118 ACTIVE
2 83 ACTIVE
2 84 CURRENT
查询备库：
SQL> select process,client_process,thread#,sequence#,status from v$managed_standby;
PROCESS CLIENT_P THREAD# SEQUENCE# STATUS
--------- -------- ---------- ---------- ------------
ARCH ARCH 2 81 CLOSING
ARCH ARCH 0 0 CONNECTED
ARCH ARCH 1 116 CLOSING
ARCH ARCH 2 83 CLOSING
RFS UNKNOWN 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS ARCH 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
11 rows selected.
SQL> select thread#, sequence#,status from v$log;
THREAD# SEQUENCE# STATUS
---------- ---------- ----------------
1 119 CURRENT
1 118 CLEARING
2 83 CLEARING
2 84 CURRENT
停止备库监听，并关闭备库，让主库无法连接
[oracle@oracletest ~]$ lsnrctl stop
LSNRCTL for Linux: Version 12.1.0.1.0 - Production on 27-MAR-2015 14:28:14
Copyright (c) 1991, 2013, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
The command completed successfully
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
在主库执行归档操作，插入数据，在进行归档：
SQL> alter system archive log current;
System altered.
SQL> select thread#, sequence#,status from v$log;
THREAD# SEQUENCE# STATUS
---------- ---------- ----------------
1 119 ACTIVE
1 120 CURRENT
2 85 CURRENT
2 84 ACTIVE
SQL> alter session set container=testpdb;
Session altered.
SQL> select * from test.t1;
C1
----------
2
3
4
1
SQL> insert into test.t1 values(5);
1 row created.
SQL> commit;
Commit complete.
再次归档后查询日志：
SQL> alter system archive log current;
System altered.
SQL> select thread#, sequence#,status from v$log;
THREAD# SEQUENCE# STATUS
---------- ---------- ----------------
1 121 CURRENT
1 120 ACTIVE
2 85 ACTIVE
2 86 CURRENT
此时我们的更改应该在sequence#120（连接的实例thread#为1）的日志上。
再来启动备库看看其日志（注意此时监听仍然关闭）：
SQL> select thread#, sequence#,status from v$log;
THREAD# SEQUENCE# STATUS
---------- ---------- ----------------
1 119 CURRENT
1 118 CLEARING
2 83 CLEARING
2 84 CURRENT
并没有120的日志。
在主库查询：
SQL> col error format a40
SQL> select status,error,synchronized,gap_status
2 from v$archive_dest_status where dest_id=2;
STATUS ERROR SYN GAP_STATUS
--------- ---------------------------------------- --- ------------------------
ERROR ORA-12541: TNS:no listener NO RESOLVABLE GAP
可以看到日志现在是不同步的，且产生了GAP，原因是没有监听。RESOLVABLE GAP表示存在GAP，但可以自动处理。
SQL> select process,client_process,thread#,sequence#,status from v$managed_standby;
PROCESS CLIENT_P THREAD# SEQUENCE# STATUS
--------- -------- ---------- ---------- ------------
ARCH ARCH 1 116 CLOSING
ARCH ARCH 1 117 CLOSING
ARCH ARCH 1 121 CLOSING
ARCH ARCH 1 118 CLOSING
LNS LNS 1 116 WRITING
在备库查询：
SQL> select process,client_process,thread#,sequence#,status from v$managed_standby;
PROCESS CLIENT_P THREAD# SEQUENCE# STATUS
--------- -------- ---------- ---------- ------------
ARCH ARCH 0 0 CONNECTED
ARCH ARCH 0 0 CONNECTED
ARCH ARCH 0 0 CONNECTED
ARCH ARCH 0 0 CONNECTED
现在打开备库的监听，查询备库：
SQL> select thread#, sequence#,status from v$log;
THREAD# SEQUENCE# STATUS
---------- ---------- ----------------
1 123 CURRENT
1 122 CLEARING
2 87 CLEARING
2 88 CURRENT
查询主库：
SQL> select thread#, sequence#,status from v$log;
THREAD# SEQUENCE# STATUS
---------- ---------- ----------------
1 123 CURRENT
1 122 ACTIVE
2 87 ACTIVE
2 88 CURRENT
SQL> select status,error,synchronized,gap_status
2 from v$archive_dest_status where dest_id=2;
STATUS ERROR SYN GAP_STATUS
--------- ---------------------------------------- --- ------------------------
VALID NO LOG SWITCH GAP
此时可以归档传送了但是仍然存在GAP。
过一段时间再次查询主库：
SQL> select status,error,synchronized,gap_status
2 from v$archive_dest_status where dest_id=2;
STATUS ERROR SYN GAP_STATUS
--------- ---------------------------------------- --- ------------------------
VALID NO NO GAP
已经没有GAP了，GAP自动处理完成。
检查备库中的数据：
SQL> alter pluggable database open;
Pluggable database altered.
SQL> select * from test.t1;
C1
----------
2
3
1
由于pdb一直没有打开，数据并没有更新！
检查日志应用：
SQL> select SEQUENCE#,registrar,applied from v$archived_log;
SEQUENCE# REGISTR APPLIED
---------- ------- ---------
103 SRMN YES
104 SRMN YES
105 SRMN YES
71 SRMN YES
72 SRMN YES
73 SRMN YES
74 SRMN YES
106 RFS YES
75 RFS YES
107 RFS YES
76 RFS YES
SEQUENCE# REGISTR APPLIED
---------- ------- ---------
108 RFS YES
109 RFS YES
77 RFS YES
110 RFS YES
111 RFS YES
112 RFS YES
78 RFS YES
113 RFS YES
114 RFS YES
79 RFS YES
115 RFS YES
SEQUENCE# REGISTR APPLIED
---------- ------- ---------
80 RFS YES
117 RFS NO
116 RFS NO
118 RFS NO
81 RFS NO
82 RFS NO
83 RFS NO
119 RFS NO
120 RFS NO
121 RFS NO
122 RFS NO
SEQUENCE# REGISTR APPLIED
---------- ------- ---------
84 RFS NO
85 RFS NO
86 RFS NO
87 RFS NO
37 rows selected.
相应的日志并没有应用，所以数据还没有更新。
由于备库重启过，我们确认一下备库有没有开启实时应用，在主库查询：
SQL> select recovery_mode,dest_id from v$archive_dest_status where dest_id=2;
RECOVERY_MODE DEST_ID
----------------------- ----------
IDLE 2
没有开启！
在备库开启实时应用：
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
在主库确认是否开启：
SQL> select recovery_mode,dest_id from v$archive_dest_status where dest_id=2;
RECOVERY_MODE DEST_ID
----------------------- ----------
MANAGED REAL TIME APPLY 2
实时应用已经开启。
再次在备库观察应用情况：
SQL> select process,client_process,thread#,sequence#,status from v$managed_standby;
PROCESS CLIENT_P THREAD# SEQUENCE# STATUS
--------- -------- ---------- ---------- ------------
ARCH ARCH 2 87 CLOSING
ARCH ARCH 0 0 CONNECTED
ARCH ARCH 0 0 CONNECTED
ARCH ARCH 1 122 CLOSING
RFS ARCH 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS UNKNOWN 0 0 IDLE
RFS LGWR 1 123 IDLE
PROCESS CLIENT_P THREAD# SEQUENCE# STATUS
--------- -------- ---------- ---------- ------------
RFS LGWR 2 88 IDLE
MRP0 N/A 2 88 APPLYING_LOG
13 rows selected.
SQL> select SEQUENCE#,registrar,applied from v$archived_log where applied <> 'YES';
SEQUENCE# REGISTR APPLIED
---------- ------- ---------
117 RFS NO
116 RFS NO
118 RFS NO
81 RFS IN-MEMORY
82 RFS IN-MEMORY
83 RFS IN-MEMORY
119 RFS NO
120 RFS NO
121 RFS NO
122 RFS NO
84 RFS IN-MEMORY
SEQUENCE# REGISTR APPLIED
---------- ------- ---------
85 RFS IN-MEMORY
86 RFS IN-MEMORY
87 RFS IN-MEMORY
14 rows selected.
可以看到开始应用日志了，查询恢复进度：
SQL> col type format a20
SQL> col units format a20
SQL> select start_time,type,sofar,total,units from V$RECOVERY_PROGRESS;
START_TIME TYPE SOFAR TOTAL UNITS
------------ -------------------- ---------- ---------- --------------------
27-MAR-15 Media Recovery 1361 0 KB/sec
27-MAR-15 Media Recovery 37 0 KB/sec
27-MAR-15 Media Recovery 1366 0 KB/sec
27-MAR-15 Media Recovery 20 0 Megabytes
27-MAR-15 Media Recovery 0 0 SCN+Time
27-MAR-15 Media Recovery 32 0 Seconds
27-MAR-15 Media Recovery 563 0 Seconds
27-MAR-15 Media Recovery 1 0 Seconds
8 rows selected.
过一段时间再次查询备库：
SQL> select SEQUENCE#,registrar,applied from v$archived_log where applied <> 'YES';
SEQUENCE# REGISTR APPLIED
---------- ------- ---------
87 RFS IN-MEMORY
87已经应用在内存中了，只是没有写到数据文件，至此日志全部应用完成。
在备库检查数据是否更新：
QL> select * from test.t1;
C1
----------
2
3
4
5
1
数据已经全部更新。
至此，Oracle自动处理了间隔，另外备库重新启动后需要开启实时应用，否则日志可以传送，但并不应用。
最后
以上就是哭泣草丛为你收集整理的Oracle12c_DataGuard中间隔自动处理的测试的全部内容，希望文章能够帮你解决Oracle12c_DataGuard中间隔自动处理的测试所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复