physical standby 归档出现gap的解决办法

今早发现有一套DG环境的备库归档出现gap，主库上的也没有了
遇到这种情况其实不用重新配置从库，只要在主库上做个增量，在standby库上恢复一下就可以了。

Media Recovery Waiting for thread 1 sequence 8317
Fetching gap sequence in thread 1, gap sequence 8317-8317

FAL[client]: Failed to request gap sequence
 GAP - thread 1 sequence 8317-8317
 DBID 857574798 branch 705669326
FAL[client]: All defined FAL servers have been attempted.

解决步骤：
一、备库
SQL> show parameter name
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert                 string
db_name                              string      test11g
db_unique_name                       string      test11g_136
global_names                         boolean     FALSE
instance_name                        string      test11g
lock_name_space                      string
log_file_name_convert                string
service_names                        string      test11g_136
查看当前的SCN号：
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
 8267046122

二、主库
进行RMAN增量备库：
Rman>backup as compressed backupset incremental from SCN 8267046122 database format '/tol/rmanbak/test11g/standby_%d_%T_%U.bak' include current controlfile for standby filesperset=5tag 'FOR STANDBY';

三、备库
进行恢复数据，恢复控制文件：
1、把增量备份SCP到备库上
scp * dg_136:/tol/rmanbak/test11g/
并且用 RMAN> catalog start with '/tol/rmanbak/test11g/'; 注册。

2、进行恢复。
Alter database recover managed standby database disconnect from session;
Alter database recover managed standby database cancel;
RMAN> run {
allocate channel dsk0 type disk;
allocate channel dsk1 type disk;
allocate channel dsk2 type disk;
restore standby controlfile to '/tol/control01.ctl';
recover database noredo;}
然后shut immediate把控制文件覆盖原控制文件。
然后startup mount
Alter database recover managed standby database disconnect from session;

四、主库
切换即可，然后查看备库的归档应用状态。

Select sequence#,applied from v$archived_log;