合 Oracle DG环境中的gap处理办法总结
Tags： Oracle故障处理高可用DG丢失归档归档日志gap
概述
当主库的某些日志没有成功传送到备库，那么这时候就发生了归档裂缝（Archive Gap）。目前Oracle提供了两种日志GAP的检测和处理机制，分别是自动GAP处理（Automatic Gap Resolution）和FAL进程GAP处理（FAL Gap Resolution）。自动GAP处理即主库上的ARCn进程会每分钟检查备库上的日志GAP情况并做相应处理。FAL（Fetch Archive Log）是通过配置FAL_SERVER和FAL_CLIENT实现GAP检测的一种机制，它是备库主动发起的“取”日志的过程。备库就是FAL_CLIENT，它从FAL_SERVER中取这些GAP。Oracle会首先尝试使用FAL进程处理GAP，当发现FAL机制并没有配置生效的时候，进而尝试使用自动GAP处理。FAL进程只在物理备库存在。FAL进程提供了一个CLIENT/SERVER的机制，用来解决检测在主库产生的连续的归档日志，而在备库接受的归档日志不连续的问题。该进程只有在需要的时候才会启动，而当工作完成后就关闭了，因此在正常情况下，该进程是无法看见的。
大致可以分为以下几种情况来处理：
1、主库归档日志存在，可以通过配置Fetch Archive Log(FAL)参数，自动解决归档GAP，或将归档日志拷贝到从库手工注册处理。
2、主库归档日志丢失，需要人工干预来修复，可以分为如下几种情况：
① 12c版本之前的常规处理步骤：
1.在主库上创建一个备库的控制文件
2.以备库的当前SCN号为起点，在主库上做一个增量备份
3.将增量备份拷贝到备库上
4.使用新的控制文件将备库启动到mount状态
5.将增量备份注册到RMAN的catalog，取消备库的恢复应用，恢复增量备份
6.开启备库的恢复进程
② 从12c开始：RECOVER … FROM SERVICE
③ 从18c开始：RECOVER STANDBY DATABASE FROM SERVICE
Oracle随着版本的升级，逐渐将步骤缩减，进行封装，18C之后可谓是达到了所谓的一键刷新，恢复DG同步。
处理GAP方法1：手动拷贝归档到备库进行手工注册处理，归档未丢失
（一）物理DG手动解决GAP
在一些特殊情况下，如果GAP不能自动解决，那么就需要手工执行中断恢复。通过查询视图V$ARCHIVE_GAP可以确定断档的是哪些日志。
1 2 3 4 | SQL> SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ----------- ------------- -------------- 1 10 12 |
可以看到，当前物理备库丢失日志文件从线程1的序号10到序号12。接下来确定归档日志文件的路径：（假设在主数据库上的本地归档目的地是LOG_ARCHIVE_DEST_1）：
1 2 3 4 5 6 | SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 10 AND 12; NAME ----------------------------------------------------------------- /arch/thread1_dest/arch_1_10.arc /arch/thread1_dest/arch_1_11.arc /arch/thread1_dest/arch_1_12.arc |
接下来，复制这些日志文件到物理备库，然后在物理备库上使用“ALTER DATABASE REGISTER LOGFILE”语句来注册这些归档日志，如下所示：
1 2 3 4 5 | SQL> ALTER DATABASE REGISTER LOGFILE '/arch/thread1_dest/arch_1_10.arc'; -- 也可以使用如下的SQL语句： ALTER DATABASE REGISTER OR REPLACE LOGFILE '/arch/thread1_dest/arch_1_10.arc'; ALTER DATABASE REGISTER OR REPLACE PHYSICAL LOGFILE '/arch/thread1_dest/arch_1_11.arc'; |
在物理备库上注册这些日志文件之后，重新打开重做应用进程。如果断档的归档日志较多，那么可以使用如下的SQL语句来生成要执行的SQL语句（如下的SQL也适用于逻辑DG）：
1 2 3 4 | SELECT 'ALTER DATABASE REGISTER OR REPLACE LOGICAL LOGFILE ''/arch/thread1_dest/arch_1_' || a ||'.arc'';' LOGICAL_DG, 'ALTER DATABASE REGISTER OR REPLACE LOGFILE ''/arch/thread1_dest/arch_1_' || a ||'.arc'';' PHYSICAL_DG FROM (SELECT LEVEL A FROM DUAL CONNECT BY LEVEL <= 12) WHERE A >= 10 ; |
需要注意的是，视图V$ARCHIVE_GAP只返回当前妨碍重做应用继续的下一个中断。在解决中断并重启重做应用进程后，再次在物理备库上查询V$ARCHIVE_GAP视图来确定下一个中断序号，如果有的话，重复这个过程直到没有更多的中断。
（二）逻辑DG手动解决GAP
在逻辑备库上查询DBA_LOGSTDBY_LOG视图可以确定是否有归档中断。例如，下面的查询指出断档号为16至18：
1 2 3 4 5 6 7 8 9 | SYS@orclasm > COLUMN FILE_NAME FORMAT a60 SYS@orclasm > SELECT THREAD#, SEQUENCE#, FILE_NAME 2 FROM DBA_LOGSTDBY_LOG L 3 WHERE NEXT_CHANGE# NOT IN (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) 4 ORDER BY THREAD#, SEQUENCE#; THREAD# SEQUENCE# FILE_NAME --------- ---------- --------------------------------------------- 1 16 /arch/oracle/arch_1_16.arc 1 18 /arch/oracle/arch_1_18.arc |
接下来复制丢失的日志文件到逻辑备库，并在逻辑备库上使用“ALTER DATABASE REGISTER LOGICAL LOGFILE”来注册这些日志文件。例如：
1 | SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/arch/oracle/arch_1_16.arc'; |
在逻辑备库上注册这些日志文件之后，重启SQL应用。和物理DG一样，在逻辑备库上的DBA_LOGSTDBY_LOG视图只返回当前妨碍SQL应用继续的下一个中断。在解决指定的中断并重启SQL应用之后，再次在逻辑备库上查询DBA_LOGSTDBY_LOG视图，以确定下一个中断序号，如果有的话，重复这个过程直到没有更多的中断。
需要注意的是，如果需要的归档日志已经不在主库上了，但是有归档日志的RMAN备份，那么可以通过RMAN恢复把缺少的归档日志进行还原，如下所示：
1 2 | SET ARCHIVELOG DESTINATION TO '/arch'; RESTORE ARCHIVELOG FROM LOGSEQ 7; |
处理GAP方法2：主库基于SCN的增量备份来恢复DG（常规办法）
如果断档的归档日志已经丢失，且RMAN又没有备份，那么在Oracle 10g之前没有办法修复了，只能重建DG，但是从Oracle 10g开始可以采用主库基于SCN的增量备份来恢复DG，请参考：
https://www.dbaup.com/dghuanjingzhukudiushiguidangqingkuangxiashujuwenjiandehuifu.html
https://www.dbaup.com/rachuanjingxiazhukudiushiguidangbeikudgdehuifuguocheng.html
https://www.dbaup.com/wulidgzaizhukudiushiguidangwenjiandeqingkuangxiadehuifu.html
从12c开始：RECOVER … FROM SERVICE
从18c开始：RECOVER STANDBY DATABASE FROM SERVICE
Oracle在18c对(RESTORE/RECOVER ...FROM SERVICE)功能进行了加强，推出了(RECOVER STANDBY DATABASE ... FROM SERVICE)通过网络服务直接增量恢复备库数据,这个新特性也大大简化了DataGuard主备的问题修复。
示例
下面我们通过实验来进行展示：
首先，模拟备库断电，主库切几个最新的归档，然后手工删掉，重新开启DG同步。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 | ##备库： ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; shutdown immediate ##主库： alter system switch logfile;多次切归档 ##删除最近几个归档日志： rm 1_34_1070147137.arc rm 1_33_1070147137.arc ##备库： startup ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; ##查看GAP SQL> SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- 1 32 34 SQL> SELECT max(sequence#) from v$archived_log where applied='YES'; MAX(SEQUENCE#) -------------- 31 SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS --------- ------------ ---------- ---------- ---------- ---------- ARCH CLOSING 1 38 1 40 ARCH CLOSING 1 39 1 2 ARCH CONNECTED 0 0 0 0 ARCH CLOSING 1 37 1 2 RFS IDLE 0 0 0 0 RFS IDLE 0 0 0 0 RFS IDLE 1 40 83 1 MRP0 APPLYING_LOG 1 33 1 245760 8 rows selected. |
12之前
当前GAP：32---34
1.在主库上创建一个备库的控制文件
1 2 3 4 | SQL> alter database create standby controlfile as '/tmp/standby.ctl'; Database altered. |
2.以备库的当前SCN号为起点，在主库上做一个增量备份
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | -- 备库 SQL> select to_char(current_scn) from v$database; TO_CHAR(CURRENT_SCN) ---------------------------------------- 1086639 -- 主库 rman target / run{ allocate channel c1 type disk; allocate channel c2 type disk; backup INCREMENTAL from scn 1086639 database format '/tmp/incre_%U'; release channel c1; release channel c2; } |
3.将增量备份拷贝到备库上
