DataGuard出现GAP的两种处理方法

DataGuard出现GAP的两种处理方法
DG GAP顾名思义就是：DG不同步，当备库不能接受到一个或多个主库的归档日志文件时候，就发生了GAP。

DG GAP主要分为两类情况：
主库归档日志存在，可以通过配置 Fetch Archive Log(FAL) 参数，自动解决归档GAP。
主库归档日志丢失，需要 人工干预 来修复：
第一种方式：
11G处理步骤：
a.在主库上创建一个备库的控制文件
b.以备库的当前SCN号为起点，在主库上做一个增量备份
c.将增量备份拷贝到备库上
d.使用新的控制文件将备库启动到mount状态
e.将增量备份注册到RMAN的catalog，取消备库的恢复应用，恢复增量备份
f.开启备库的恢复进程
具体实现方式如下：
首先，模拟备库断电，主库切几个最新的归档，然后手工删掉，重新开启DG同步。
备库停止DG同步进程

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

主库切换多次归档

SQL>sqlplus / as sysdba
SQL>alter system switch logfile;

主库删除最近几个归档日志
rm 1_34_1070147137.arc
rm 1_33_1070147137.arc

备库开启同步进程

SQL>startup
SQL>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 41 46

SQL>SELECT max(sequence#) from v$archived_log where applied='YES';

MAX(SEQUENCE#)
---------
31
注意：当前DG数据库已存在GAP，GAP日志为：32—34 。
a.在主库上创建一个备库的控制文件

SQL>alter database create standby controlfile as '/home/oracle/standby.ctl';

b.以备库的当前SCN号为起点，在主库上做一个增量备份
备库查询当前scn号

SQL>select  to_char(current_scn) from v$database;

TO_CHAR(CURRENT_SCN)
---------
1619474

确认主备GAP期间是否新增数据文件

SQL>select file# from v$datafile where creation_change# > =1619474;

主库根据备库scn号进行增量备份

rman target /
RMAN>run{
allocate channel c1 type disk;
allocate channel c2 type disk;
backup INCREMENTAL from scn 1086639 database format '/home/oracle/incre_%U';
release channel c1;
release channel c2;
}

注意：如果存在新增数据文件，备库恢复时需要先restore新添加的数据文件。
c.将增量备份和控制文件拷贝到备库上
主库拷贝增量备份和控制文件你至备库

scp incre_0* oracle@orcl_stby:/home/oracle
scp standby.ctl oracle@orcl_stby:/home/oracle

注意：确认备库的磁盘空间是否足够存放。
d.使用新的控制文件将备库启动到mount状态
备库关闭数据库实例，开启至nomount状态

SQL>sqlplus / as sysdba
SQL>shutdown immediate
SQL>startup nomount

备库恢复新的控制文件

rman target /
RMAN>restore controlfile from '/home/oracle/standby.ctl';

备库开启到mount状态

SQL>alter database mount;

e.增量备份注册到RMAN的catalog，取消日志应用，恢复增量备份
确认备库已关闭DG同步进程

SQL>sqlplus / as sysdba
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

备库rman注册增量备份文件

rman target /
RMAN>catalog start with '/home/oracle/';

备库开启恢复增量备份

RMAN>recover database noredo;

f.开启备库的恢复进程
备库开启日志同步进程

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

主库重新激活同步

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

查询是否存在GAP，确认主备是否同步

SQL>sqlplus / as sysdba
SQL>SELECT * FROM V$ARCHIVE_GAP;
SQL>SELECT max(sequence#) from v$archived_log where applied='YES';
SQL>SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;

第二种方式：
手工处理日志GAP的步骤

1、在备库检查是否有日志缺失

SQL> select * from V$ARCHIVE_GAP;

THREAD#   LOW_SEQUENCE#     HIGH_SEQUENCE#
----------------  ----------------------------      ------------------
1                  99                               109

从上面的信息可以看出，备库中缺失了99到109的日志。
2、在主库中查询缺失的日志的所在路径和名称

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

NAME
---------------------
/u01/archivelog/1_99_626106231.arc
/u01/archivelog/1_100_626106231.arc
/u01/archivelog/1_101_626106231.arc
/u01/archivelog/1_102_626106231.arc
/u01/archivelog/1_103_626106231.arc
/u01/archivelog/1_104_626106231.arc
/u01/archivelog/1_105_626106231.arc
/u01/archivelog/1_106_626106231.arc
/u01/archivelog/1_107_626106231.arc
/u01/archivelog/1_108_626106231.arc
/u01/archivelog/1_109_626106231.arc

如果把日志移动到其他路径，则把日志所在路径换成当前实际所在路径。
3、把日志拷贝到备库上
可以通过scp命令传输归档日志。
4、在备库上手工注册上一步中从主库拷贝来的日志

SQL> ALTER DATABASE REGISTER LOGFILE '/u01/archivelog/1_99_626106231.arc';

Database altered.

SQL> ALTER DATABASE REGISTER LOGFILE '/u01/archivelog/1_109_626106231.arc';

Database altered.
5、稍等片刻，观察备库的alert日志信息 ：
Sun Aug 12 20:38:47 2007
Media Recovery Log /u01/archivelog/1_99_626106231.arc
Media Recovery Log /u01/archivelog/1_100_626106231.arc
Media Recovery Log /u01/archivelog/1_101_626106231.arc
Media Recovery Log /u01/archivelog/1_102_626106231.arc
…
从以上信息，可以看出之前注册的日志已经被正常应用。或者查询视图v$archived_log的applied字段

6、检查备库是否还有日志GAP

SQL> select * from V$ARCHIVE_GAP;

no rows selected
如果有行返回，则重复2-5步，直到查询结果是"no rows selected"。
如果日志只是临时移动到其他地方，过后会再移回原路径，则不用这么大费周折手工去手工处理了，把日志拷回原处后FAL会自动处理GAP。