數據庫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