当前位置： 首页 > news >正文

Oracle DG主备架构中GAP（归档裂缝）处理方法总结

news 2026/7/8 13:03:49

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检测的一种机制，**备库主动发起的“取”(fetch)**日志的过程。备库就是FAL_CLIENT，它从FAL_SERVER中取这些GAP。

特点：

1、Oracle会首先尝试使用FAL进程处理GAP，当发现FAL机制并没有配置生效的时候，进而尝试使用自动GAP处理。

2、FAL进程只在物理备库存在。

3、FAL进程提供了一个CLIENT/SERVER的机制，用来解决检测在主库产生的连续的归档日志，而备库接收的归档日志不连续的问题。

4、FAL进程只有在需要的时候才会启动，而当工作完成后就关闭了，因此在正常情况下，该进程是无法看见的。

二、GAP处理方法

当自动GAP处理和FAL进程GAP处理，都无法处理GAP时，就需要人工进行干预，GAP处理方法主要有如下两类：

1、主库归档日志未丢失，Oracle提供了两种日志GAP的检测和处理机制未正常处理，主要有两种处理方法：1）通过11g版本开始的flush redo特性尝试处理；2）将主库的归档日志手工拷贝到备库服务器上，并手工注册归档日志，让备库识别和同步这些归档日志；

2、主库归档日志出现丢失，这种情况需要人工干预来修复。

三、GAP（主库归档日志未丢失）处理

（一）flush redo方法

在Oracle 11g开始，Data Guard 切换多了一个新的功能：flush redo。
Flush 能把没有发送的redo 从主库传送到standby库。 只要主库能启动到mount 状态，那么Flush 就可以把没有发送的归档和current online redo 发送到备库。

Flush语法：

ALTER SYSTEM FLUSH REDO TO ‘target_db_name’ [ no confirm apply];

注意：

1）targe_db_name表示备库的db_unique_name
2）必须加上引号
3）主库（Primary Database）必须处于 Mount 状态，才能执行该命令
4）no confirm apply ，表示主库将redo数据发送到备库，但不等待备库的应用确认，就直接返回成功。此时命令变为异步操作，只要主库确认 redo 数据已成功发送到备库的日志文件中，命令就视为成功，不再关心备库是否完成了应用。
5）不带no confirm apply，表示主库将 redo 数据发送到备库，并等待备库确认这些 redo 数据已经成功应用后，才返回成功。此时FLUSH REDO 命令是一个同步操作，它会阻塞，直到备库确认所有发送过去的 redo 都已被成功应用

（二）手工传输归档日志和注册的方法

1、物理备库上执行如下SQL，判断是否存在gap

SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ----------- ------------- -------------- 1 40 43

2、主库上查询确认

SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 41 AND 43; NAME ------------------------------------------------------------------------------- /oradata/arch/1_41_1236681669.dbf /oradata/arch/1_42_1236681669.dbf

3、把这些归档日志复制、传输至物理备库服务器归档目录

[oracle@host31 arch]$ scp 1_41_*.dbf 1_42_*.dbf host32:/oradata/arch oracle@host32's password: 1_41_1236681669.dbf 100% 58KB 49.6MB/s 00:00 1_42_1236681669.dbf 100% 20KB 25.7MB/s 00:00 备注：如果需要的归档日志已经不在主库服务器上了，但是有归档日志的RMAN备份，那么可以通过RMAN恢复把缺少的归档日志进行还原，类似如下： rman target / set archivelog destination to '/oradata/arch'; restore archivelog from logseq 40;

4、备库上使用ALTER DATABASE REGISTER LOGFILE应用这些归档

