問題描述：做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;
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/28251.html
標籤：Oracle
上一篇：Oracle轉SqlServer
下一篇：SQL實用技巧：如何分割字串