若是控制文件損壞那麼如何恢復？恢復控制文件的方式有哪幾種

 

【RMAN】若是控制文件損壞那麼如何恢復？恢復控制文件的方式有哪幾種？

---

---

 

真題一、若是控制文件損壞那麼如何恢復？恢復控制文件的方式有哪幾種？

答案：若是控制文件有多個，而只損壞了單個控制文件，那麼只須要關閉數據庫，拷貝其它好的控制文件覆蓋掉壞的控制文件便可。也能夠修改參數文件，只保留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/

 

 

 

真題一、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 命令從現有控制文件恢復控制文件。 RMAN> restore controlfile from '+DATA/orcl/controlfile/current.260.695209463'; • 若是控制文件存儲爲常規文件系統文件，則： – 關閉數據庫。 – 複製現有的控制文件來替代丟失的控制文件。 成功恢復控制文件後，打開數據庫。   版權全部 © 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  有備份狀況下的恢復

1、 控制文件之一丟失(單個控制文件丟失或損壞)

正確的處理步驟：

① 關閉數據庫

② 從其它位置拷貝一個

③ 啓動數據庫

 

  咱們知道數據庫的控制文件都不止一個（通常爲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.

 注：單個控制文件損壞也可使用下面所講的所有控制文件損壞時的恢復方法，只是這裏直接重命名其餘控制文件的方法比較快，也是推薦的一種恢復方法。

 

2、 各類狀況下的丟失

 

一、 已知備份文件位置

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參數時建立控制文件時使用的規則同樣。

 

二、 使用了恢復目錄

當沒有使用恢復目錄時，必須從控制文件自動備份中還原控制文件。若是從控制文件自動備份中還原控制文件，數據庫必須置於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來打開數據庫。

 

 

三、 設置了設置閃回區

設置閃回區的狀況下還原控制文件所使用的命令是相同的。然而若是當前數據庫正在使用閃回區，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

 

四、 缺失歸檔日誌的狀況下的恢復

 

衆所周知，恢復控制文件時「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等命令再添加回去。

 

 

1、當前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>

 

2、屢次切換日誌後，如今的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...

 

3、下面，咱們開始恢復：

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 ~]#

 

4、下面咱們掛載數據庫：

RMAN> mount database;

 

database mounted

released channel: ORA_DISK_1

 

RMAN>

 

5、下邊恢復數據庫將報錯，表示找不到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'

 

 

 

6、分析緣由，首先查看目前已知的歸檔文件最大的日誌序列號是多少？

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結尾

 

 

 

 

3、 使用控制文件快照

使用控制文件的快照進行恢復，其實也是一種採用備份來進行恢復的策略。

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;

1、 重建控制文件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