ALTER DATABASE REGISTER LOGFILE '/oradata/arch/1_41_1236681669.dbf'; ALTER DATABASE REGISTER LOGFILE '/oradata/arch/1_42_1236681669.dbf'; 备库上最大的日志序列号变为42，表示已经自动应用手工注册的归档日志 select inst_id,max(sequence#) ,min(sequence#) from gv$archived_log group by inst_id order by 1; INST_ID MAX(SEQUENCE#) MIN(SEQUENCE#) ---------- -------------- -------------- 1 42 35

备注：注册完成后，备库会自动应用这些归档日志，完成主备同步

5、可选！！如果后续是准备failover并打开数据库，传输完主库的归档后，可以继续使用主库的当前REDO恢复，尽量确保数据恢复最大化（甚至主备数据一致！）

1）主库上，将redo日志传输至备库 scp /oradata/orcl/redo*.log host32:/oradata/orcl 2）备库上，确保备库mount状态 alter database recover managed standby database cancel; //先取消日志恢复 shutdown immediate; //关闭数据库 startup mount; //启动备库至mount状态 3）备库执行不完全恢复 recover standby database until cancel; //备库执行不完全恢复，通过主库传输过来的redo进行尝试 ORA-00279: change 1042670 generated at 06/29/2026 14:07:49 needed for thread 1 ORA-00289: suggestion : /oradata/arch/1_43_1236681669.dbf ORA-00280: change 1042670 for thread 1 is in sequence #43 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /oradata/orcl/redo01.log ----具体是哪些redo日志文件，可以一一尝试！ Log applied. Media recovery complete. 备注：如果/oradata/orcl/redo01.log报不准确，则继续尝试/oradata/orcl/redo02.log，依次这样，确保所有日志文件都完成恢复！ 4）failover切换 alter database activate standby database; ---强制切换备库为主库 5）打开备库 alter database open; select protection_mode,database_role,open_mode from v$database; PROTECTION_MODE DATABASE_ROLE OPEN_MODE -------------------- ---------------- -------------------- MAXIMUM PERFORMANCE PRIMARY READ WRITE

四、GAP（主库归档日志丢失）处理

(一)处理本质总结
12c版本之前的常规处理步骤：

1、在主库上创建一个备库的控制文件
2、以备库的当前SCN号为起点，在主库上做一个增量备份
3、将新创建的控制文件和增量备份拷贝到备库服务器上
4、使用新的控制文件将备库启动到mount状态
5、将增量备份注册到RMAN的catalog，取消备库的恢复应用，恢复增量备份
6、开启备库的恢复进程

上述六个步骤，是处理归档日志丢失gap的本质过程，12c版本、18c版本，逐步可以做到一键式处理，但是本质都是通过上述几个步骤完成，只是封装后所需要执行的命令越来越简单！

12c开始处理命令
RECOVER … FROM SERVICE
18c开始处理命令
RECOVER STANDBY DATABASE FROM SERVICE Oracle在18c对12c的功能进行了加强，推出了(RECOVER STANDBY DATABASE … FROM SERVICE)通过网络服务直接增量恢复备库数据,这个新特性也大大简化了DataGuard主备的问题修复。

Oracle随着版本的升级，逐渐将步骤缩减，进行封装，18C之后可谓是达到了所谓的一键刷新，恢复DG同步。

（二）11g版本，归档日志丢失gap处理案例

gap模拟说明：模拟备库断电，主库做一些产生日志的动作，然后切几个最新的归档，最后手工删掉这几个归档日志，备库重新开启DG同步。

1、模拟归档日志丢失gap
1）备库down掉，模拟断电 alter database recover managed standby database cancel; shutdown immediate 2）主库做一些产生日志的动作，然后多切换几个归档日志 insert into t1 values(10); commit; alter system archive log current; create table tab_user1 as select * from dba_users; alter system archive log current; insert into t1 values(11); alter system archive log current; 3）主库服务器上，删除最近几个归档日志 cd /oradata/arch mkdir bak mv 1_47_1236681669.dbf 1_48_1236681669.dbf 1_49_1236681669.dbf bak/ 4）启动备库开启同步 startup ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; 5）备库上查看GAP情况 select * from v$archive_gap; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- 1 46 49 SELECT max(sequence#) from v$archived_log where applied='YES'; MAX(SEQUENCE#) -------------- 46 set pagesize 99 SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS --------- ------------ ---------- ---------- ---------- ---------- ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CLOSING 1 50 1 114 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 RFS IDLE 0 0 0 0 RFS IDLE 0 0 0 0 RFS IDLE 1 51 2005 1 MRP0 APPLYING_LOG 1 47 65 102400 12 rows selected.

最终GAP归档日志确认为47—49这三个归档日志

2、正式处理过程

1）在主库上创建一个备库的控制文件

alter database create standby controlfile as '/oradata/backup/standby.ctl'; Database altered.

2）以备库的当前SCN号为起点，在主库上做一个增量备份

备库上执行，查询备库的当前scn号 SQL> select to_char(current_scn) from v$database; TO_CHAR(CURRENT_SCN) ---------------------------------------- 1044264 主上执行你，以备库scn号为起点，主库做一个增量备份 rman target / backup INCREMENTAL from scn 1044264 database format '/oradata/backup/incre_%U'; 备注：可以并发方式完成，类似如下 run{ allocate channel c1 type disk; allocate channel c2 type disk; backup INCREMENTAL from scn 1086639 database format '/oradata/backup/incre_%U'; release channel c1; release channel c2; }

3）将控制文件和增量备份拷贝到备库上

主库服务器上执行 scp /oradata/backup/* oracle@host32:/oradata/backup/ [oracle@host31 backup]$ scp /oradata/backup/* oracle@host32:/oradata/backup/ oracle@host32's password: incre_144rsqmg_1_1 100% 3032KB 103.6MB/s 00:00 incre_154rsqmh_1_1 100% 9856KB 82.4MB/s 00:00 standby.ctl 100% 9808KB 212.2MB/s 00:00

4）使用新的控制文件将备库启动到mount状态

shutdown immediate startup nomount rman target / restore controlfile from '/oradata/backup/standby.ctl'; 具体输出 Starting restore at 29-JUN-26 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=20 device type=DISK channel ORA_DISK_1: copied control file copy output file name=/oradata/orcl/control01.ctl output file name=/oradata/orcl/control02.ctl Finished restore at 29-JUN-26 启动至mount状态 alter database mount;

5）增量备份注册到RMAN的catalog，取消日志应用，恢复增量备份

备库取消日志应用： ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 增量备份注册到备库的catalog中： rman target / catalog start with '/oradata/backup'; 具体输出： RMAN> catalog start with '/oradata/backup'; released channel: ORA_DISK_1 searching for all files that match the pattern /oradata/backup List of Files Unknown to the Database ===================================== File Name: /oradata/backup_bak/st1.ctl File Name: /oradata/backup/incre_144rsqmg_1_1 File Name: /oradata/backup/incre_154rsqmh_1_1 File Name: /oradata/backup/standby.ctl Do you really want to catalog the above files (enter YES or NO)? YES //输入YES cataloging files... cataloging done List of Cataloged Files ======================= File Name: /oradata/backup_bak/st1.ctl File Name: /oradata/backup/incre_144rsqmg_1_1 File Name: /oradata/backup/incre_154rsqmh_1_1 File Name: /oradata/backup/standby.ctl 恢复增量备份 recover database noredo; 具体输出： Starting recover at 29-JUN-26 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=20 device type=DISK channel ORA_DISK_1: starting incremental datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set destination for restore of datafile 00001: /oradata/orcl/system01.dbf destination for restore of datafile 00002: /oradata/orcl/sysaux01.dbf destination for restore of datafile 00003: /oradata/orcl/undotbs01.dbf destination for restore of datafile 00004: /oradata/orcl/users01.dbf channel ORA_DISK_1: reading from backup piece /oradata/backup/incre_144rsqmg_1_1 channel ORA_DISK_1: piece handle=/oradata/backup/incre_144rsqmg_1_1 tag=TAG20260629T150552 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 Finished recover at 29-JUN-26

6）开启备库的恢复进程

备库只读方式打开，并且启动应用： alter database open read only; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; 查询视图，确认GAP已修复 SELECT * FROM V$ARCHIVE_GAP; SELECT max(sequence#) from v$archived_log where applied='YES'; SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS --------- ------------ ---------- ---------- ---------- ---------- ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CLOSING 1 51 2048 1064 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 RFS IDLE 0 0 0 0 RFS IDLE 0 0 0 0 RFS IDLE 1 52 143 1 MRP0 APPLYING_LOG 1 52 143 102400 12 rows selected. SQL> select * from t1; ID ---------- 10 11

至此，完成11g版本归档日志丢失的GAP修复！

（三）12c版本，归档日志丢失gap处理案例

采用rman的新功能，recover standby using service，通过RMAN连接到target备库，然后用主库的service执行恢复备库命令。

语法： RECOVER DATABASE FROM SERVICE < PRIMARY DB SERVICE NAME > NOREDO USING COMPRESSED BACKUPSET;

具体恢复过程

备库启动到nomount状态 shutdown immediate startup nomount rman恢复 rman target / 恢复控制文件 restore standby controlfile from service orcl; 备库mount alter database mount; 执行恢复 recover database from service orcl noredo using compressed backupset; 备注：如果期间有新增数据文件，目录位置不一样，需要进行额外的处理工作！！ 开启备库应用日志 alter database open; alter pluggable database all open; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
（四）18c版本及以上，归档日志丢失gap处理案例

采用RECOVER STANDBY DATABASE FROM SERVICE恢复备库，RECOVER STANDBY DATABASE命令完成的工作：

1）重新启动备用实例;

2)从主数据库刷新控制文件;

3)并自动重命名数据文件，临时文件和联机日志;

4)它可以还原添加到主数据库中的新数据文件;

5)还原到当前时间的备用数据库。

具体恢复过程

备库取消日志应用 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 开始恢复备库，备库上执行 rman target / RECOVER STANDBY DATABASE FROM SERVICE orcl; 开启备库应用日志 alter database open; alter pluggable database all open; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
http://www.jsqmd.com/news/1147849/

相关文章：

  • 福建一次性棉柔巾批发哪家性价比高
  • LangGraph Demo 实战总结：从状态图、工具调用到 RAG Agent
  • Python+OpenCV 相机标定全流程：从 8 张棋盘格图像到 3D 坐标轴可视化
  • 5分钟掌握：Reset Windows Update Tool终极修复Windows更新问题指南
  • 任意成品exe一键加密系统—乾坤云验证，一套真正把细节做到极致的系统
  • Trae氛围编程：用声明式技能链重构内容同步工作流
  • 金融机构终端安全深度复盘：银狐木马、内存脚本已成常态化威胁，传统防护体系全面失效
  • 电气隔离技术与TLP241A在工业控制中的应用
  • 2026澳洲旅游签攻略：签证材料NAATI翻译流程+费用指南
  • 企业微信 SCRM 全面解析：概念、核心功能与选型指南
  • 中大型工厂数字化改造避坑路线图
  • SolonCode CLI 为什么选择 Java 技术栈？
  • 提示工程与 Agent 编排：从单轮对话到复杂任务执行的架构演进
  • 国内企业AI算力管控平台排行：多维度实测评估
  • PyTorch nn.Linear 与 nn.MSELoss 原理解析：从 1 维输入到多维扩展
  • 2026鞍山黄金回收白银回收铂金回收中检持证鉴定师铂金银饰高价回收门店联系方式推荐
  • 蓝牙5.4 LE Audio嵌入式系统开发实战
  • STM32与DTH-08实现信号上拉下拉控制详解
  • AI Agent 炸裂科普：Hugging Face 术语表深度解读
  • GESP2026年6月认证C++七级( 第三部分编程题（1、染色））精讲
  • DLSS Swapper完全指南：一键智能切换DLSS版本，彻底释放显卡性能潜力
  • Detect It Easy：文件类型识别工具
  • 个人微信API二次开发，一挂载调试器就闪退，难道无法绕过底层的反调试机制吗？
  • 工业视觉验收报告必备指标：精度、召回率、FPS、稳定性（MTBF）详解
  • 最优化算法收敛性实战：梯度下降 vs 牛顿法，5 种迭代策略的 Python 对比
  • 新手提交CNVD漏洞报告避坑指南：从驳回案例到成功收录的实战经验
  • AI Agent 从入门到封神：24 讲打造你的超级智能体~系列文章12：Plugin vs Tool vs MCP：三种扩展方式怎么选？
  • SharpKeys终极指南：3步完成Windows键盘重映射，彻底告别误触烦恼
  • 能量模型 (EBM) 与扩散模型对比：3 大核心差异与 Langevin 采样演进分析
  • 【ROS2】 Conda 环境搭建（命令行版）