Oracle ADG 搭建完成后处于 WAIT_FOR_GAP 状态问题处理

科技   2024-10-31 23:02   北京  
作者 | JiekeXu
来源 |公众号 JiekeXu DBA之路(ID: JiekeXu_IT)
如需转载请联系授权 | (个人微信 ID:JiekeXu_DBA)
大家好,我是 JiekeXu,江湖人称“强哥”,荣获 Oracle ACE Pro 称号,墨天轮 MVP,墨天轮年度“墨力之星”,拥有 Oracle OCP/OCM 认证,MySQL 5.7/8.0 OCP 认证以及 PCA、PCTA、OBCA、OGCA、KCP 等众多国产数据库认证证书,今天和大家一起来看看 Oracle ADG 搭建完成后处于 WAIT_FOR_GAP 状态问题处理,欢迎点击最上方蓝字“JiekeXu DBA之路”关注我的微信公众号,然后点击右上方三个点“设为星标”置顶,更多干货文章才能第一时间推送,谢谢!

前  言 

最近两个月前遇到网友有一套云上的单机的 11g DG,去年通过某云搭建好了 ADG 环境,但今年中由于网络原因导致主库的归档日志还没有传递到备库就被强制删除了,进而导致 ADG 备库出现 GAP。原以为这个问题比较简单,通过增量备份恢复就好了,因为不是 19c 版本没法通过 from service 的方式恢复,感兴趣的可查看如下文章。

Oracle ADG 备库停启维护步骤及增量恢复
利用 Oracle 19c 新特性 from service 修复备库 GAP

正  文

因归档丢失出现 GAP 如果需要的归档日志有备份,直接恢复出所需要的归档,然后拿到备库去注册就行,如果没有备份归档,那么则需要重建或者增量恢复,如果库比较大,则增量恢复。当使用正常的流程增量恢复后,应用日志开启 MRP0 进程却不同步日志,状态是 WAIT_FOR_GAP 等待几年前的已经不存在的归档号 16754。如下图所示:

一度怀疑他是不是没有按照我的步骤做恢复,因为平时上班期间也不能远程,排查无果,没办法只能让其全库恢复了,使用如下命令进行 rman 全备,然后传递到备库做恢复。

rman target /run {  allocate channel c1 type disk ;  allocate channel c2 type disk ;  allocate channel c3 type disk ;  allocate channel c4 type disk ;  backup  as compressed backupset database format '/backup/backup20240830/%d_%I_%s_%p.bak';  backup  as compressed backupset archivelog all format '/backup/backup20240830/%d_%I_%s_%p.arc';  backup current controlfile for standby format '/backup/backup20240830/%d_%I_%s_%p.ctl';  release channel c1;  release channel c2;  release channel c3;  release channel c4;}
--将备份传输至备库[oracle@jiekexu rmanbk]$ scp beijing_3078169696_* 192.168.3.105:/backup/backup20240830/
--备库操作SQL> startup nomount
rman target /RMAN> restore standby controlfile from '/backup/backup20240830/JiekeXu_1470960497_14179_1.ctl';RMAN> sql 'alter database mount';
--注册从源数据库拷贝过来的备份集到 rman 中RMAN> catalog start with'/backup/backup20240830/';……Do you really want to catalog the abovefiles (enter YES or NO)? yes
--恢复数据库run { allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; allocate channel c4 type disk; restore database; recover database; release channel c1; release channel c2; release channel c3; release channel c4;}

进行全量备份恢复后,应用日志开启 MRP0 进程,alert 日志中也没有任何报错,但还是不同步日志,状态也是 WAIT_FOR_GAP 等待几年前的已经不存在的归档号 16754。如下图所示:

问题根因

最终通过排查发现,源库有一个 43 号数据文件处于“RECOVER”状态。

SQL> select file#,CREATION_TIME,ts#,status,ENABLED from v$datafile where file#=43;
FILE# CREATION_ TS# STATUS ENABLED---------- --------- ---------- ------- ---------- 43 23-JUN-19 6 RECOVER READ WRITE
SQL> select file_id,file_name,status from dba_data_files where tablespace_name='STS_01' and file_id=43;
FILE_ID FILE_NAME STATUS---------- ---------------------------------------------------------------------------------------- ---------        43 /u01/oracle/oradata/prod/sts_01.20190623_5.dbf                                      AVAILABLE

