DataGuard GAP问题解决

某天下午打开DG备库时发现无法open只能到mount状态。

Alter database open; 总是提示如下错误:

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1:
‘/oracle/app/oracle/oradata/PROD1_ST/datafile/o1_mf_system_0qrb37o0_.dbf‘

提示需要recovery,于是立马查看gap以及日志应用情况。

select name,sequence#,archived,applied from v$archived_log;

结果sequence#从905到973之前大片的归档日志applied状态为NO,看了下备库的归档目录确实少了很多归档日志。

悲剧,于是决定采用备份主库日志的解决办法来恢复。

1.停止备库的Redo Apply

SQL> alter database recover managed standby database cancel;

2.查询备库的当前SCN 值

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

3.在主库使用RMAN 基于SCN 的增量备份

RMAN> backup incremental from scn 1579945 database format ‘/u01/backup/forstandby_arch‘ tag ‘forstandby‘;

4.将备份copy 到备库,还原备库控制文件并执行恢复操作

RMAN> STARTUP FORCE NOMOUNT;
RMAN> RESTORE STANDBY CONTROLFILE FROM ‘/home/oracle/backup/forstandby_arch‘;
RMAN> ALTER DATABASE MOUNT;
RMAN> CATALOG START WITH ‘/home/oracle/backup/‘; --注册下新的备份集
RMAN> RECOVER DATABASE NOREDO; --应用新的增量备份集
RMAN> ALTER DATABASE OPEN;

5.最后开启MRP进程

SQL> alter database recover managed standby database using current logfile disconnect from session; --打开real time apply
时间: 2024-11-02 13:25:34

DataGuard GAP问题解决的相关文章

DataGuard Gap sequence的处理方法

检查数据库服务器,发现磁盘已满,因为前期规划问题,磁盘空间不足,还好该库不影响. 删除归档时,发现删除过多,导致备库归档没有成功应用,就被删除了. 这个操作确实粗心大意,检查备库归档时,发现无法应用,查看日志有如下报错: Fetching gap sequence in thread 1, gap sequence 42102-42102 FAL[client]: All defined FAL servers have been attempted. ---------------------

【Oracle】基于SCN的增量备份修复DataGuard GAP

1. 首先来模拟Gap的产生 1.1. 备库关闭: [email protected]_s>shutdown immediate; 1.2. 主库切换日志 [email protected]>select SEQUENCE#,ARCHIVED,STATUS from v$log; SEQUENCE# ARC STATUS ---------- --- ---------------- 61 YES ACTIVE 62 YES ACTIVE 63 NO  CURRENT [email prote

DataGuard主备归档存在gap的处理办法

DataGuard主备之间可能由于网络等原因,造成备库和主库之间的归档日志不一致,这样就产生了gap. 解决gap的步骤: 1.在备库获得gap的详细信息 2.将需要的归档日志从主库拷贝到备库 3.备库将归档日志注册,然后应用.   --备库alert日志提示gap详情   Media Recovery Waiting for thread 1 sequence 7057 Fetching gap sequence in thread 1, gap sequence 7057-7080 FAL[

oracle dataguard archive gap后恢复

起因:源端数据库应用程序逻辑错误,导致重大量重试回滚,日产生归档300GB,异地备份在10Mbps的网速下,产生了archive gap:解决流程:1 查出备库当前的scn号 select current_scn from v$database; 1612480746 2 在主库生成基于备库scn的增量备份 --primary show all; run{ ALLOCATE CHANNEL d1 TYPE disk; set limit channel d1 kbytes=104857600;

增量备份解决dataguard库日志gap

有时候备库滞后于主库很长时间了,而主库的归档日志已经不存在了,此时的日志间隔如何消除那,很多人选择重建备库,这个是很麻烦的,尤其当主库数据量很大的时候,此时我们还有另外一种选择,那就是使用增量数据库备份来前滚备库,消除日志间隔,具体作法如下:1.备库查看丢失的归档时的scn号 idle> select current_scn from v$database; CURRENT_SCN ----------- 96458277 2.主库创建基于丢失归档scn号为起始的增量备份(要确定主库和备库的目标

Dataguard 11G ora-16047问题解决

最近在安装并测试Oracle 11G Datagurad,搭建安装了测试系统,并且配置完毕,但是出现了ora-16047的问题,简单描述环境: 主库:hunter          SID:hunter           db_name=hunter    db_unique_name=hunter         service=hunter 被库:hunterdg      SID:hunterdg      db_name=hunter    db_unique_name=hunterd

Oracle 11g Dataguard 配置,维护与详解 (ADG)

一.前言: 本手册主要记录如何配置,还介绍了配置原因,以及注意要点,已经主备切换,以及故障转移等重要操作步骤,我希望这个文章可以作为进行dataguard配置的一个参考手册. 二.前提 1.主库是归档模式: 如果我们不清楚为什么是归档模式,那我们就应该也不会清楚dataguard是用来做什么的.透过很多修饰的官方语言,我们需要明确DG(dataguard简称,后同)实际上的作用就是用来高可用.而实现原理就是从主库获取数据到从库,在主库发生异常的时候,从库接管主库,完成身份的变化.可以一个主库,最

oracle11g dataguard 完全手册

一.前言: 网络上关于dataguard的配置文章很多,但是很多打着oracle11g的文章实际都是只能在9 10 上运行,比如FAL_CLIENT在11g中已经废弃,但是现在网络上的文章都是没有标注这一点.而且对于具体含义语焉不详对于新手只能知其然而不知其所以然.这篇文章我就想让像我这样的人对于dataguard配置不仅仅知道怎么配置,还要知道为什么需要这样配置,这样的效果才是最好的. 这篇文章不仅仅是记录如何配置,还介绍了为什么是这样,以及注意要点,我希望这个文章可以作为进行dataguar

【DATAGUARD】物理dg配置客户端无缝切换 (八.4)--ora-16652 和 ora-16603错误

[DATAGUARD]物理dg配置客户端无缝切换 (八.4)--ora-16652 和 ora-16603错误 一.1  BLOG文档结构图       一.2  前言部分   一.2.1  导读 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① Data Guard Broker 的配置 ② Fast-Start Failover 的配置 ③ Oracle DataGuard 之客户端TAF 配置 ④ 使用DGMGRL 来管理数据库