Dataguard GAP修复

11G Dataguard GAP修复

GAP是怎么产生的

一般在dg配置好后，除非有专人维护，不然很少有人会去检查dg状态，这往往会导致，因各种原因备库已经长时间未与主库同步，等发现的时候，主库的归档日志已经删除，备库无法再次与主库同步，这时候GAP就产生了。

可通过以下命令在备库查看主备库GAP

sqlplus / as sysdba
SELECT * FROM V$ARCHIVE_GAP;
THREAD#    LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
 1     198     201

SELECT max(sequence#) from v$archived_log where applied='YES';
MAX(SEQUENCE#)
--------------
198

上述查询结果说明归档日志只传到198#，199#、200#、201#没有传到备库来。可此时主库的199-201#日志可能已经被删除了，备库不可能通过应用主库日志的方法来同步，所以要通过备份恢复的方法来追上和主库的数据差距。

如果主库归档日志还存在那就好处理了
首先在主库上找到备库缺失的归档日志

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 199 AND 201 ;

name
---------------------
/u01/archivelog/1_199_1078960375.dbf
/u01/archivelog/1_200_1078960375.dbf
/u01/archivelog/1_201_1078960375.dbf

将备库缺失的日志从主库拷贝过来，在备库重新应用一下日志就行了。

如果日志在主库已经删除就使用下面的方法。

1.没有生产环境，接下来模拟一个GAP环境

停止备库同步

sqlplus / as sysdba
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
shutdown immediate

主库切换几次日志

sqlplus / as sysdba
alter system switch logfile;

我这里切换3次日志

切换3次日志产生了3个归档，199#200#201#，此时备库的日志传输已经关闭，所以这三个归档不会传输到备库

然后删除，或者将这3个日志移动到归档路径意外，模拟日志删除。
rm/mv 1_199_…dbf
…
…

重新在备库应用日志。

alter database recover managed standby database using current logfile disconnect from session;

至此，GAP已经产生，通过查询主备同步状态发现主备库已经无法继续同步。

在备库查看GAP

sqlplus / as sysdba
SELECT * FROM V$ARCHIVE_GAP;
THREAD#    LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
 1     198     201  --GAP与日志号相对

SELECT max(sequence#) from v$archived_log where applied='YES';
MAX(SEQUENCE#)
--------------
198

2.修复GAP

a.在主库创建备库控制文件

alter database create standby controlfile as '/u01/standby.ctl';

b.在主库以备库scn为起点做增量备份

在备库查询当前scn
（1）这个是控制文件中的scn

sqlplus / as sysdba
select  to_char(current_scn) from v$database;
TO_CHAR(CURRENT_SCN)
----------------------------------------
2991877

（2）这个是数据文件头部的scn

SQL> select min(checkpoint_change#) from v$datafile_header where file# not in (select file# from v$datafile where enabled = 'READ ONLY');

MIN(CHECKPOINT_CHANGE#)
-----------------------
              2991878

我们一般以控制文件中的scn或者较小的scn为准

rman target /
run{
allocate channel c1 type disk;
allocate channel c2 type disk;
backup INCREMENTAL from scn 2991877 database format '/u01/incre_%U';
release channel c1;
release channel c2;
}

注：如果在备库与主库存在GAP的时间段内，主库新增了数据文件，在备库做增量恢复前需要先restore新增的数据文件。

在主库查询后发现主库新增了数据文件

sqlplus / as sysdba
select file# from v$datafile where creation_change# > =2991877;
FILE# NAME
------ -----------------------------------------------
    21 /u01/app/oracle/oradata/tps_data16.dbf
    22 /u02/oradata/tps_data17.dbf

所以备库在做恢复前要先restore新增的数据文件。

将控制文件和增量备份拷贝至备库

c.备库用新控制文件启动到mount

sqlplus / as sysdba
shutdown immediate
startup nomount

rman target /
restore controlfile from '/u01/standby.ctl';

sqlplus / as sysdba
alter database mount;

d.在备库用主库的增量备份恢复

确认备库已停止同步。

注册增量备份文件

rman target /
catalog start with '/u01/bak/';
YES

开始恢复
如果主库新增了数据文件需要先执行下面这步，restore datafile file#；如果没有新增可直接recover database noredo;

从库还原新增的数据文件
RMAN>restore datafile 21;
RMAN>restore datafile 22;

其实也可以不提前这一步，如果有新添加的数据文件没有restore的话，在recover数据库的时候会有提示如下：

如果有提示 ，你就按照提示restore datafile 153;就行了

RMAN>recover database noredo;

此时查询备库GAP，已经没有了。

e.备库重新开启同步

恢复完成后备库可开启同步

sqlplus / as sysdba
alter database open read only;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

可以重新激活一下主库同步参数 --可能也不用，我没做。

sqlplus / as sysdba
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=defer;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=enable;

此时DG同步状态应该就正常了