数据库dg参数和各项配置已准备完毕
在搭建dg最后，recover后打开dg同步（recover managed standby database using current logfile disconnect），
dg备库报错如下
Thu Jun 4 21:05:16 2020
Waiting for all non-current ORLs to be archived...
Media Recovery Log +ARCH/lisdb_new/archivelog/2020_06_03/thread_1_seq_1.281.1042077683
Media Recovery Waiting for thread 2 sequence 1
Thu Jun 4 21:05:16 2020
Completed: alter database recover managed standby database using current logfile disconnect from session
Thu Jun 4 21:05:26 2020
Fetching gap sequence in thread 2, gap sequence 1-100
Thu Jun 4 21:05:56 2020
FAL[client]: Failed to request gap sequence
GAP - thread 2 sequence 1-100
DBID 619928562 branch 1042077514
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
报错说fal没有找到gap序列号，检查fal参数的tns，可以用sqlplus登陆，说明不是监听和网络问题
查看报错中备库想要拿到的归档的seq号 1-100
查看备库所拥有的归档：
SQL> select sequence#,applied,to_char(next_time,'yyyy-mm-dd hh24:mi:ss'),NAME from v$archived_log where name is not null order by name;
SEQUENCE# APP TO_CHAR(NEXT_TIME,' NAME
---------- --- ------------------- --------------------------------------------------------------------------------
22017 NO 2020-05-29 01:45:56 +ARCH/lisdb_new/archivelog/2020_05_29/thread_1_seq_22017.264.1041696777
21546 YES 2020-05-29 01:45:59 +ARCH/lisdb_new/archivelog/2020_05_29/thread_2_seq_21546.265.1041696779
1 NO 2020-06-03 02:01:22 +ARCH/lisdb_new/archivelog/2020_06_03/thread_1_seq_1.281.1042077683
22019 YES 2020-06-03 00:39:14 +ARCH/lisdb_new/archivelog/2020_06_03/thread_1_seq_22019.274.1042072815
22020 YES 2020-06-03 01:41:17 +ARCH/lisdb_new/archivelog/2020_06_03/thread_1_seq_22020.277.1042076535
22021 NO 2020-06-03 01:57:47 +ARCH/lisdb_new/archivelog/2020_06_03/thread_1_seq_22021.280.1042077471
21548 YES 2020-06-02 22:11:11 +ARCH/lisdb_new/archivelog/2020_06_03/thread_2_seq_21548.275.1042073481
21549 YES 2020-06-03 00:39:12 +ARCH/lisdb_new/archivelog/2020_06_03/thread_2_seq_21549.276.1042073481
21550 YES 2020-06-03 01:41:17 +ARCH/lisdb_new/archivelog/2020_06_03/thread_2_seq_21550.278.1042076537
21551 NO 2020-06-03 01:57:47 +ARCH/lisdb_new/archivelog/2020_06_03/thread_2_seq_21551.279.1042077471
22017 YES 2020-05-29 01:45:56 +ARCH/lisdb_new/archivelog/2020_06_04/thread_1_seq_22017.272.1042228257
SEQUENCE# APP TO_CHAR(NEXT_TIME,' NAME
---------- --- ------------------- --------------------------------------------------------------------------------
22018 YES 2020-06-02 07:06:50 +ARCH/lisdb_new/archivelog/2020_06_04/thread_1_seq_22018.270.1042228265
22022 NO 2020-06-04 20:09:19 +ARCH/lisdb_new/archivelog/2020_06_04/thread_1_seq_22022.289.1042229401
21546 YES 2020-05-29 01:45:59 +ARCH/lisdb_new/archivelog/2020_06_04/thread_2_seq_21546.271.1042228259
21547 YES 2020-06-01 04:00:06 +ARCH/lisdb_new/archivelog/2020_06_04/thread_2_seq_21547.286.1042228399
21552 NO 2020-06-04 20:09:17 +ARCH/lisdb_new/archivelog/2020_06_04/thread_2_seq_21552.287.1042228913
归档已经从主库传了过来，存放在备库的arch磁盘组中
查看主库归档：
pri:
SQL> Set lin 200
SQL> col name for a100
SQL> select sequence#,applied,to_char(next_time,'yyyy-mm-dd hh24:mi:ss'),NAME from v$archived_log where name is not null order by name;
SEQUENCE# APP TO_CHAR(NEXT_TIME,' NAME
---------- --- ------------------- ----------------------------------------------------------------------------------------------------
21547 NO 2020-06-01 04:00:06 +FRA/lisdb/archivelog/2020_06_01/thread_2_seq_21547.493.1041912007
22018 NO 2020-06-02 07:06:50 +FRA/lisdb/archivelog/2020_06_02/thread_1_seq_22018.835.1042009611
21548 NO 2020-06-02 22:11:11 +FRA/lisdb/archivelog/2020_06_02/thread_2_seq_21548.826.1042063871
22019 NO 2020-06-03 00:39:14 +FRA/lisdb/archivelog/2020_06_03/thread_1_seq_22019.814.1042072759
22020 NO 2020-06-03 01:41:17 +FRA/lisdb/archivelog/2020_06_03/thread_1_seq_22020.817.1042076481
21549 NO 2020-06-03 00:39:12 +FRA/lisdb/archivelog/2020_06_03/thread_2_seq_21549.822.1042072753
21550 NO 2020-06-03 01:41:17 +FRA/lisdb/archivelog/2020_06_03/thread_2_seq_21550.648.1042076483
22021 NO 2020-06-04 20:01:10 +FRA/lisdb/archivelog/2020_06_04/thread_1_seq_22021.392.1042228871
22022 NO 2020-06-04 20:09:19 +FRA/lisdb/archivelog/2020_06_04/thread_1_seq_22022.338.1042229359
21551 NO 2020-06-04 20:01:10 +FRA/lisdb/archivelog/2020_06_04/thread_2_seq_21551.336.1042228871
21552 NO 2020-06-04 20:09:17 +FRA/lisdb/archivelog/2020_06_04/thread_2_seq_21552.558.1042229357
SEQUENCE# APP TO_CHAR(NEXT_TIME,' NAME
---------- --- ------------------- ----------------------------------------------------------------------------------------------------
22022 NO 2020-06-04 20:09:19 lisdb_new
21552 NO 2020-06-04 20:09:17 lisdb_new
21547 YES 2020-06-01 04:00:06 lisdb_new
22020 YES 2020-06-03 01:41:17 lisdb_new
21548 YES 2020-06-02 22:11:11 lisdb_new
21549 YES 2020-06-03 00:39:12 lisdb_new
22019 YES 2020-06-03 00:39:14 lisdb_new
21550 YES 2020-06-03 01:41:17 lisdb_new
主库归档没有丢失，而且已经通过lisdb_new传到备库
备库居然想拿到1-100号sequence的归档，归档的序列号（归档的序列号在每个实例上都是递增的）现在都21000+了，
不应该去取这么久的归档才对
而我的controlfile又是从主库create standby过来的（restore完成后做的此操作），按理应该是没有问题的
在asm中再次查看备库归档
[grid@LISDB ~]$ asmcmd
ASMCMD> cd +ARCH/lisdb_new/archivelog/2020_06_03
ASMCMD> ls
thread_1_seq_1.281.1042077683
thread_1_seq_22019.274.1042072815
thread_1_seq_22020.277.1042076535
thread_1_seq_22021.280.1042077471
thread_2_seq_21548.275.1042073481
thread_2_seq_21549.276.1042073481
thread_2_seq_21550.278.1042076537
thread_2_seq_21551.279.1042077471
asm中居然有seq为1的归档，很奇怪
尝试删除
ASMCMD> rm thread_1_seq_1.281.1042077683
ORA-15032: not all alterations performed
ORA-15028: ASM file '+ARCH/lisdb_new/archivelog/2020_06_03/thread_1_seq_1.281.1042077683' not dropped; currently being accessed (DBD ERROR: OCIStmtExecute)
SQL> recover managed standby database cancel;
Media recovery complete.
ASMCMD> rm thread_1_seq_1.281.1042077683
ASMCMD>
删掉了，而且备库还获取了这个归档，可能我删归档的操作有问题
再次打开dg，查看告警日志如下：
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 1-100
DBID 619928562 branch 1042077514
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
cancel掉再recover试试
RMAN> recover database;
Starting recover at 04-JUN-20
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=2172 devtype=DISK
starting media recovery
archive log thread 1 sequence 22021 is already on disk as file +ARCH/lisdb_new/archivelog/2020_06_03/thread_1_seq_22021.280.1042077471
archive log thread 2 sequence 21551 is already on disk as file +ARCH/lisdb_new/archivelog/2020_06_03/thread_2_seq_21551.279.1042077471
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/04/2020 21:18:27
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 1 lowscn 106417241876 found to restore
这么大的scn号不可能在seq1里面
没办法只有做增量了
增量本篇幅就不贴了，前面篇幅已经讲过
简单的原理就是查找备库数据库scn和数据文件scn的最小值，然后再主库做from scn的增量备份，最后在备库recover