基於SCN增量恢復DG同步

問題描述：作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;