【RMAN】如果控制文件損壞那么如何恢復？恢復控制文件的方式有哪幾種？
真題1、如果控制文件損壞那么如何恢復？恢復控制文件的方式有哪幾種？
答案：如果控制文件有多個，而只損壞了單個控制文件，那么只需要關閉數據庫，拷貝其它好的控制文件覆蓋掉壞的控制文件即可。也可以修改參數文件，只保留1個控制文件。如果損壞了全部控制文件，那么需要重新創建控制文件或從備份恢復。在有控制文件備份的情況下，restore controlfile命令可以用來還原控制文件。在還原控制文件后需要對數據庫執行完全介質恢復並以resetlogs選項來打開數據庫。
RMAN可以將控制文件還原到它的默認存儲位置，也可以使用restore controlfile ... to destination來指定控制文件的恢復位置。當還原控制文件時，控制文件的默認位置是由參數control_files控制的。如果沒有設置control_files參數，那么數據庫判斷還原控制文件存儲位置的規則將會與沒有設置control_files參數時創建控制文件時使用的規則一樣。
如下命令可以從備份集中恢復控制文件：
restore controlfile from '/bak/OCPLHR1/ctl_OCPLHR1_20180322_64_1.bak';
restore controlfile to '/home/oracle/a.ctl' from '/bak/OCPLHR1/ctl_OCPLHR1_20180322_64_1.bak' ;
在將控制文件還原到默認位置時，數據庫必須處於nomount狀態。如果從自動備份中還原控制文件，那么必須首先設置數據庫DBID，然后執行restore controlfile from autobackup命令。
最后，可以考慮使用控制文件快照進行恢復。如果沒有任何備份的控制文件，那么需要重建控制文件。重建控制文件的腳本可以通過命令“ALTER DATABASE BACKUP CONTROLFILE TO TRACE;”獲取。
在啟動數據庫的時候，如果報控制文件的版本不一致（ORA-00214），那么只需要將高版本的數據庫的控制文件覆蓋低版本的數據庫的控制文件即可，如下所示：
SYS@OCPLHR1> startup
ORACLE instance started.
Total System Global Area 521936896 bytes
Fixed Size 2229944 bytes
Variable Size 301992264 bytes
Database Buffers 209715200 bytes
Redo Buffers 7999488 bytes
ORA-00214: control file '/u01/app/oracle/fast_recovery_area/OCPLHR1/control02.ctl' version 2701 inconsistent with file
'/u01/app/oracle/oradata/OCPLHR1/control01.ctl' version 2699
SYS@OCPLHR1> ! cp /u01/app/oracle/fast_recovery_area/OCPLHR1/control02.ctl /u01/app/oracle/oradata/OCPLHR1/control01.ctl
SYS@OCPLHR1> alter database mount;
Database altered.
SYS@OCPLHR1> alter database open;
&說明：
有關控制文件在缺失歸檔日志的情況下的恢復可以參考我的BLOG：http://blog.itpub.net/26736162/viewspace-2152506/
真題1、Oracle的控制文件在缺失歸檔日志的情況下的恢復步驟有哪些？
在恢復控制文件時“recover database”命令可能需要使用歸檔日志。所謂缺失歸檔日志，是指控制文件從備份還原之后，在執行“recover database”命令恢復時報告找不到相應的日志導致恢復終止的情況。
這種情況下的恢復操作主要步驟如下：
① 首先還原控制文件，方式不限。
② 執行“recover database”命令將報RMAN-06054錯誤，即找不到某歸檔日志。
③ 查看相關的動態性能視圖，對問題定位，確認問題與控制文件，而不是數據文件相關（與數據文件相關必須進行不完全恢復）。
④ 利用create controlfile 命令重建控制文件。
⑤ 再次執行“recover database”命令，還會報RMAN-06054錯誤，這次是找不到另一個歸檔日志，其序列號應該大於第二步中的。
⑥ 查看v$log視圖確定第5步中所要的是哪個日志。
⑦ 執行SQLPLUS的”recover database using backup controlfile“命令，等”Specify log：“提示符出現后給出正確的在線日志路徑，直到命令成功結束。
⑧ 以resetlogs方式打開數據庫。
⑨ 由於創建的控制文件內不會有臨時數據文件的信息，需要重新將其添加回臨時表空間。
⑩ 將控制文件內其他丟失的信息用catalog和configure等命令再添加回去。
&說明：
有關控制文件在缺失歸檔日志的情況下的恢復可以參考我的BLOG：http://blog.itpub.net/26736162/viewspace-2152115/
一.1.1.1 丟失了控制文件
| 丟失了控制文件 如果控制文件丟失或損壞，則實例通常會中止。 • 如果控制文件存儲在 ASM 磁盤組中，則恢復方案如下： – 使用 Enterprise Manager 執行指導式恢復。 – 將數據庫置於NOMOUNT模式，然后使用 RMAN 命令從現有控制文件恢復控制文件。
• 如果控制文件存儲為常規文件系統文件，則： – 關閉數據庫。 – 復制現有的控制文件來替代丟失的控制文件。 成功恢復控制文件后，打開數據庫。
版權所有 © 2010，Oracle。保留所有權利。 |
丟失了控制文件后，可選的恢復方案取決於控制文件的存儲配置以及是至少還有一個控制文件還是丟失了所有文件。
如果使用ASM存儲，並且至少還有一個控制文件副本，您可以使用Enterprise Manager執行指導式恢復，或者使用RMAN執行手動恢復，如下所示：
將數據庫置於NOMOUNT模式。
連接到 RMAN 並發出restore controlfile命令來從現有的控制文件恢復控制文件，例如：
restore controlfile from '+DATA/orcl/controlfile/current.260.695209463';
成功恢復控制文件后，打開數據庫。
如果您的控制文件存儲為常規文件系統文件並且至少還有一個控制文件副本，這樣，在數據庫處於關閉狀態時，您只需將剩余的控制文件中的一個復制到丟失文件的位置。如果介質故障是由於磁盤驅動器或控制器缺失而造成的，則將剩余的控制文件中的一個復制到其它某個位置，然后通過更新實例的參數文件來指向新位置。或者，可從初始化參數文件中刪除對丟失的控制文件的引用。請注意：Oracle 建議始終至少保留兩個控制文件。
注：《Oracle Database 11g：數據庫管理－課堂練習 II》課程中介紹了如何在丟失了所有控制文件后進行恢復。
一.1.1.2 控制文件恢復前的准備
為了恢復控制文件，實例應該處於nomount狀態，如果發現問題的時候實例還未關閉，首先應該使用“shutdown abort”命令關閉實例，接着雖然可以使用“startup nomount”命令，但是建議使用“startup” 命令啟動實例，使其自然卡在 “nomount”狀態，這樣做可能會在警告日志和追蹤日志中產生更多有用有價值的信息，並且對數據恢復顧問也有好處。
----跳過某個已經刪除的表空間：
控制文件自動備份打開的情況下：
一.1.1.3 有備份情況下的恢復
一、 控制文件之一丟失(單個控制文件丟失或損壞)
正確的處理步驟：
① 關閉數據庫
② 從其它位置拷貝一個
③ 啟動數據庫
我們知道數據庫的控制文件都不止一個（一般為3個），這些控制文件互相為鏡像，所以只需要將其他沒損壞的控 制 文件重命名為損壞的控制文件即可。
我現在有三個控制文件
-rw-r----- 1 oracle oinstall 7258112 Mar 13 15:18 control01.ctl
-rw-r----- 1 oracle oinstall 7258112 Mar 13 15:18 control02.ctl
-rw-r----- 1 oracle oinstall 7258112 Mar 13 15:18 control03.ctl
現在刪除一個控制文件control01.ctl
SQL> startup
ORACLE instance started.
Total System Global Area 285212672 bytes
Fixed Size 1218992 bytes
Variable Size 104859216 bytes
Database Buffers 176160768 bytes
Redo Buffers 2973696 bytes
ORA-00205: error in identifying control file, check alert log for more info
將control02.ctl復制為control01.ctl
[oracle@localhost orcl]$ cp control02.ctl control01.ctl
成功啟動數據庫
SQL> alter database mount;
Database altered.
SQL> alter database open；
Database altered.
注：單個控制文件損壞也可以使用下面所講的全部控制文件損壞時的恢復方法，只是這里直接重命名其他控制文件的方法比較快，也是推薦的一種恢復方法。
二、 各種情況下的丟失
1、 已知備份文件位置
restore controlfile from '/bak/OCPLHR1/ctl_OCPLHR1_20180322_64_1.bak';
restore controlfile to '/home/oracle/a.ctl' from '/bak/OCPLHR1/ctl_OCPLHR1_20180322_64_1.bak' ;
如果丟失或損壞所有的控制文件就需要從備份中還原控制文件。restore controlfile命令用來還原控制文件。在還原控制文件后需要對數據庫執行完全介質恢復並以resetlog選項來打開數據庫。RMAN可以將控制文件還原到它的默認存儲位置，也可以使用restore controlfile ... to destination來指定位置。
從已經知的控制文件備份中還原控制文件
SQL> show parameter control_files NAME TYPE VALUE------------------------------------ ----------- ------------------------------control_files string /u01/app/oracle/oradata/test/c ontrol01.ctl, /u01/app/oracle/ oradata/test/control02.ctl, /u 01/app/oracle/oradata/test/con trol03.ctl
顯示當前可用的備份
RMAN> list backup; List of Backup Sets=================== BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------77 693.50K DISK 00:00:02 28-JAN-15 BP Key: 75 Status: AVAILABLE Compressed: YES Tag: TAG20150128T131713 Piece Name: /u02/test_df870182233_s95_s1 List of Archived Logs in backup set 77 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 13 2928236 28-JAN-15 2928830 28-JAN-15 BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------78 Full 166.91M DISK 00:01:19 28-JAN-15 BP Key: 76 Status: AVAILABLE Compressed: YES Tag: TAG20150128T131716 Piece Name: /u02/test_df870182236_s96_s1 List of Datafiles in backup set 78 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 2928835 28-JAN-15 /u01/app/oracle/oradata/test/system01.dbf 2 Full 2928835 28-JAN-15 /u01/app/oracle/oradata/test/undotbs01.dbf 3 Full 2928835 28-JAN-15 /u01/app/oracle/oradata/test/sysaux01.dbf 4 Full 2928835 28-JAN-15 /u01/app/oracle/oradata/test/users01.dbf 5 Full 2928835 28-JAN-15 /u01/app/oracle/oradata/test/example01.dbf 6 Full 2928835 28-JAN-15 /u01/app/oracle/oradata/test/test01.dbf BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------79 7.50K DISK 00:00:01 28-JAN-15 BP Key: 77 Status: AVAILABLE Compressed: YES Tag: TAG20150128T131841 Piece Name: /u02/test_df870182321_s97_s1 List of Archived Logs in backup set 79 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 14 2928830 28-JAN-15 2928868 28-JAN-15 BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------80 Full 9.42M DISK 00:00:02 28-JAN-15 BP Key: 78 Status: AVAILABLE Compressed: NO Tag: TAG20150128T131843 Piece Name: /u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150128-0d Control File Included: Ckp SCN: 2928874 Ckp time: 28-JAN-15 SPFILE Included: Modification time: 28-JAN-15
從上面的信息可以看到備份集80是控制文件與spfile文件的備份
下面來刪除當前數據庫的所有控制文件：
[root@oracle11g ~]# cd /u01/app/oracle/oradata/test/[root@oracle11g test]# ls -lrttotal 2213868-rw-r----- 1 oracle oinstall 11804672 Feb 1 11:36 users01.dbf-rw-r----- 1 oracle oinstall 52436992 Feb 1 11:36 test01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 11:36 redo02.log-rw-r----- 1 oracle oinstall 52429312 Feb 1 11:36 redo01.log-rw-r----- 1 oracle oinstall 104865792 Feb 1 11:36 example01.dbf-rw-r----- 1 oracle oinstall 20979712 Feb 1 11:37 temp01.dbf-rw-r----- 1 oracle oinstall 838868992 Feb 1 19:05 system01.dbf-rw-r----- 1 oracle oinstall 492838912 Feb 1 19:05 undotbs01.dbf-rw-r----- 1 oracle oinstall 576724992 Feb 1 19:05 sysaux01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 19:10 redo03.log-rw-r----- 1 oracle oinstall 9814016 Feb 1 19:11 control03.ctl-rw-r----- 1 oracle oinstall 9814016 Feb 1 19:11 control02.ctl-rw-r----- 1 oracle oinstall 9814016 Feb 1 19:11 control01.ctl[root@oracle11g test]# rm -rf control*.ctl[root@oracle11g test]# ls -lrttotal 2185068-rw-r----- 1 oracle oinstall 52429312 Feb 1 11:36 redo02.log-rw-r----- 1 oracle oinstall 20979712 Feb 1 11:37 temp01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 19:13 redo03.log-rw-r----- 1 oracle oinstall 11804672 Feb 1 19:14 users01.dbf-rw-r----- 1 oracle oinstall 492838912 Feb 1 19:14 undotbs01.dbf-rw-r----- 1 oracle oinstall 52436992 Feb 1 19:14 test01.dbf-rw-r----- 1 oracle oinstall 838868992 Feb 1 19:14 system01.dbf-rw-r----- 1 oracle oinstall 576724992 Feb 1 19:14 sysaux01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 19:14 redo01.log-rw-r----- 1 oracle oinstall 104865792 Feb 1 19:14 example01.dbf
向測試表t2中插入一些數據庫
SQL> insert into t2 select * from dba_objects; 51319 rows created. SQL> select count(*) from t2; COUNT(*)---------- 102560 SQL> commit; Commit complete.
這里因為是從linux操作系統層面刪除了所有控制文件，因為在數據庫沒有關閉的情況下文件的句柄沒有釋放所以數據庫還能運行。
人為將數據庫異常終止
[root@oracle11g test]# ps -ef | grep smonoracle 3463 1 0 22:30 ? 00:00:00 ora_smon_testroot 3179 3123 0 22:45 pts/3 00:00:00 grep smon[root@oracle11g test]# kill -9 3463
啟動數據庫：
SQL> startupORACLE instance started. Total System Global Area 327155712 bytesFixed Size 1273516 bytesVariable Size 138412372 bytesDatabase Buffers 184549376 bytesRedo Buffers 2920448 bytesORA-00205: error in identifying control file, check alert log for more info
alert日志的內容如下:
ORA-00210: cannot open the specified control fileORA-00202: control file: '/u01/app/oracle/oradata/test/control01.ctl'ORA-27037: unable to obtain file statusLinux Error: 2: No such file or directoryAdditional information: 3Sun Feb 01 19:18:18 CST 2015ORA-205 signalled during: ALTER DATABASE MOUNT...
找不到控制文件不能將數據庫置於mount狀態.現在通過備份來還原控制文件執行完全數據庫恢復:
RMAN> restore controlfile from '/u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150128-0d'; Starting restore at 01-FEB-15using channel ORA_DISK_1 channel ORA_DISK_1: restoring control filechannel ORA_DISK_1: restore complete, elapsed time: 00:00:05output filename=/u01/app/oracle/oradata/test/control01.ctloutput filename=/u01/app/oracle/oradata/test/control02.ctloutput filename=/u01/app/oracle/oradata/test/control03.ctlFinished restore at 01-FEB-15 RMAN> sql 'alter database mount'; sql statement: alter database mountreleased channel: ORA_DISK_1 SQL> select status from v$instance; STATUS------------------------MOUNTED
執行完全恢復
RMAN> recover database; Starting recover at 01-FEB-15Starting implicit crosscheck backup at 01-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=155 devtype=DISKCrosschecked 3 objectsFinished implicit crosscheck backup at 01-FEB-15 Starting implicit crosscheck copy at 01-FEB-15using channel ORA_DISK_1Crosschecked 6 objectsFinished implicit crosscheck copy at 01-FEB-15 searching for all files in the recovery areacataloging files...no files cataloged using channel ORA_DISK_1 starting media recovery archive log thread 1 sequence 17 is already on disk as file /u01/app/oracle/oradata/test/redo02.logarchive log thread 1 sequence 18 is already on disk as file /u01/app/oracle/oradata/test/redo03.logarchive log thread 1 sequence 19 is already on disk as file /u01/app/oracle/oradata/test/redo01.logarchive log filename=/u02/1_15_870133266.dbf thread=1 sequence=15archive log filename=/u02/1_16_870133266.dbf thread=1 sequence=16archive log filename=/u01/app/oracle/oradata/test/redo02.log thread=1 sequence=17archive log filename=/u01/app/oracle/oradata/test/redo03.log thread=1 sequence=18archive log filename=/u01/app/oracle/oradata/test/redo01.log thread=1 sequence=19media recovery complete, elapsed time: 00:00:06Finished recover at 01-FEB-15 RMAN> sql 'alter database open resetlogs'; sql statement: alter database open resetlogs SQL> select status from v$instance; STATUS------------OPEN SQL> select count(*) from t2; COUNT(*)---------- 102560
表t2中的記錄與恢復之前相同，說明恢復成功。
當還原控制文件時，控制文件的默認位置是由參數control_files控制的。如果沒有設置control_files參數，那么數據庫判斷還原控制文件存儲位置的規則將會與沒有設置control_files參數時創建控制文件時使用的規則一樣。
2、 使用了恢復目錄
當沒有使用恢復目錄時，必須從控制文件自動備份中還原控制文件。如果從控制文件自動備份中還原控制文件，數據庫必須置於nomount狀態。必須首先設置數據庫的DBID，然后執行restore controlfile from autobackup命令
1.人為刪除所有控制文件
[root@oracle11g test]# ls -lrttotal 2213868-rw-r----- 1 oracle oinstall 20979712 Feb 1 11:37 temp01.dbf-rw-r----- 1 oracle oinstall 11804672 Feb 1 22:31 users01.dbf-rw-r----- 1 oracle oinstall 52436992 Feb 1 22:31 test01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo03.log-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo02.log-rw-r----- 1 oracle oinstall 104865792 Feb 1 22:31 example01.dbf-rw-r----- 1 oracle oinstall 576724992 Feb 1 22:37 sysaux01.dbf-rw-r----- 1 oracle oinstall 492838912 Feb 1 22:42 undotbs01.dbf-rw-r----- 1 oracle oinstall 838868992 Feb 1 22:42 system01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:42 redo01.log-rw-r----- 1 oracle oinstall 9814016 Feb 1 22:42 control03.ctl-rw-r----- 1 oracle oinstall 9814016 Feb 1 22:42 control02.ctl-rw-r----- 1 oracle oinstall 9814016 Feb 1 22:42 control01.ctl[root@oracle11g test]# rm -rf control*.ctl[root@oracle11g test]# ls -lrttotal 2185068-rw-r----- 1 oracle oinstall 20979712 Feb 1 11:37 temp01.dbf-rw-r----- 1 oracle oinstall 11804672 Feb 1 22:31 users01.dbf-rw-r----- 1 oracle oinstall 52436992 Feb 1 22:31 test01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo03.log-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo02.log-rw-r----- 1 oracle oinstall 104865792 Feb 1 22:31 example01.dbf-rw-r----- 1 oracle oinstall 576724992 Feb 1 22:37 sysaux01.dbf-rw-r----- 1 oracle oinstall 492838912 Feb 1 22:42 undotbs01.dbf-rw-r----- 1 oracle oinstall 838868992 Feb 1 22:42 system01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:42 redo01.log
2.人為將數據庫異常終止
[root@oracle11g test]# ps -ef | grep smonoracle 3063 1 0 22:30 ? 00:00:00 ora_smon_testroot 3179 3123 0 22:45 pts/3 00:00:00 grep smon[root@oracle11g test]# kill -9 3063
3.將數據庫啟動到nomount狀態
SQL> startup nomountORACLE instance started. Total System Global Area 327155712 bytesFixed Size 1273516 bytesVariable Size 138412372 bytesDatabase Buffers 184549376 bytesRedo Buffers 2920448 bytes
4.從以前的備份信息中可以找到如下信息，其中c-2155613261-20150201-03中的2155613261就是DBID
Starting Control File and SPFILE Autobackup at 01-FEB-15piece handle=/u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150201-03 comment=NONEFinished Control File and SPFILE Autobackup at 01-FEB-15
5.還原控制文件
RMAN> show controlfile autobackup format; RMAN configuration parameters are:CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'STB' TO '%F';CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'SBT_TAPE' TO '%F'; RMAN> set dbid 2155613261; executing command: SET DBID RMAN> restore controlfile from autobackup; Starting restore at 01-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=155 devtype=DISK recovery area destination: /u01/app/oracle/flash_recovery_areadatabase name (or database unique name) used for search: TESTchannel ORA_DISK_1: no autobackups found in the recovery areachannel ORA_DISK_1: looking for autobackup on day: 20150201channel ORA_DISK_1: autobackup found: c-2155613261-20150201-03channel ORA_DISK_1: control file restore from autobackup completeoutput filename=/u01/app/oracle/oradata/test/control01.ctloutput filename=/u01/app/oracle/oradata/test/control02.ctloutput filename=/u01/app/oracle/oradata/test/control03.ctlFinished restore at 01-FEB-15
6.恢復數據庫
RMAN> sql 'alter database mount'; sql statement: alter database mountreleased channel: ORA_DISK_1 RMAN> recover database; Starting recover at 01-FEB-15Starting implicit crosscheck backup at 01-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=155 devtype=DISKCrosschecked 13 objectsFinished implicit crosscheck backup at 01-FEB-15 Starting implicit crosscheck copy at 01-FEB-15using channel ORA_DISK_1Crosschecked 6 objectsFinished implicit crosscheck copy at 01-FEB-15 searching for all files in the recovery areacataloging files...no files cataloged using channel ORA_DISK_1 starting media recovery archive log thread 1 sequence 2 is already on disk as file /u01/app/oracle/oradata/test/redo02.logarchive log thread 1 sequence 3 is already on disk as file /u01/app/oracle/oradata/test/redo03.logarchive log filename=/u01/app/oracle/oradata/test/redo02.log thread=1 sequence=2archive log filename=/u01/app/oracle/oradata/test/redo03.log thread=1 sequence=3media recovery complete, elapsed time: 00:00:03Finished recover at 01-FEB-15 RMAN> sql 'alter database open resetlogs'; sql statement: alter database open resetlogs
RMAN會使用自動備份的格式與DBID來判斷在什么存儲位置來搜索控制文件自動備份。如果找到，RMAN就會從備份中將控制文件還原到由control_files參數所指定的所有位置
RMAN使用恢復目錄還原控制文件
1.人為刪除所有控制文件
[root@oracle11g test]# ls -lrt
total 2213868
-rw-r----- 1 oracle oinstall 20979712 Feb 1 11:37 temp01.dbf
-rw-r----- 1 oracle oinstall 11804672 Feb 1 22:31 users01.dbf
-rw-r----- 1 oracle oinstall 52436992 Feb 1 22:31 test01.dbf
-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo03.log
-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo02.log
-rw-r----- 1 oracle oinstall 104865792 Feb 1 22:31 example01.dbf
-rw-r----- 1 oracle oinstall 576724992 Feb 1 22:37 sysaux01.dbf
-rw-r----- 1 oracle oinstall 492838912 Feb 1 22:42 undotbs01.dbf
-rw-r----- 1 oracle oinstall 838868992 Feb 1 22:42 system01.dbf
-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:42 redo01.log
-rw-r----- 1 oracle oinstall 9814016 Feb 1 22:42 control03.ctl
-rw-r----- 1 oracle oinstall 9814016 Feb 1 22:42 control02.ctl
-rw-r----- 1 oracle oinstall 9814016 Feb 1 22:42 control01.ctl
[root@oracle11g test]# rm -rf control*.ctl
[root@oracle11g test]# ls -lrt
total 2185068
-rw-r----- 1 oracle oinstall 20979712 Feb 1 11:37 temp01.dbf
-rw-r----- 1 oracle oinstall 11804672 Feb 1 22:31 users01.dbf
-rw-r----- 1 oracle oinstall 52436992 Feb 1 22:31 test01.dbf
-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo03.log
-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo02.log
-rw-r----- 1 oracle oinstall 104865792 Feb 1 22:31 example01.dbf
-rw-r----- 1 oracle oinstall 576724992 Feb 1 22:37 sysaux01.dbf
-rw-r----- 1 oracle oinstall 492838912 Feb 1 22:42 undotbs01.dbf
-rw-r----- 1 oracle oinstall 838868992 Feb 1 22:42 system01.dbf
-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:42 redo01.log
2.人為將數據庫異常終止
[root@oracle11g test]# ps -ef | grep smonoracle 4135 1 0 22:30 ? 00:00:00 ora_smon_testroot 3179 3123 0 22:45 pts/3 00:00:00 grep smon[root@oracle11g test]# kill -9 4135
3.將數據庫啟動到nomount狀態
SQL> startup nomountORACLE instance started. Total System Global Area 327155712 bytesFixed Size 1273516 bytesVariable Size 138412372 bytesDatabase Buffers 184549376 bytesRedo Buffers 2920448 bytes
4.還原控制文件
[oracle@oracle11g admin]$ rman target sys/zzh_2046@test catalog rman/rman@jy Recovery Manager: Release 10.2.0.5.0 - Production on Sun Feb 1 23:04:03 2015 Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database: test (not mounted)connected to recovery catalog database RMAN> restore controlfile; Starting restore at 01-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=155 devtype=DISK channel ORA_DISK_1: starting datafile backupset restorechannel ORA_DISK_1: restoring control filechannel ORA_DISK_1: reading from backup piece /u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150201-01channel ORA_DISK_1: restored backup piece 1piece handle=/u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150201-01 tag=TAG20150201T213315channel ORA_DISK_1: restore complete, elapsed time: 00:00:04output filename=/u01/app/oracle/oradata/test/control01.ctloutput filename=/u01/app/oracle/oradata/test/control02.ctloutput filename=/u01/app/oracle/oradata/test/control03.ctlFinished restore at 01-FEB-15
5.執行完全恢復
RMAN> sql 'alter database mount'; sql statement: alter database mountreleased channel: ORA_DISK_1 RMAN> recover database; Starting recover at 01-FEB-15Starting implicit crosscheck backup at 01-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=155 devtype=DISKCrosschecked 8 objectsFinished implicit crosscheck backup at 01-FEB-15 Starting implicit crosscheck copy at 01-FEB-15using channel ORA_DISK_1Crosschecked 6 objectsFinished implicit crosscheck copy at 01-FEB-15 searching for all files in the recovery areacataloging files...no files cataloged using channel ORA_DISK_1 starting media recovery archive log thread 1 sequence 3 is already on disk as file /u01/app/oracle/oradata/test/redo03.logarchive log thread 1 sequence 4 is already on disk as file /u01/app/oracle/oradata/test/redo01.logarchive log filename=/u01/app/oracle/oradata/test/redo03.log thread=1 sequence=3archive log filename=/u01/app/oracle/oradata/test/redo01.log thread=1 sequence=4media recovery complete, elapsed time: 00:00:01Finished recover at 01-FEB-15 RMAN> sql 'alter database open resetlogs'; sql statement: alter database open resetlogsnew incarnation of database registered in recovery catalogstarting full resync of recovery catalogfull resync complete
①、 將控制文件還原到新目錄
有一種將控制文件還原到一個或多個新目錄的方法是修改control_files參數，然后用沒有任何參數的restore controlfile命令將控制文件還原到默認位置。例如，如果在有些控制文件目錄所在的磁盤出現故障還原控制文件，可以修改control_files參數將出現故障的磁盤使用其它的磁盤來替代，然后執行restore controlfile命令來還原控制文件。
如果不修改control_files參數也可以使用restore controlfile to 'filename' [from autobackup]命令來將控制文件還原到你所指定的位置。
示例：
RESTORE CONTROLFILE TO '/tmp/my_controlfile';
下面的命令將使用自動備份將控制文件還原到'/u01/app/oracle/‘目錄下
RMAN> restore controlfile to '/u01/app/oracle/control_temp.ctl' from autobackup; Starting restore at 02-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=148 devtype=DISK recovery area destination: /u01/app/oracle/flash_recovery_areadatabase name (or database unique name) used for search: TESTchannel ORA_DISK_1: autobackup found in the recovery areachannel ORA_DISK_1: autobackup found: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_02/o1_mf_s_870567448_bdwndtqk_.bkpchannel ORA_DISK_1: control file restore from autobackup completeFinished restore at 02-FEB-15
上面的命令可以在數據庫為nomount,mount,open狀態下進行，因為不會覆蓋任何當前使用的控制文件。在將控制文件還原到新目錄后，可以修改control_files參數來引用新目錄下的控制文件。
使用備份控制文件的限制
在使用備份控制文件還原數據庫后，你必須執行recover database來恢復數據庫並且必須執行alter database open resetlogs來打開數據庫。
3、 設置了設置閃回區
設置閃回區的情況下還原控制文件所使用的命令是相同的。然而如果當前數據庫正在使用閃回區，RMAN通過對所有基於控制文件中的基於磁盤的備份和鏡像副本和任何在閃回區中而不在還原的控制文件中的備份執行隱式的crosscheck來更新從備份中還原的控制文件。因此還原后的控制文件會完整的和精確的記錄在閃回區中的所有備份和其它任何在備份該控制文件時所知道的備份。這提高了在數據庫還原操作中的可用性。
下面來看一個使用閃回區還原控制文件的實例：
1.環境檢查，看是否已經啟用閃回區與設置控制文件自動備份
SQL> show parameter db_recover NAME TYPE VALUE------------------------------------ ----------- ------------------------------db_recovery_file_dest string /u01/app/oracle/flash_recovery_areadb_recovery_file_dest_size big integer 2G SQL> select flashback_on from v$database; FLASHBACK_ON------------------YES RMAN> show controlfile autobackup; RMAN configuration parameters are:CONFIGURE CONTROLFILE AUTOBACKUP ON;
從上面信息可知已經啟用了閃回區並設置了控制文件自動備份
2.創建一個表空間,在數據庫結構發生變化時，就會自動備份控制文件
SQL> create tablespace testbak datafile '/u01/app/oracle/oradata/test/testbak.dbf' size 10M extent management local segment space management auto; Tablespace created.
從alert日志中可以看到產生的控制文件自動備份的文件信息
create tablespace testbak datafile '/u01/app/oracle/oradata/test/testbak.dbf' size 10M extent management local segment space management autoMon Feb 02 00:17:28 CST 2015Starting control autobackupControl autobackup written to DISK device handle '/u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_02/o1_mf_s_870567448_bdwndtqk_.bkp'Completed: create tablespace testbak datafile '/u01/app/oracle/oradata/test/testbak.dbf' size 10M extent management local segment space management auto
其實控制文件和spfile同時被自動備份了
查看閃回區是否存在自動備份文件
[root@oracle11g 2015_02_02]# ls -lrttotal 19360-rw-r----- 1 oracle oinstall 9895936 Feb 2 00:17 o1_mf_s_870567448_bdwndtqk_.bkp
3.人為刪除所有控制文件
[root@oracle11g test]# ls -lrttotal 2213868-rw-r----- 1 oracle oinstall 20979712 Feb 1 11:37 temp01.dbf-rw-r----- 1 oracle oinstall 11804672 Feb 1 22:31 users01.dbf-rw-r----- 1 oracle oinstall 52436992 Feb 1 22:31 test01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo03.log-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo02.log-rw-r----- 1 oracle oinstall 104865792 Feb 1 22:31 example01.dbf-rw-r----- 1 oracle oinstall 576724992 Feb 1 22:37 sysaux01.dbf-rw-r----- 1 oracle oinstall 492838912 Feb 1 22:42 undotbs01.dbf-rw-r----- 1 oracle oinstall 838868992 Feb 1 22:42 system01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:42 redo01.log-rw-r----- 1 oracle oinstall 9814016 Feb 1 22:42 control03.ctl-rw-r----- 1 oracle oinstall 9814016 Feb 1 22:42 control02.ctl-rw-r----- 1 oracle oinstall 9814016 Feb 1 22:42 control01.ctl[root@oracle11g test]# rm -rf control*.ctl[root@oracle11g test]# ls -lrttotal 2185068-rw-r----- 1 oracle oinstall 20979712 Feb 1 11:37 temp01.dbf-rw-r----- 1 oracle oinstall 11804672 Feb 1 22:31 users01.dbf-rw-r----- 1 oracle oinstall 52436992 Feb 1 22:31 test01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo03.log-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:31 redo02.log-rw-r----- 1 oracle oinstall 104865792 Feb 1 22:31 example01.dbf-rw-r----- 1 oracle oinstall 576724992 Feb 1 22:37 sysaux01.dbf-rw-r----- 1 oracle oinstall 492838912 Feb 1 22:42 undotbs01.dbf-rw-r----- 1 oracle oinstall 838868992 Feb 1 22:42 system01.dbf-rw-r----- 1 oracle oinstall 52429312 Feb 1 22:42 redo01.log
4.人為將數據庫異常終止
[root@oracle11g test]# ps -ef | grep smonoracle 3068 1 0 22:30 ? 00:00:00 ora_smon_testroot 3179 3123 0 22:45 pts/3 00:00:00 grep smon[root@oracle11g test]# kill -9 3068
5.將數據庫啟動到nomount狀態
SQL> startup nomountORACLE instance started. Total System Global Area 327155712 bytesFixed Size 1273516 bytesVariable Size 138412372 bytesDatabase Buffers 184549376 bytesRedo Buffers 2920448 bytes
6.恢復控制文件
RMAN> restore controlfile from autobackup; Starting restore at 02-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=148 devtype=DISK recovery area destination: /u01/app/oracle/flash_recovery_areadatabase name (or database unique name) used for search: TESTchannel ORA_DISK_1: autobackup found in the recovery areachannel ORA_DISK_1: autobackup found: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_02/o1_mf_s_870567448_bdwndtqk_.bkpchannel ORA_DISK_1: control file restore from autobackup completeFinished restore at 02-FEB-15
在上面的還原控制文件的過程可以看到如下內容說明是使用存儲在閃回區中的控制文件自動備份來還原控制文件
channel ORA_DISK_1: autobackup found in the recovery areachannel ORA_DISK_1: autobackup found: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_02/o1_mf_s_870567448_bdwndtqk_.bkp
磁帶備份在還原控制文件后不會自動執行crosscheck。如果正使用磁帶備份，那么在還原控制文件並將數據庫置於mount狀態后，必須手工執行crosscheck.
RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT;
7.執行完全恢復
RMAN> sql 'alter database mount'; sql statement: alter database mountreleased channel: ORA_DISK_1 RMAN> recover database; Starting recover at 01-FEB-15Starting implicit crosscheck backup at 01-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=155 devtype=DISKCrosschecked 8 objectsFinished implicit crosscheck backup at 01-FEB-15 Starting implicit crosscheck copy at 01-FEB-15using channel ORA_DISK_1Crosschecked 6 objectsFinished implicit crosscheck copy at 01-FEB-15 searching for all files in the recovery areacataloging files...no files cataloged using channel ORA_DISK_1 starting media recovery archive log thread 1 sequence 3 is already on disk as file /u01/app/oracle/oradata/test/redo03.logarchive log thread 1 sequence 4 is already on disk as file /u01/app/oracle/oradata/test/redo01.logarchive log filename=/u01/app/oracle/oradata/test/redo03.log thread=1 sequence=3archive log filename=/u01/app/oracle/oradata/test/redo01.log thread=1 sequence=4media recovery complete, elapsed time: 00:00:01Finished recover at 01-FEB-15 RMAN> sql 'alter database open resetlogs'; sql statement: alter database open resetlogsnew incarnation of database registered in recovery catalogstarting full resync of recovery catalogfull resync complete
4、 缺失歸檔日志的情況下的恢復
眾所周知，恢復控制文件時“recover database”命令可能需要使用歸檔日志。所謂缺失歸檔日志，是指控制文件從備份還原之后，在執行“recover database”命令恢復時報告找不到相應的日志導致恢復終止的情況。
這種情況下的恢復操作主要步驟如下：
① 首先還原控制文件，方式不限
② 執行“recover database”命令將報RMAN-06054錯誤，即找不到某歸檔日志
③ 查看相關的動態性能視圖，對問題定位，確認問題與控制文件，而不是數據文件相關（與數據文件相關必須進行不完全恢復）
④ 利用create controlfile 命令重建控制文件
⑤ 再次執行“recover database”命令，還會報RMAN-06054錯誤，這次是找不到另一個歸檔日志，其序列號應該大於第二步中的
⑥ 查看v$log視圖確定第5步中所要的是哪個日志
⑦ 執行SQLPLUS的”recover database using backup controlfile“命令，等”Specify log：“提示符出現后給出正確的在線日志路徑，直到命令成功結束。
⑧ 以resetlogs方式打開數據庫
⑨ 由於創建的控制文件內不會有臨時數據文件的信息，需要重新將其添加回臨時表空間
⑩ 將控制文件內其他丟失的信息用catalog和configure等命令再添加回去。
一、當前current日志序列號為：5，此時進行控制文件備份
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch
Oldest online log sequence 3
Next log sequence to archive 5
Current log sequence 5
SQL>
RMAN> backup current controlfile;
Starting backup at 2015-02-04 16:28:13
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 2015-02-04 16:28:14
channel ORA_DISK_1: finished piece 1 at 2015-02-04 16:28:15
piece handle=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/1vpuel4t_1_1 tag=TAG20150204T162813 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2015-02-04 16:28:15
RMAN>
二、多次切換日志后，現在的CURRENT日志是20號，所有控制文件丟失並且第15號歸檔日志丟失，數據庫啟動后停留在了nomount狀態：
SQL> alter system switch logfile;
。。。。。。。。
System altered.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch
Oldest online log sequence 18
Next log sequence to archive 20
Current log sequence 20
SQL>
RMAN> delete archivelog sequence 15;
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=257 device type=DISK
List of Archived Log Copies for database with db_unique_name LILOVE
=====================================================================
Key Thrd Seq S Low Time
------- ---- ------- - -------------------
44 1 15 X 2015-02-04 16:29:58
Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_15_870711361.dbf
Do you really want to delete the above objects (enter YES or NO)? yes
deleted archived log
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_15_870711361.dbf RECID=44 STAMP=870798598
Deleted 1 objects
RMAN>
[root@rhel6_lhr ~]# ll /u01/app/oracle/oradata/utf8test/*
-rw-r----- 1 oracle asmadmin 10076160 Feb 4 16:40 /u01/app/oracle/oradata/utf8test/control01.ctl
-rw-r----- 1 oracle oinstall 10076160 Feb 4 16:40 /u01/app/oracle/oradata/utf8test/control02.ctl
-rw-r----- 1 oracle asmadmin 52429312 Feb 4 16:30 /u01/app/oracle/oradata/utf8test/redo01.log
-rw-r----- 1 oracle asmadmin 52429312 Feb 4 16:40 /u01/app/oracle/oradata/utf8test/redo02.log
-rw-r----- 1 oracle asmadmin 52429312 Feb 4 16:30 /u01/app/oracle/oradata/utf8test/redo03.log
-rw-r----- 1 oracle asmadmin 608182272 Feb 4 16:39 /u01/app/oracle/oradata/utf8test/sysaux01.dbf
-rw-r----- 1 oracle asmadmin 775954432 Feb 4 16:39 /u01/app/oracle/oradata/utf8test/system01.dbf
-rw-r----- 1 oracle asmadmin 10493952 Feb 3 16:15 /u01/app/oracle/oradata/utf8test/tbs_read01.dbf
-rw-r----- 1 oracle asmadmin 20979712 Feb 4 11:15 /u01/app/oracle/oradata/utf8test/temp01.dbf
-rw-r----- 1 oracle asmadmin 52436992 Feb 4 16:39 /u01/app/oracle/oradata/utf8test/undotbs01.dbf
-rw-r----- 1 oracle asmadmin 10493952 Feb 4 16:30 /u01/app/oracle/oradata/utf8test/users01.dbf
[root@rhel6_lhr ~]# rm -rf /u01/app/oracle/oradata/utf8test/control0*
[root@rhel6_lhr ~]# ll /u01/app/oracle/oradata/utf8test/*
-rw-r----- 1 oracle asmadmin 52429312 Feb 4 16:30 /u01/app/oracle/oradata/utf8test/redo01.log
-rw-r----- 1 oracle asmadmin 52429312 Feb 4 16:40 /u01/app/oracle/oradata/utf8test/redo02.log
-rw-r----- 1 oracle asmadmin 52429312 Feb 4 16:30 /u01/app/oracle/oradata/utf8test/redo03.log
-rw-r----- 1 oracle asmadmin 608182272 Feb 4 16:39 /u01/app/oracle/oradata/utf8test/sysaux01.dbf
-rw-r----- 1 oracle asmadmin 775954432 Feb 4 16:39 /u01/app/oracle/oradata/utf8test/system01.dbf
-rw-r----- 1 oracle asmadmin 10493952 Feb 3 16:15 /u01/app/oracle/oradata/utf8test/tbs_read01.dbf
-rw-r----- 1 oracle asmadmin 20979712 Feb 4 11:15 /u01/app/oracle/oradata/utf8test/temp01.dbf
-rw-r----- 1 oracle asmadmin 52436992 Feb 4 16:39 /u01/app/oracle/oradata/utf8test/undotbs01.dbf
-rw-r----- 1 oracle asmadmin 10493952 Feb 4 16:30 /u01/app/oracle/oradata/utf8test/users01.dbf
[root@rhel6_lhr ~]#
SQL> startup force;
ORACLE instance started.
Total System Global Area 501059584 bytes
Fixed Size 2229744 bytes
Variable Size 356518416 bytes
Database Buffers 134217728 bytes
Redo Buffers 8093696 bytes
ORA-00205: error in identifying control file, check alert log for more info
SQL>
告警文件報錯：
ALTER DATABASE MOUNT
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/oradata/utf8test/control02.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/oradata/utf8test/control01.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-205 signalled during: ALTER DATABASE MOUNT...
三、下面，我們開始恢復：
RMAN> restore controlfile from '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/1vpuel4t_1_1';
Starting restore at 2015-02-04 16:44:10
using channel ORA_DISK_1
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/oradata/utf8test/control01.ctl
output file name=/u01/app/oracle/oradata/utf8test/control02.ctl
Finished restore at 2015-02-04 16:44:11
RMAN>
查看控制文件的確已經恢復：
[root@rhel6_lhr ~]# ll /u01/app/oracle/oradata/utf8test/con*
-rw-r----- 1 oracle asmadmin 10076160 Feb 4 16:44 /u01/app/oracle/oradata/utf8test/control01.ctl
-rw-r----- 1 oracle asmadmin 10076160 Feb 4 16:44 /u01/app/oracle/oradata/utf8test/control02.ctl
[root@rhel6_lhr ~]#
四、下面我們掛載數據庫：
RMAN> mount database;
database mounted
released channel: ORA_DISK_1
RMAN>
五、下邊恢復數據庫將報錯，表示找不到15號歸檔文件：
RMAN> recover database;
Starting recover at 2015-02-04 16:47:55
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK
datafile 5 not processed because file is read-only
starting media recovery
archived log for thread 1 with sequence 18 is already on disk as file /u01/app/oracle/oradata/utf8test/redo03.log
archived log for thread 1 with sequence 19 is already on disk as file /u01/app/oracle/oradata/utf8test/redo01.log
archived log for thread 1 with sequence 20 is already on disk as file /u01/app/oracle/oradata/utf8test/redo02.log
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_5_870711361.dbf thread=1 sequence=5
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_6_870711361.dbf thread=1 sequence=6
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_7_870711361.dbf thread=1 sequence=7
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_8_870711361.dbf thread=1 sequence=8
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_9_870711361.dbf thread=1 sequence=9
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_10_870711361.dbf thread=1 sequence=10
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_11_870711361.dbf thread=1 sequence=11
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_12_870711361.dbf thread=1 sequence=12
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_13_870711361.dbf thread=1 sequence=13
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_14_870711361.dbf thread=1 sequence=14
unable to find archived log
archived log thread=1 sequence=15
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/04/2015 16:47:58
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 15 and starting SCN of 1927288
RMAN>
若此時打開數據庫，將報很多的錯誤：
RMAN> alter database open;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 02/04/2015 16:50:38
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
RMAN> alter database open resetlogs;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 02/04/2015 16:50:49
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/app/oracle/oradata/utf8test/system01.dbf'
六、分析原因，首先查看目前已知的歸檔文件最大的日志序列號是多少？
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
20
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch
Oldest online log sequence 3
Next log sequence to archive 5
Current log sequence 5
SQL> select GROUP#,SEQUENCE#,MEMBERS,STATUS,ARCHIVED from v$log;
GROUP# SEQUENCE# MEMBERS STATUS ARC
---------- ---------- ---------- ---------------- ---
1 4 1 INACTIVE YES
3 3 1 INACTIVE YES
2 5 1 CURRENT NO
SQL>
答案為20，如果歸檔已經是20了，那么current日志一定是大於20的，而我的數據庫的在線日志組數量為3個，也就是說在線日志的最小序列號大於17，進而得知所有數據文件的完全檢查點必然超過了17號日志的最后一條重做記錄。那么結論就是數據文件最多只需要17號之后的日志就能將恢復完成。
那么控制文件是從幾號開始恢復的呢？由v$log可知是從5號開始恢復的，恢復到15號日志的時候報錯了，所以我們只需要讓控制文件放棄17號就可以順利過關了。這個方法就是使用”create controlfile“創建一個新的控制文件。這個新的控制文件不知道current日志的序列號，不會強制所要任何日志對其恢復。
首先生成創建命令並重啟至nomount狀態：
SQL> alter database backup controlfile to trace as '/home/oracle/ctl.txt';
Database altered.
SQL> startup force nomount;
ORACLE instance started.
Total System Global Area 501059584 bytes
Fixed Size 2229744 bytes
Variable Size 356518416 bytes
Database Buffers 134217728 bytes
Redo Buffers 8093696 bytes
SQL>
我們在trace文件中得到並執行noresetlogs版本的”create controlfile“命令：
CREATE CONTROLFILE REUSE DATABASE "lilove" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u01/app/oracle/oradata/utf8test/redo01.log' SIZE 50M BLOCKSIZE 512,
GROUP 2 '/u01/app/oracle/oradata/utf8test/redo02.log' SIZE 50M BLOCKSIZE 512,
GROUP 3 '/u01/app/oracle/oradata/utf8test/redo03.log' SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/oradata/utf8test/system01.dbf',
'/u01/app/oracle/oradata/utf8test/sysaux01.dbf',
'/u01/app/oracle/oradata/utf8test/undotbs01.dbf',
'/u01/app/oracle/oradata/utf8test/users01.dbf'
CHARACTER SET AL32UTF8
;
將以上命令在sqlplus中執行，等”Control file created.“出現，數據庫已經自動mount了。然后再執行recover database命令就將至少從17號日志開始，越過了15號這個阻礙：
RMAN> recover database;
Starting recover at 2015-02-04 17:21:17
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK
starting media recovery
unable to find archived log
archived log thread=1 sequence=20
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/04/2015 17:21:18
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 20 and starting SCN of 1927308
RMAN>
從結果得到，15號不用了，但是報20號找不到，而20號歸檔是存在的，是在線日志，導致此問題的原因是新創建的控制文件有一個缺陷：使用這種控制文件恢復時RMAN通道只會一直地找歸檔日志，而無視在線日志。所以，恢復到尾聲階段的時候一定會報RMAN-06054錯誤，此時再查下v$log：
SQL> select GROUP#,SEQUENCE#,MEMBERS,STATUS,ARCHIVED from v$log;
GROUP# SEQUENCE# MEMBERS STATUS ARC
---------- ---------- ---------- ---------------- ---
1 19 1 INACTIVE NO
3 18 1 INACTIVE NO
2 20 1 CURRENT NO
SQL>
原來20號是在線日志，接下來使用sqlplus的”recover database using backup controlfile“命令，可以手動指定恢復過程中所使用的日志，然后resetlogs打開數據庫：
SQL> recover database using backup controlfile;
ORA-00279: change 1927308 generated at 02/04/2015 16:30:05 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_20_870711361.dbf
ORA-00280: change 1927308 for thread 1 is in sequence #20
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/utf8test/redo02.log
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
最后根據得到的控制文件trace中的內容執行如下語句：
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('BACKUP OPTIMIZATION','ON');
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('RETENTION POLICY','TO RECOVERY WINDOW OF 3 DAYS');
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/app/oracle/changetracking/rman_change_track.ctf' REUSE;
ALTER DATABASE RENAME FILE 'MISSING00005' TO '/u01/app/oracle/oradata/utf8test/tbs_read01.dbf';
ALTER TABLESPACE "TBS_READ" ONLINE;
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/utf8test/temp01.dbf' REUSE;
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('BACKUP OPTIMIZATION','ON');
VARIABLE RECNO NUMBER;
SQL>
PL/SQL procedure successfully completed.
SQL> SQL> EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('RETENTION POLICY','TO RECOVERY WINDOW OF 3 DAYS');
PL/SQL procedure successfully completed.
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/app/oracle/changetracking/rman_change_track.ctf' REUSE;
Database altered.
SQL> ALTER DATABASE RENAME FILE 'MISSING00005' TO '/u01/app/oracle/oradata/utf8test/tbs_read01.dbf';
Database altered.
SQL> ALTER TABLESPACE "TBS_READ" ONLINE;
Tablespace altered.
SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/utf8test/temp01.dbf' REUSE;
Tablespace altered.
SQL>
最后不要忘記全備數據庫。
①、 以noresetlogs結尾
三、 使用控制文件快照
使用控制文件的快照進行恢復，其實也是一種采用備份來進行恢復的策略。
SYS@OCPLHR1> select name from v$controlfile;
NAME
----------------------------------------------------------------------------
/u01/app/oracle/oradata/OCPLHR1/control01.ctl
/u01/app/oracle/fast_recovery_area/OCPLHR1/control02.ctl
[oracle@OCPLHR dbs]$ ll
total 9796
-rw-rw---- 1 oracle oinstall 1544 Mar 25 21:00 hc_OCPLHR1.dat
-rw-rw---- 1 oracle oinstall 1544 Mar 22 20:02 hc_OCPLHR2.dat
-rw-r----- 1 oracle oinstall 24 Mar 25 20:26 lkDUMMY
-rw-r----- 1 oracle oinstall 24 Jan 17 20:08 lkOCPLHR1
-rw-r----- 1 oracle oinstall 24 Jan 17 20:16 lkOCPLHR2
-rw-r----- 1 oracle oinstall 1536 Mar 25 20:09 orapwOCPLHR1
-rw-r----- 1 oracle oinstall 1536 Jan 17 20:25 orapwOCPLHR2
-rw-r----- 1 oracle oinstall 9977856 Mar 25 20:58 snapcf_OCPLHR1.f
-rw-r----- 1 oracle oinstall 3584 Mar 25 20:54 spfileOCPLHR1.ora
-rw-r----- 1 oracle oinstall 2560 Mar 25 19:54 spfileOCPLHR2.ora
[oracle@OCPLHR dbs]$ cp snapcf_OCPLHR1.f /u01/app/oracle/oradata/OCPLHR1/control01.ctl
[oracle@OCPLHR dbs]$ cp snapcf_OCPLHR1.f /u01/app/oracle/fast_recovery_area/OCPLHR1/control02.ctl
[oracle@OCPLHR dbs]$
[oracle@OCPLHR dbs]$
[oracle@OCPLHR dbs]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Sun Mar 25 21:01:41 2018
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: OCPLHR1 (not mounted)
RMAN> alter database mount;
using target database control file instead of recovery catalog
database mounted
RMAN> alter database open;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 03/25/2018 21:02:09
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
RMAN> alter database open RESETLOGS;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 03/25/2018 21:02:17
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/app/oracle/oradata/OCPLHR1/system01.dbf'
RMAN> recover datafile 1;
Starting recover at 2018-03-25 21:02:30
Starting implicit crosscheck backup at 2018-03-25 21:02:30
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=129 device type=DISK
Crosschecked 28 objects
Finished implicit crosscheck backup at 2018-03-25 21:02:31
Starting implicit crosscheck copy at 2018-03-25 21:02:31
using channel ORA_DISK_1
Crosschecked 4 objects
Finished implicit crosscheck copy at 2018-03-25 21:02:32
searching for all files in the recovery area
cataloging files...
no files cataloged
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/25/2018 21:02:32
RMAN-06067: RECOVER DATABASE required with a backup or created control file
RMAN> recover database;
Starting recover at 2018-03-25 21:03:17
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 1 is already on disk as file /u01/app/oracle/oradata/OCPLHR1/redo01.log
archived log file name=/u01/app/oracle/oradata/OCPLHR1/redo01.log thread=1 sequence=1
media recovery complete, elapsed time: 00:00:01
Finished recover at 2018-03-25 21:03:18
RMAN> alter database open ;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 03/25/2018 21:03:32
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
RMAN> alter database open NORESETLOGS;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "identifier": expecting one of: "resetlogs, ;"
RMAN-01008: the bad identifier was: NORESETLOGS
RMAN-01007: at line 1 column 21 file: standard input
RMAN> alter database open RESETLOGS;
database opened
RMAN>
一.1.1.4 重建控制文件---無備份情況下的恢復
alter database backup controlfile to trace as '/home/oracle/aa.txt';
告警信息：
Sun Mar 25 21:06:42 2018
alter database backup controlfile to trace as '/home/oracle/aa.txt'
Completed: alter database backup controlfile to trace as '/home/oracle/aa.txt'
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "OCPLHR1" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u01/app/oracle/oradata/OCPLHR1/redo01.log' SIZE 50M BLOCKSIZE 512,
GROUP 2 '/u01/app/oracle/oradata/OCPLHR1/redo02.log' SIZE 50M BLOCKSIZE 512,
GROUP 3 '/u01/app/oracle/oradata/OCPLHR1/redo03.log' SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/oradata/OCPLHR1/system01.dbf',
'/u01/app/oracle/oradata/OCPLHR1/sysaux01.dbf',
'/u01/app/oracle/oradata/OCPLHR1/undotbs01.dbf',
'/u01/app/oracle/oradata/OCPLHR1/users01.dbf',
'/u01/app/oracle/oradata/OCPLHR1/example01.dbf'
CHARACTER SET ZHS16GBK
;
-- Configure RMAN configuration record 1
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('RETENTION POLICY','TO REDUNDANCY 3');
-- Configure RMAN configuration record 2
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('BACKUP OPTIMIZATION','ON');
-- Configure RMAN configuration record 3
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP','ON');
-- Configure RMAN configuration record 4
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE','DISK TO ''/bak/cf_%F.ctl''');
-- Configure RMAN configuration record 5
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('DEVICE TYPE','DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET');
-- Configure RMAN configuration record 6
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('DATAFILE BACKUP COPIES FOR DEVICE TYPE','DISK TO 1');
-- Commands to re-create incarnation table
-- Below log names MUST be changed to existing filenames on
-- disk. Any one log file from each branch can be used to
-- re-create incarnation records.
-- ALTER DATABASE REGISTER LOGFILE '/u01/app/oracle/fast_recovery_area/OCPLHR1/archivelog/2018_03_25/o1_mf_1_1_%u_.arc';
-- ALTER DATABASE REGISTER LOGFILE '/u01/app/oracle/fast_recovery_area/OCPLHR1/archivelog/2018_03_25/o1_mf_1_1_%u_.arc';
-- ALTER DATABASE REGISTER LOGFILE '/u01/app/oracle/fast_recovery_area/OCPLHR1/archivelog/2018_03_25/o1_mf_1_1_%u_.arc';
-- ALTER DATABASE REGISTER LOGFILE '/u01/app/oracle/fast_recovery_area/OCPLHR1/archivelog/2018_03_25/o1_mf_1_1_%u_.arc';
-- ALTER DATABASE REGISTER LOGFILE '/u01/app/oracle/fast_recovery_area/OCPLHR1/archivelog/2018_03_25/o1_mf_1_1_%u_.arc';
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE
-- Block change tracking was enabled, so re-enable it now.
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/home/oracle/bct_ocplhr1.log' REUSE;
-- Set Database Guard and/or Supplemental Logging
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
-- All logs need archiving and a log switch is needed.
ALTER SYSTEM ARCHIVE LOG ALL;
-- Database can now be opened normally.
ALTER DATABASE OPEN;
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/OCPLHR1/temp01.dbf'
SIZE 30408704 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;
一、 重建控制文件resetlogs和noresetlogs的區別
重建控制文件又分兩種情況：resetlogs 和noresetlogs。使用使用resetlogs 重建控制文件后，RMAN恢復又會涉及到incarnation 問題，resetlogs只需要數據文件在位，而Noresetlogs 就不會出現incarnation的問題，但是必須是數據文件和online log文件都在位。
如何選擇哪個腳本來恢復控制文件的關鍵就在於：
1.Set NORESETLOGS case
The following commands will create a new control file and use it to open the database.
Data used by Recovery Manager will be lost.
Additional logs may be required for media recovery of offline.
Use this only if the current versions of all online logs are available.
2.Set RESETLOGS case
The following commands will create a new control file and use it to open the database.
Data used by Recovery Manager will be lost.
The contents of online logs will be lost and all backups will be invalidated.
Use this only if online logs are damaged.
一：注意事項：
1 指定reuse
表明被初始化參數CONTROL_FILES 識別的控制文件能夠被覆蓋使用。如果忽略該參數，任何已經存在的控制文件被數據庫檢測到，則返回一個報錯。
2 指定SET DATABASE
表明要更改數據庫的名字，名字長度能達到8個字節。除此之外，你必須指定resetlogs語句，如果你想重新命名數據庫的名字，並保留已經存在的日志文件，則創建控制文件語句執行后
使用alter database recover using bakcup controlfile 語句執行一個完全數據庫恢復。
3 指定resetlogs
indicate 忽略日志文件內容，或者日志文件不存在。
指定datafile
除了只讀表空間的文件（可以之后添加）和臨時表空間的數據文件，列出所有數據文件，就算這些文件需要進行恢復。
4 ARCHIVELOG | NOARCHIVELOG
如果忽略了ARCHIVELOG | NOARCHIVELOG oracle默認采用非歸檔模式。
二實驗步驟：
1 以noresetlogs方式創建控制文件，控制文件內容
[oracle@oracle backup]$ cat control.sql
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "CRM" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/oracle/CRM/redo01.log' SIZE 200M BLOCKSIZE 512,
GROUP 2 '/oracle/CRM/redo02.log' SIZE 200M BLOCKSIZE 512,
GROUP 3 '/oracle/CRM/redo03.log' SIZE 200M BLOCKSIZE 512,
GROUP 4 '/oracle/CRM/redo02.dbf' SIZE 200M BLOCKSIZE 512
DATAFILE
'/oracle/CRM/system01.dbf',
'/oracle/CRM/sysaux01.dbf',
'/oracle/CRM/undotbs01.dbf',
'/backup/users01.dbf',
'/oracle/CRM/pos.dbf',
'/oracle/CRM/erp.dbf',
'/oracle/CRM/user01.dbf',
'/oracle/CRM/undotbs02.dbf'
CHARACTER SET ZHS16GBK
;
2 以resetlogs方式創建控制文件，控制文件內容
cat control.sql
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "CRM" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/oracle/CRM/redo01.log' SIZE 200M BLOCKSIZE 512,
GROUP 2 '/oracle/CRM/redo02.log' SIZE 200M BLOCKSIZE 512,
GROUP 3 '/oracle/CRM/redo03.log' SIZE 200M BLOCKSIZE 512,
GROUP 4 '/oracle/CRM/redo02.dbf' SIZE 200M BLOCKSIZE 512
DATAFILE
'/oracle/CRM/system01.dbf',
'/oracle/CRM/sysaux01.dbf',
'/oracle/CRM/undotbs01.dbf',
'/backup/users01.dbf',
'/oracle/CRM/pos.dbf',
'/oracle/CRM/erp.dbf',
'/oracle/CRM/user01.dbf',
'/oracle/CRM/undotbs02.dbf'
CHARACTER SET ZHS16GBK
;
3 恢復過程
noresetlogs方式
SQL> @/backup/control.sql
ORACLE instance started.
Total System Global Area 1252663296 bytes
Fixed Size 2226072 bytes
Variable Size 1006635112 bytes
Database Buffers 234881024 bytes
Redo Buffers 8921088 bytes
Control file created.
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-00264: no recovery required
SQL> alter database open;
Database altered.
resetlogs方式
SQL> @/backup/control.sql
ORACLE instance started.
Total System Global Area 1252663296 bytes
Fixed Size 2226072 bytes
Variable Size 1006635112 bytes
Database Buffers 234881024 bytes
Redo Buffers 8921088 bytes
Control file created.
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
SQL> recover database using backup controlfile;
ORA-00279: change 2526007 generated at 08/26/2012 01:13:10 needed for thread 1
ORA-00289: suggestion : /oracle/archive/1_8_791790817.dbf
ORA-00280: change 2526007 for thread 1 is in sequence #8
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log '/oracle/archive/1_8_791790817.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log '/oracle/archive/1_8_791790817.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 2526007 generated at 08/26/2012 01:13:10 needed for thread 1
ORA-00289: suggestion : /oracle/archive/1_8_791790817.dbf
ORA-00280: change 2526007 for thread 1 is in sequence #8
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ WRITE
重建控制文件時resetlogs與noresetlogs的使用情況
控制文件中記錄着數據庫的數據文件,日志文件,備份數據等信息,更為重要的,控制文件中還記錄了數據庫的檢查點
和scn信息,這些信息在數據恢復的過程中將起到關鍵性作用.
一個正常運行的數據庫,通常控制文件都存在多份鏡像,這些鏡像的內容是完全相同的,oracle缺省就創建多份控制
文件更說明了控制文件的重要:
SQL> select name from v$controlfile;
NAME
--------------------------------------------------------------------------------
/u01/app/oracle/product/11.2.0/oradata/jingyong/control01.ctl
/u01/app/oracle/product/11.2.0/oradata/jingyong/control02.ctl
可以通過如下一條命令將控制文件的創建語句備份到跟蹤文件中:
SQL> alter database backup controlfile to trace;
Database altered.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_18818.trc
SQL> host sz /u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_18818.trc
rz
Starting zmodem transfer. Press Ctrl+C to cancel.
100% 8 KB 8 KB/s 00:00:01 0 Errors
此跟蹤文件中會記錄控制文件的創建腳本,腳本包含兩個主要的段落,其中一段如下所示:
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "JINGYONG" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log' SIZE 50M BLOCKSIZE 512,
GROUP 2 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log' SIZE 50M BLOCKSIZE 512,
GROUP 3 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log' SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf',
'/u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf',
'/u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf',
'/u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf',
'/u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf',
'/u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf'
CHARACTER SET ZHS16GBK
;
當數據庫處於nomount狀態下時,可以通過運行這段腳本創建控制文件,控制文件會自動創建到參數文件中
記錄控制文件的位置(原來的控制文件在創建過程會被覆蓋).這里需要理解的一個主要選項是:
noresetlogs/resetlogs.在跟蹤文件中包含如下注釋,詳細解釋了這兩個選項的含義:
-- Below are two sets of SQL statements, each of which creates a new
-- control file and uses it to open the database. The first set opens
-- the database with the NORESETLOGS option and should be used only if
-- the current versions of all online logs are available. The second
-- set opens the database with the RESETLOGS option and should be used
-- if online logs are unavailable.
-- The appropriate set of statements can be copied from the trace into
-- a script. file, edited as necessary, and executed when there is a
-- need to re-create the control file.
當數據庫當前的redo log都可用時,可以通過noresetlogs參數重建控制文件,此時oracle能夠從日志文件中
讀取redo信息,記錄到控制文件中,由於redo中記錄的信息足以重演所有提交成功的事務,所以最終能夠實現
完全恢復,成功打開數據庫,這時的數據庫就如同進行了一次斷電之后的實例恢復,數據沒有損失,重做日志
可以繼續向前寫入:
下面測試來看一下以noresetlogs重建控制文件進行數據庫恢復的過程
先在數據庫正常運行狀態下對控制文件執行一次轉儲:
SQL> alter session set events 'immediate trace name controlf level 12';
Session altered.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_19350.trc
這個轉儲文件中將包含數據庫的檢查點,redo thread信息,數據文件等信息,看一下
log file records內容:
***************************************************************************
LOG FILE RECORDS
***************************************************************************
(size = 72, compat size = 72, section max = 16, section in-use = 3,
last-recid= 3, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 10, numrecs = 16)
LOG FILE #1:
name #3: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x19000 seq: 0x00000010 hws: 0x2 bsz: 512 nab: 0x1e flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000ea466
Low scn: 0x0000.000ea474 05/02/2013 11:40:58
Next scn: 0x0000.000ea4db 05/02/2013 11:44:07
LOG FILE #2:
name #2: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log
Thread 1 redo log links: forward: 3 backward: 1
siz: 0x19000 seq: 0x00000011 hws: 0x1 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000ea474
Low scn: 0x0000.000ea4db 05/02/2013 11:44:07
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #3:
name #1: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x19000 seq: 0x0000000f hws: 0x2 bsz: 512 nab: 0x2 flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000e8ed8
Low scn: 0x0000.000ea466 05/02/2013 11:40:52
Next scn: 0x0000.000ea474 05/02/2013 11:40:58
從記錄信息中我們可以看到redo02.log文件的next scn:0xffff.ffffffff,所以redo02.log文件是當前的
日志文件,我們可以從v$log視圖中查看當前的重做日志組
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 CURRENT
3 INACTIVE
接下來通過shutdown abort模擬一次數據庫故障:
SQL> shutdown abort;
ORACLE instance shut down.
啟動數據庫到nomount狀態,再來使用noresetlogs參數來重建控制文件:
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 238530560 bytes
Fixed Size 1335724 bytes
Variable Size 150998612 bytes
Database Buffers 83886080 bytes
Redo Buffers 2310144 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "JINGYONG" NORESETLOGS ARCHIVELOG
2 MAXLOGFILES 16
3 MAXLOGMEMBERS 3
4 MAXDATAFILES 100
5 MAXINSTANCES 8
6 MAXLOGHISTORY 292
7 LOGFILE
8 GROUP 1 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log' SIZE 50M BLOCKSIZE 512,
9 GROUP 2 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log' SIZE 50M BLOCKSIZE 512,
10 GROUP 3 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log' SIZE 50M BLOCKSIZE 512
11 -- STANDBY LOGFILE
12 DATAFILE
13 '/u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf',
14 '/u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf',
15 '/u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf',
16 '/u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf',
17 '/u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf',
18 '/u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf'
19 CHARACTER SET ZHS16GBK
20 ;
Control file created.
此時再來對控制文件進行一次轉儲,檢查log file records部分:
SQL> alter session set events 'immediate trace name controlf level 12';
Session altered.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_19438.trc
***************************************************************************
LOG FILE RECORDS
***************************************************************************
(size = 72, compat size = 72, section max = 16, section in-use = 3,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 10, numrecs = 16)
LOG FILE #1:
name #2: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x19000 seq: 0x00000010 hws: 0x2 bsz: 512 nab: 0x1e flg: 0x0 dup: 1
Archive links: fwrd: 2 back: 3 Prev scn: 0x0000.000ea466
Low scn: 0x0000.000ea474 05/02/2013 11:40:58
Next scn: 0x0000.000ea4db 05/02/2013 11:44:07
LOG FILE #2:
name #1: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log
Thread 1 redo log links: forward: 3 backward: 1
siz: 0x19000 seq: 0x00000011 hws: 0x1 bsz: 512 nab: 0xffffffff flg: 0xa dup: 1
Archive links: fwrd: 0 back: 1 Prev scn: 0x0000.000ea474
Low scn: 0x0000.000ea4db 05/02/2013 11:44:07
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #3:
name #3: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x19000 seq: 0x0000000f hws: 0x2 bsz: 512 nab: 0x2 flg: 0x0 dup: 1
Archive links: fwrd: 1 back: 0 Prev scn: 0x0000.00000000
Low scn: 0x0000.000ea466 05/02/2013 11:40:52
Next scn: 0x0000.000ea474 05/02/2013 11:40:58
從上面的記錄我們可以看到重建的控文件能夠從當前的日志文件獲得正確的SCN及時間點等信息.同樣地,控制
文件也能夠從數據文件中獲得詳細的檢查點信息:
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(size = 520, compat size = 520, section max = 100, section in-use = 6,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1:
name #9: /u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf
creation size=0 block size=8192 status=0x12 head=9 tail=9 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:119 scn: 0x0000.000ea4db 05/02/2013 11:44:07
Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
Creation Checkpointed at scn: 0x0000.00000007 08/13/2009 23:00:53
thread:0 rba:(0x0.0.0)
.....
DATA FILE #2:
name #8: /u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf
creation size=0 block size=8192 status=0x12 head=8 tail=8 dup=1
tablespace 1, index=2 krfil=2 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:119 scn: 0x0000.000ea4db 05/02/2013 11:44:07
Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
Creation Checkpointed at scn: 0x0000.00000874 08/13/2009 23:00:57
thread:0 rba:(0x0.0.0)
.....
DATA FILE #3:
name #7: /u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf
creation size=0 block size=8192 status=0x12 head=7 tail=7 dup=1
tablespace 2, index=3 krfil=3 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:47 scn: 0x0000.000ea4db 05/02/2013 11:44:07
Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
Creation Checkpointed at scn: 0x0000.000b7982 08/13/2009 23:56:54
thread:0 rba:(0x0.0.0)
.....
DATA FILE #4:
name #6: /u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf
creation size=0 block size=8192 status=0x12 head=6 tail=6 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:118 scn: 0x0000.000ea4db 05/02/2013 11:44:07
Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
Creation Checkpointed at scn: 0x0000.00004743 08/13/2009 23:01:06
thread:0 rba:(0x0.0.0)
....
DATA FILE #5:
name #5: /u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf
creation size=0 block size=8192 status=0x12 head=5 tail=5 dup=1
tablespace 6, index=5 krfil=5 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:43 scn: 0x0000.000ea4db 05/02/2013 11:44:07
Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
Creation Checkpointed at scn: 0x0000.000bf3fe 04/25/2013 14:05:52
thread:0 rba:(0x0.0.0)
....
DATA FILE #6:
name #4: /u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf
creation size=0 block size=8192 status=0x12 head=4 tail=4 dup=1
tablespace 7, index=6 krfil=6 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:11 scn: 0x0000.000ea96d 05/02/2013 12:00:47
Stop scn: 0xffff.ffffffff 05/02/2013 12:44:28
Creation Checkpointed at scn: 0x0000.000e9b4f 05/02/2013 08:43:22
thread:0 rba:(0x0.0.0)
.....
從上面的信息可以知道由於數據庫是異常關閉的,所以數據文件的Stop scn:為無窮大:
Stop scn: 0xffff.ffffffff,接下來對數據庫執行恢復,當恢復完成后再對控制文件進行轉儲:
SQL> recover database;
Media recovery complete.
SQL> alter session set events 'immediate trace name controlf level 12';
Session altered.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_19450.trc
來觀察此跟蹤文件中的數據文件信息:
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(size = 520, compat size = 520, section max = 100, section in-use = 6,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1:
name #9: /u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf
creation size=0 block size=8192 status=0x2 head=9 tail=9 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:120 scn: 0x0000.000efd7d 05/02/2013 12:43:16
Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
Creation Checkpointed at scn: 0x0000.00000007 08/13/2009 23:00:53
thread:0 rba:(0x0.0.0)
....
DATA FILE #2:
name #8: /u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf
creation size=0 block size=8192 status=0x2 head=8 tail=8 dup=1
tablespace 1, index=2 krfil=2 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:120 scn: 0x0000.000efd7d 05/02/2013 12:43:16
Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
Creation Checkpointed at scn: 0x0000.00000874 08/13/2009 23:00:57
thread:0 rba:(0x0.0.0)
....
DATA FILE #3:
name #7: /u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf
creation size=0 block size=8192 status=0x2 head=7 tail=7 dup=1
tablespace 2, index=3 krfil=3 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:48 scn: 0x0000.000efd7d 05/02/2013 12:43:16
Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
Creation Checkpointed at scn: 0x0000.000b7982 08/13/2009 23:56:54
thread:0 rba:(0x0.0.0)
....
DATA FILE #4:
name #6: /u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf
creation size=0 block size=8192 status=0x2 head=6 tail=6 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:119 scn: 0x0000.000efd7d 05/02/2013 12:43:16
Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
Creation Checkpointed at scn: 0x0000.00004743 08/13/2009 23:01:06
thread:0 rba:(0x0.0.0)
....
DATA FILE #5:
name #5: /u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf
creation size=0 block size=8192 status=0x2 head=5 tail=5 dup=1
tablespace 6, index=5 krfil=5 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:44 scn: 0x0000.000efd7d 05/02/2013 12:43:16
Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
Creation Checkpointed at scn: 0x0000.000bf3fe 04/25/2013 14:05:52
thread:0 rba:(0x0.0.0)
....
DATA FILE #6:
name #4: /u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf
creation size=0 block size=8192 status=0x2 head=4 tail=4 dup=1
tablespace 7, index=6 krfil=6 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:12 scn: 0x0000.000efd7d 05/02/2013 12:43:16
Stop scn: 0x0000.000efd7d 05/02/2013 12:43:16
Creation Checkpointed at scn: 0x0000.000e9b4f 05/02/2013 08:43:22
thread:0 rba:(0x0.0.0)
....
經過恢復之后,數據文件達到了一致狀態,checkpoint scn(0x0000.000efd7d)和Stop scn(0x0000.000efd7d)
達到了一致,此時數據庫就完成了恢復,數據庫可以順利啟動:
SQL> ALTER SYSTEM ARCHIVE LOG ALL;
System altered.
SQL> ALTER DATABASE OPEN;
Database altered.
SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/product/11.2.0/oradata/jingyong/temp01.dbf'
2 SIZE 30M REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 40M;
Tablespace altered.
現在我們來實驗使用resetlogs方式來重建控制文件:
模擬數據庫故障
SQL> shutdown abort;
ORACLE instance shut down.
以resetlogs來重建控制文件
SQL> startup nomount
ORACLE instance started.
Total System Global Area 238530560 bytes
Fixed Size 1335724 bytes
Variable Size 150998612 bytes
Database Buffers 83886080 bytes
Redo Buffers 2310144 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "JINGYONG" RESETLOGS ARCHIVELOG
2 MAXLOGFILES 16
3 MAXLOGMEMBERS 3
4 MAXDATAFILES 100
5 MAXINSTANCES 8
6 MAXLOGHISTORY 292
7 LOGFILE
8 GROUP 1 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log' SIZE 50M BLOCKSIZE 512,
9 GROUP 2 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log' SIZE 50M BLOCKSIZE 512,
10 GROUP 3 '/u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log' SIZE 50M BLOCKSIZE 512
11 -- STANDBY LOGFILE
12 DATAFILE
13 '/u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf',
14 '/u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf',
15 '/u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf',
16 '/u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf',
17 '/u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf',
18 '/u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf'
19 CHARACTER SET ZHS16GBK
20 ;
Control file created.
此時對控制文件進行一次轉儲
SQL> alter session set events 'immediate trace name controlf level 12';
Session altered.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_19598.trc
觀察轉儲的跟蹤文件中的log file record的信息:
***************************************************************************
LOG FILE RECORDS
***************************************************************************
(size = 72, compat size = 72, section max = 16, section in-use = 3,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 10, numrecs = 16)
LOG FILE #1:
name #3: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x19000 seq: 0x00000000 hws: 0x0 bsz: 512 nab: 0x0 flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00000000
Low scn: 0x0000.00000000 01/01/1988 00:00:00
Next scn: 0x0000.00000000 01/01/1988 00:00:00
LOG FILE #2:
name #2: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo02.log
Thread 1 redo log links: forward: 3 backward: 1
siz: 0x19000 seq: 0x00000000 hws: 0x0 bsz: 512 nab: 0x0 flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00000000
Low scn: 0x0000.00000000 01/01/1988 00:00:00
Next scn: 0x0000.00000000 01/01/1988 00:00:00
LOG FILE #3:
name #1: /u01/app/oracle/product/11.2.0/oradata/jingyong/redo03.log
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x19000 seq: 0x00000000 hws: 0x0 bsz: 512 nab: 0x2 flg: 0xb dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00000000
Low scn: 0x0000.00000000 01/01/1988 00:00:00
Next scn: 0x0000.00000000 01/01/1988 00:00:00
從上面的信息可以看到此時控制文件中的日志信息都是空的,oracle認為resetlogs方式下,當前的日志文件
已經損壞,那么就意味着oracle可能會丟失提交成功的數據,恢復將是一次不完全的介質恢復.
此時的數據文件信息如下:
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(size = 520, compat size = 520, section max = 100, section in-use = 6,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1:
name #9: /u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf
creation size=0 block size=8192 status=0x12 head=9 tail=9 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:123 scn: 0x0000.000efd80 05/02/2013 12:53:11
Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
Creation Checkpointed at scn: 0x0000.00000007 08/13/2009 23:00:53
thread:0 rba:(0x0.0.0)
....
DATA FILE #2:
name #8: /u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf
creation size=0 block size=8192 status=0x12 head=8 tail=8 dup=1
tablespace 1, index=2 krfil=2 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:123 scn: 0x0000.000efd80 05/02/2013 12:53:11
Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
Creation Checkpointed at scn: 0x0000.00000874 08/13/2009 23:00:57
thread:0 rba:(0x0.0.0)
....
DATA FILE #3:
name #7: /u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf
creation size=0 block size=8192 status=0x12 head=7 tail=7 dup=1
tablespace 2, index=3 krfil=3 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:51 scn: 0x0000.000efd80 05/02/2013 12:53:11
Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
Creation Checkpointed at scn: 0x0000.000b7982 08/13/2009 23:56:54
thread:0 rba:(0x0.0.0)
....
DATA FILE #4:
name #6: /u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf
creation size=0 block size=8192 status=0x12 head=6 tail=6 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:122 scn: 0x0000.000efd80 05/02/2013 12:53:11
Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
Creation Checkpointed at scn: 0x0000.00004743 08/13/2009 23:01:06
thread:0 rba:(0x0.0.0)
....
DATA FILE #5:
name #5: /u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf
creation size=0 block size=8192 status=0x12 head=5 tail=5 dup=1
tablespace 6, index=5 krfil=5 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:47 scn: 0x0000.000efd80 05/02/2013 12:53:11
Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
Creation Checkpointed at scn: 0x0000.000bf3fe 04/25/2013 14:05:52
thread:0 rba:(0x0.0.0)
....
DATA FILE #6:
name #4: /u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf
creation size=0 block size=8192 status=0x12 head=4 tail=4 dup=1
tablespace 7, index=6 krfil=6 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:15 scn: 0x0000.000efd80 05/02/2013 12:53:11
Stop scn: 0xffff.ffffffff 05/02/2013 13:01:12
Creation Checkpointed at scn: 0x0000.000e9b4f 05/02/2013 08:43:22
thread:0 rba:(0x0.0.0)
....
從上面的信息可以知道由於數據庫是異常關閉的,所以數據文件的Stop scn:為無窮大:
Stop scn: 0xffff.ffffffff
不完全恢復最終要求數據庫通過resetlogs方式打開,resetlogs將會強制清空或重建聯機重做日志文件.
此時執行恢復必須使用backup controlfile選項,否則將會報錯:
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
SQL> recover database using backup controlfile;
ORA-00279: change 982400 generated at 05/02/2013 12:53:11 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/product/11.2.0/flash_recovery_area/JINGYONG/archivelog/2013_05_0
2/o1_mf_1_18_%u_.arc
ORA-00280: change 982400 for thread 1 is in sequence #18
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
如果在線日志操壞,那么恢復到最后,oracle提示的最后一個歸檔日志將是不存在的(如果在線日志沒有
損壞,則可以指定在線日志文件執行恢復),此時可以輸入cancel取消恢復,然后可以強制打開數據庫:
alter database open resetlogs;
SQL> recover database using backup controlfile;
ORA-00279: change 1003572 generated at 05/02/2013 13:20:06 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/product/11.2.0/flash_recovery_area/JINGYONG/archivelog/2013_05_0
2/o1_mf_1_19_%u_.arc
ORA-00280: change 1003572 for thread 1 is in sequence #19
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/product/11.2.0/oradata/jingyong/redo01.log
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/product/11.2.0/oradata/jingyong/temp01.dbf'
2 SIZE 30M REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 40M;
Tablespace altered.
二、 在線日志無損情況下的重建
然后就是添加臨時數據文件，注冊備份的信息，最后做備份等后續操作。
三、 在線日志損壞情況下的重建
四、 具有只讀數據文件情況下的重建
一.1.1.1 OCP
【OCP真題1】 Are using Recovery Manager (RMAN) with a recovery catalog to perform the backup operation at regular intervals使用恢復管理器（RMAN）對恢復目錄定期執行備份操作
Set the control file autobackup to “on” 設置控制文件自動備份為“開”
Are maintaining image copies of the database files維持數據庫映像文件的副本
You have lost the server parameter file (SPFILE) and the control file. Which option must you consider before restoring the SPFILIE: and the control file by using the control file autobackup? 你已經失去了服務器參數文件（SPFILE）和控制文件。恢復SPFILIE之前你認為哪個選項必須考慮：使用控制文件自動備份的控制文件？
A. setting DBID for the database
B. using the RMAN SWITCH command
C. using the RMAN SWITCH command使用RMAN切換命令 B和C一樣
D. starting up the database Instance In the NOMOUNT state
Answer: C
【OCP真題2】 Your database is up and running and one of your three control files is accidentally erased. You start RMAN and run the following command:
RESTORE CONTROLFILE FROM AUTOBACKUP;
Which of the following statements is true? (Choose all that apply.)
A. The command restores only the missing control file.
B. The command restores all the control files.
C. The command fails because the database is running.
D. This is the correct way to address this problem.
E. This is not the correct way to address this problem.
Answer: CE
【OCP真題3】 You have discovered that one of three control files has been lost. What steps would you follow to recover that control file? 你已經發現三個控制文件之一已丟失。為恢復控制文件，你會遵循以下什么樣的步驟？
a. Shut down the database. 關閉數據庫
b. Restore a control-file copy from backup media.
c. Use the create control file command to create a new control file.
d. Copy the backup control file into place.
e. Create a new copy of the control file from one of the surviving control files. 從一個幸存的控制文件創建一個新的控制文件的副本。
f. Recover the database using the recover database using backup controlfile command.
g. Start up the database. 啟動數據庫。
A. a, b, f, g
B. c, f, g
C. a, d, f, g
D. a, f, g
E. a, e, g
關閉數據庫; 從一個幸存的控制文件創建一個新的控制文件的副本; 啟動數據庫
Answer: E
【OCP真題4】 Your database is up and running and one of your three control files is accidentally erased. You start RMAN and run the following command: 你的數據庫在啟動和運行，你的三個控制文件之一被意外刪除。啟動RMAN並運行以下命令：
RESTORE CONTROLFILE FROM AUTOBACKUP;從自動備份中還原控制文件
Which of the following statements is true? (Choose all that apply .)
A. The command restores only the missing control file.
B. The command restores all the control files.
C. The command fails because the database is running. 該命令失敗，因為數據庫正在運行。
D. This is the correct way to address this problem.
E. This is not the correct way to address this problem. 這不是正確的方法來解決這個問題
This is not the correct way to address this problem. The command will fail because the database is
running. Additionally, this is not the correct way to approach the loss of one of several control files.
The better way to approach this loss is to shut down the database and simply copy one of the
surviving control files over to where the missing control file existed. 這是不是正確的方法來解決這個問題，該命令將失敗，因為數據庫正在運行。此外，這是不正確的方式來處理多個控制文件的損失之一。更好的方式來處理這方面的損失是關閉數據庫，並簡單地復制一個幸存的控制文件存在丟失的控制文件的地方。
Answer:
C,E
【OCP真題5】 You have lost all your database control files. To recover them, you are going to use the results of the alter database backup controlfile to trace command. Your datafiles and your online redo logs are all intact.
Which of the following is true regarding your recovery?
A. You will need to open the database with the resetlogs command.
B. All you need to do is execute the trace file from SQL*Plus and it will perform the recovery for you
C. You will use the resetlogs version of the create controlfile command.
D. You will use the noresetlogs version of the create controlfile command.
E. You will use the trace file to create a backup control file, and then you will recover the database with the recover database using backup controlfile command
Answer: D
About Me
.............................................................................................................................................
● 本文作者：小麥苗，部分內容整理自網絡，若有侵權請聯系小麥苗刪除
● 本文在itpub（http://blog.itpub.net/26736162/abstract/1/）、博客園（http://www.cnblogs.com/lhrbest）和個人微信公眾號（xiaomaimiaolhr）上有同步更新
● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/
● 本文博客園地址：http://www.cnblogs.com/lhrbest
● 本文pdf版、個人簡介及小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/
● 數據庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/
● DBA寶典今日頭條號地址：http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826
.............................................................................................................................................
● QQ群號：230161599（滿）、618766405
● 微信群：可加我微信，我拉大家進群，非誠勿擾
● 聯系我請加QQ好友（646634621），注明添加緣由
● 於 2018-04-01 06:00 ~ 2018-04-31 24:00 在魔都完成
● 最新修改時間：2018-04-01 06:00 ~ 2018-04-31 24:00
● 文章內容來源於小麥苗的學習筆記，部分整理自網絡，若有侵權或不當之處還請諒解
● 版權所有，歡迎分享本文，轉載請保留出處
.............................................................................................................................................
● 小麥苗的微店：https://weidian.com/s/793741433?wfr=c&ifr=shopdetail
● 小麥苗出版的數據庫類叢書：http://blog.itpub.net/26736162/viewspace-2142121/
● 小麥苗OCP、OCM、高可用網絡班：http://blog.itpub.net/26736162/viewspace-2148098/
.............................................................................................................................................
使用微信客戶端掃描下面的二維碼來關注小麥苗的微信公眾號（xiaomaimiaolhr）及QQ群（DBA寶典），學習最實用的數據庫技術。
小麥苗的微信公眾號 小麥苗的DBA寶典QQ群2 《DBA筆試面試寶典》讀者群 小麥苗的微店
.............................................................................................................................................
