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

datapeng發表於2017-12-27
問題現象：
  1. SQL> alter database open resetlogs;
  2. alter database open resetlogs
  3. *
  4. ERROR at line 1:
  5. ORA-01152: file 1 was not restored from a sufficiently old backup
  6. ORA-01110: data file 1: '/DBSoft/oracle/oradata/woo/system01.dbf'

日誌中報錯：
  1. alter database open
  2. Errors in file /DBSoft/oracle/diag/rdbms/woo/woo/trace/woo_ora_24956.trc:
  3. ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
  4. ORA-1589 signalled during: alter database open...
  5. Sun Dec 24 05:44:45 2017
  6. Signalling error 1152 for datafile
  7. Signalling error 1152 for datafile
  8. Signalling error 1152 for datafile
  9. Signalling error 1152 for datafile
  10. Signalling error 1152 for datafile
  11. Checker run found 5 new persistent data failures
  12. Sun Dec 24 05:44:51 2017
  13. alter database open resetlogs
  14. Signalling error 1152 for datafile
  15. ORA-1152 signalled during: alter database open resetlogs...

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

檢視scn資訊：
檢視資料檔案頭部的scn資訊：
  1. SQL> select checkpoint_change# from v$datafile_header;

  3. CHECKPOINT_CHANGE#
  4. ------------------
  5.      2247792
  6.      2247792
  7.      2247792
  8.      2247792
  9.      2247792

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

  1. SQL> select checkpoint_change# from v$datafile;

  3. CHECKPOINT_CHANGE#
  4. ------------------
  5.      2247974
  6.      2247974
  7.      2247974
  8.      2247974
  9.      2247974

      在這裡我們可以很清楚的看到控制檔案中記錄的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;

  3. Database altered.
檢查：
  1. SQL> col error format a10;
  2. SQL> select * from v$recover_file;

  4. no rows selected

  6. SQL> select checkpoint_change# from v$datafile_header;

  8. CHECKPOINT_CHANGE#
  9. ------------------
  10.      2247797
  11.      2247797
  12.      2247797
  13.      2247797
  14.      2247797

  16. SQL> select checkpoint_change# from v$datafile;

  18. CHECKPOINT_CHANGE#
  19. ------------------
  20.      2247797
  21.      2247797
  22.      2247797
  23.      2247797
  24.      2247797
總結：必須保證資料檔案頭部的scn和控制檔案中的scn資訊保持一致，資料庫才能開啟，那麼正常恢復將遵循就近，就小來恢復。










來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29371470/viewspace-2149361/，如需轉載，請註明出處，否則將追究法律責任。

相關文章