小記基於控制檔案的scn不完全恢復

問題現象：

日誌中報錯：

問題分析：
做完recover database正要起庫，發現data file 1需要恢復，那麼這個時候就應該要想到需要做不完全恢復了。那麼不完全恢復自然有四種，基於時間（time）恢復
  基於取消（cancel）恢復
  基於SCN（change）恢復
  基於備份控制檔案（unsing backup controlfile）的恢復，那麼接下來我們需要了解下，用那種方式最合適了。

檢視scn資訊：
檢視資料檔案頭部的scn資訊：

檢視控制檔案中記錄的scn頭部資訊：


      在這裡我們可以很清楚的看到控制檔案中記錄的scn資訊比資料檔案頭部記錄的scn資訊更新，且所有資料檔案頭部資訊是一致的，由此可以快速得出，我們將資料庫恢復到資料檔案的scn這樣資料庫就可以開啟了。

做基於檔案頭部的scn恢復：

1. SQL> recover database until change 2247792;
   
2. ORA-00283: recovery session canceled due to errors
   
3. ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

        提示需要使用控制檔案來做基於scn的恢復。

使用控制檔案來做基於scn的恢復：

1. SQL> recover database until change 2247792 using backup controlfile;
   
2. Media recovery complete.

  SQL> select * from v$recover_file


     FILE# ONLINE  ONLINE_ ERROR CHANGE# TIME
---------- ------- ------- ---------- ---------- ------------------
1 ONLINE  ONLINE 2247792 23-DEC-17
2 ONLINE  ONLINE 2247792 23-DEC-17
3 ONLINE  ONLINE 2247792 23-DEC-17
4 ONLINE  ONLINE 2247792 23-DEC-17
5 ONLINE  ONLINE 2247792 23-DEC-17

恢復完成之後，執行open resetlogs:

1. SQL> alter database open resetlogs;
   
2. 
   
3. Database altered.

檢查：

1. SQL> col error format a10;
   
2. SQL> select * from v$recover_file;
   
3. 
   
4. no rows selected
   
5. 
   
6. SQL> select checkpoint_change# from v$datafile_header;
   
7. 
   
8. CHECKPOINT_CHANGE#
   
9. ------------------
   
10.      2247797
    
11.      2247797
    
12.      2247797
    
13.      2247797
    
14.      2247797
    
15. 
    
16. SQL> select checkpoint_change# from v$datafile;
    
17. 
    
18. CHECKPOINT_CHANGE#
    
19. ------------------
    
20.      2247797
    
21.      2247797
    
22.      2247797
    
23.      2247797
    
24.      2247797

總結：必須保證資料檔案頭部的scn和控制檔案中的scn資訊保持一致，資料庫才能開啟，那麼正常恢復將遵循就近，就小來恢復。