查看 alert 日志发现这个 43 号文件在 22 年的时候就被 drop 过,后面做过 “RECOVER” 但是一直没有 online,幸好这个数据文件上也没有存放数据,不然可能导致数据丢失的风险。

SELECT e.segment_name, e.segment_typeFROM dba_extents eJOIN dba_data_files f ON e.file_id = f.file_idWHERE f.file_id=43;

注意:如果查出有数据,那么需要联系业务人员再三确认这些对象可以删除,如果没有备份,那么恢复起来就比较困难了,具体还需要进一步判断数据对象是什么,通过非常规手段进行异常数据恢复。

问题解决

那么,通过查看 alert 日志发现这个数据文件以前主库就被删除过,且去年搭建 DG 的时候也 drop 过这个文件,经过再三确定可以删除这个文件,那就干吧。

SQL> startup mountORACLE instance started.
Total System Global Area 1.5500E+11 bytesFixed Size 2261448 bytesVariable Size 2.0938E+10 bytesDatabase Buffers 1.3368E+11 bytesRedo Buffers 376410112 bytesDatabase mounted.SQL> SQL> select file#,CREATION_TIME,ts#,status,ENABLED from v$datafile where file#=43;
FILE# CREATION_TIME TS# STATUS ENABLED---------- ------------------- ---------- ------- ---------- 43 2019-06-23 22:59:20 6 RECOVER READ WRITE
SQL> SQL> alter database datafile 43 offline;alter database datafile 43 offline*ERROR at line 1:ORA-01668: standby database requires DROP option for offline of data file
SQL> alter database datafile 43 offline drop;
Database altered.
SQL> ![oracle@jiekexu ~]$ ll /u02/oracle/oradata/prod/ts_01.20190623_5.dbf-rw-r----- 1 oracle oinstall 33286004736 Aug 31 22:15 /u02/oracle/oradata/prod/ts_01.20190623_5.dbf

执行后此命令不会立即删除磁盘上的物理文件。这个命令的作用是将数据文件 ID 为 43 的数据文件将被标记为离线并从数据库控制文件中删除,但它不会自动删除物理磁盘上的文件。

通过这个操作后,重启 MRP 进程,查看状态以及变为 APPLYING_LOG,不一会儿 apply lag 也变成了 0,算是恢复正常了。

问题总结

如果主库有处于 recover 状态的数据文件无法通过 Rman 备份,更加搭建不了一个正常同步的 ADG。

全文完,希望可以帮到正在阅读的你,如果觉得有帮助,可以分享给你身边的朋友,同事,你关心谁就分享给谁,一起学习共同进步~~~



分享几个数据库备份脚本

一文搞懂 Oracle 统计信息

我的 Oracle ACE 心路历程

MOP 系列|MOP 三种主流数据库索引简介

Oracle 主流版本不同架构下的静默安装指南

关机重启导致 ASM 磁盘丢失数据库无法启动

Oracle SQL 性能分析(SPA)原理与实战演练

Oracle 11g 升级到 19c 需要关注的几个问题

Windows 10 环境下 MySQL 8.0.33 安装指南

SQL 大全(四)|数据库迁移升级时常用 SQL 语句

OGG|使用 OGG19c 迁移 Oracle11g 到 19C(第二版)

Oracle 大数据量导出工具——sqluldr2 的安装与使用

Oracle ACE 视角下的国产数据库现状与选型及应对策略

从国产数据库调研报告中你都能了解哪些信息及我的总结建议

使用数据泵利用 rowid 分片导出导入 lob 大表及最佳实践

在归档模式下直接 rm dbf 数据文件并重启数据库还有救吗?

欢迎关注我的公众号【JiekeXu DBA之路】,一起学习新知识!
——————————————————————————
公众号:JiekeXu DBA之路
墨天轮:https://www.modb.pro/u/4347

CSDN :https://blog.csdn.net/JiekeXu
ITPUB:https://blog.itpub.net/69968215
腾讯云:https://cloud.tencent.com/developer/user/5645107——————————————————————————

JiekeXu DBA之路
JiekeXu:Oracle ACE-Pro,获 Oracle OCP/OCM 及 MySQL OCP 认证,墨天轮 MVP,利用闲时间记录菜鸟 DBA 学习成长之路,所发布文字属于个人观点和学习笔记,如有错误及不当之处,敬请批评指正!
 最新文章