問題描述：做scn恢復備庫的測試，吭哧了幾天，今天終於可以記錄一下，遇到了很多坑，作為初學者可以更好地理解DG，主要先關閉備庫，在主庫做歸檔丟失備庫無法同步，備庫產生GAP，然後增量備份恢復備庫，版本：SQL*Plus: Release 11.2.0.4.0 Production on Thu No ...
問題描述：做scn恢復備庫的測試，吭哧了幾天，今天終於可以記錄一下，遇到了很多坑，作為初學者可以更好地理解DG，主要先關閉備庫，在主庫做歸檔丟失備庫無法同步，備庫產生GAP，然後增量備份恢復備庫，版本：SQL*Plus: Release 11.2.0.4.0 Production on Thu Nov 28 09:33:14 2019
1.備庫操作：關閉備庫，關閉之前首先要檢查一下主備是否同步，否則會產生一些不必要的麻煩
SQL> select process,client_process,sequence#,status,block#,blocks from v$managed_standby; 檢查一下備庫進程，mrp進程正在等待應用進程，然後就需要重新應用一下保持DG同步
SQL> recover managed standby database cancel; 關閉一下實時應用
SQL> select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby; 這個時候實時應用關閉，mrp進程是被關掉的，日誌中都可以看到
SQL> alter database recover managed standby database using current logfile disconnect from session; 開啟實時同步，這個時候mrp進程是起來的
SQL> select process,client_process,status,sequence#,block#,blocks from v$managed_standby; 查詢一下wait狀態變成了applying應用狀態
2.關閉備庫，前邊都是廢話，檢查一下備庫是否同步，下邊取消實時應用，也就是關掉
SQL> recover managed standby database cancel;
SQL> shutdown immediate
3.主庫上操作：模擬歸檔丟失，這時備庫的已經關掉
SQL> alter system switch logfile;
SQL> select max(sequence#) from v$archived_log; 查詢一下歸檔序號到了24號
SQL> archive log list 這裡寫一下查找歸檔路徑的方法，不用在意我這裡的歸檔號，這是後來補上的圖，當時沒做這個操作，查到路徑在USE_DB_RECOVERY_FILE_DEST，這是系統預設的閃回去內，這裡也可以修改的。
SQL> show parameter log_archive_dest_1
SQL> desc v$archived_log
SQL> select name from v$archived_log; 按照這個步驟來可以找到歸檔的路徑
[root@orcl ~]# cd /home/oracle/flashdata/ORCL/archivelog/2019_11_27/ 找到該路徑，我切換了兩次，所以序列號到24
4.這裡對比一下備庫的序列號，註意這裡是備庫截至到序列號是22，下邊是我遇到的一個大坑
這裡讓主庫模擬丟失的本來是23和24，但是備庫一直出現不了GAP的狀態，後來一看備庫日誌說的是23已經再被運輸中(in transit)，所以說這裡如果備庫重新啟動23是直接被應用的，如果把23號歸檔mv掉，是產生不了GAP的，所以要模擬mv掉歸檔 就mv 24號歸檔，也就是切換的第二個歸檔，這裡需要註意下
5.主庫繼續模擬丟失歸檔
[root@orcl 2019_11_27]# mv o1_mf_1_24_gxx0qq27_.arc /tmp 這裡我隨便挪到一個目錄下
6.備庫上：啟動備庫，查看GAP
SQL> startup mount
SQL> recover managed standby database using current logfile disconnect from session;
SQL> select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby; 已經可以看到mrp進程正在等待GAP24號
這個是日誌截圖都是gap24號
SQL> select * from v$archive_gap; 這些都可以查到
7.主庫上：查詢到24號歸檔的scn號，然後做增量備份，這裡要做的是在主庫上查詢到24號歸檔的scn號，也就是在對24號歸檔做操作之前的記錄，然後在備庫增量恢復
SQL> select FIRST_CHANGE# from v$archived_log where SEQUENCE# =24; 查詢到24號歸檔之前的操作
SQL> select current_scn from v$database; 確認一下24號scn號的範圍怎麼樣，這裡是當前的歸檔號
8.主庫上做基於1110582的備份
[oracle@orcl ~]$ rman target /
RMAN> backup as compressed backupset incremental from SCN 1110582 database format '/home/oracle/standby_%d_%T_%U.bak' include current controlfile for standby filesperset=5 tag 'FOR STANDBY'; 這裡要看一下哪個是控制文件，以及rman備份文件的許可權問題
這裡查看一下備份的文件
9.傳輸到備庫 /home/oracle下
[oracle@orcl ~]$ scp *.bak 192.168.1.5:/home/oracle
10.在備庫上進行恢復scn號,首先恢復控制文件
[root@orclstd oracle]# su - oracle
[oracle@orclstd ~]$ rman target /
RMAN> restore standby controlfile from '/home/oracle/standby_ORCL_20191127_0euhv1rm_1_1.bak';
RMAN> alter database mount; 到mount狀態
RMAN> catalog start with'/home/oracle'; 註冊一下傳輸過來的備份，這裡rman有一個文件頭損壞的報錯，這裡不影響後邊的報錯，但是我沒有理解
RMAN> recover database noredo; 增量恢復備份文件
11.驗證，這裡狀態都變成了應用日誌，這裡也可以在主庫多切換幾次日誌，看看備庫有沒有實時同步
SQL> recover managed standby database using current logfile disconnect from session;
Media recovery complete.
SQL> select process,status,sequence# from v$managed_standby;
