今早的pub的一個帖子引起了自己的興趣，說到是錯誤刪除undo表空間資料檔案無法開啟，此時如果我們有恢復，那直接restore然後recover就行了！模擬下不用備份集恢復的情況吧！

關閉資料庫在os上刪除資料檔案13

SQL> shutdown abort；

資料庫已經關閉。

已經解除安裝資料庫。

ORACLE 例程已經關閉。

SQL> startup;

ORA-32004: obsolete and/or deprecated parameter(s) specified

ORACLE 例程已經啟動。

Total System Global Area 524288000 bytes

Fixed Size 1249968 bytes

Variable Size 390073680 bytes

Database Buffers 130023424 bytes

Redo Buffers 2940928 bytes

資料庫裝載完畢。

ORA-01157: 無法標識/鎖定資料檔案 13 - 請參閱 DBWR 跟蹤檔案

ORA-01110: 資料檔案 13: 'D:ORACLEPRODUCT10.2.0ORADATAORCLUNTBSO02.DBF'

SQL> alter database datafile 13 offline drop;

資料庫已更改。

Alter database datafile 13 offline drop並不會刪除此資料檔案，只是將資料檔案離線

歸檔模式：alter database datafile 'file_name' offline 和 offline drop 沒有什麼區別，因為都需要進行介質恢復。

非歸檔模式: 更多是offline drop

SQL> alter database open;

資料庫已更改。

剛開始自己想直接把這個資料檔案從untbso02表空間刪掉，不過報錯了！

資料庫已經open，如果我們刪除untbso02表空間的這個資料檔案13了

SQL> alter tablespace untbso02 drop datafile 13;

alter tablespace untbso02 drop datafile 13

*

第 1 行出現錯誤:

ORA-03263: 無法刪除表空間 UNTBSO02 的第一個檔案

表空間的第一個資料檔案無法刪除，首先儲存的表空間的後設資料

如果此時刪除表空間untbso02的其他檔案了，下面的datafile 6是先前已經建好的

SQL> alter tablespace untbso02 drop datafile 6;

alter tablespace untbso02 drop datafile 6

*

第 1 行出現錯誤:

ORA-03262: 檔案非空

SQL> alter tablespace untbso02 drop datafile 6;

alter tablespace untbso02 drop datafile 6

*

第 1 行出現錯誤:

ORA-03264: 無法刪除本地管理的表空間中的離線資料檔案

如果此時我們建立一個空的資料檔案則可以動態刪除。

SQL> alter tablespace untbso02 add datafile 'd:test01.dbf' size 10m;

表空間已更改。

SQL> alter tablespace untbso02 drop datafile 'd:test01.dbf';

表空間已更改。

看來對錶空間中的資料檔案只能在oracle中刪除非空和非第一個和online的資料檔案。

這裡重建一個undo刪除原來的undo

SQL> drop tablespace untbso02 including contents and datafiles;

表空間已刪除。

SQL> create tablespace undotbnew datafile 'd:oracleproduct10.2.0oradataorcl

undotbnew01.dbf' size 50M;

表空間已建立。

SQL> alter system set undo_tablespace=undotbnew scope=spfile;

系統已更改。

但是此時個人在這裡還是有個疑問的：此時我們刪除預設的undo表空間，由於資料庫是非正常關閉的，此時重啟資料庫時，很可能需要使用undo來恢復資訊，而由於丟失了undo表空間資料檔案，此時那部分undo資訊可能不存在了而使資料出現丟失了。

不過這裡如果有備份歸檔，那麼恢復將是非常輕鬆地事情的。

這裡說下隱含引數_allow_resetlogs_corruption的特殊恢復：

無備份，如果current重做日誌或者active日誌丟失順壞，非正常關閉會丟失提交的資料，由於意外關閉，空間檔案的stop scn和資料檔案頭的啟動scn不一致，而不一致是資料庫無法開啟的最終原因！而oracle提供了一個隱含引數_allow_resetlogs_corruption用於跳過一致性檢索強制開啟資料庫.

這裡就簡單列出其中的操作

Shutdown abort

Alter system set “_allow_resetlogs_corruption”=true scope=spfile

Startup mount

Recover database using backup controlfile until cancel

SQL> recover database using backup controlfile until cancel;

ORA-00279: 更改 2080349273 (在 11/25/2011 14:36:15 生成) 對於執行緒 1 是必需的

ORA-00289: 建議:

D:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREAORCLARCHIVELOG2011_11_25O1_MF_1_

174_%U_.ARC

ORA-00280: 更改 2080349273 (用於執行緒 1) 在序列 #174 中

指定日誌: {=suggested | filename | AUTO | CANCEL}

cancel

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 將出現如下錯誤

ORA-01194: 檔案 1 需要更多的恢復來保持一致性

ORA-01110: 資料檔案 1: 'D:ORACLEPRODUCT10.2.0ORADATAORCLSYSTEM01.DBF'

ORA-01112: 未啟動介質恢復

Alter database open resetlogs

此時比較幸運順利開啟了，之前第一次測試出現一大堆的ora-00600錯誤，然後馬上exp所有資料，重建資料庫imp。

另一次測試open resetlogs階段出現的ora-00600

Errors in file d:oracleproduct10.2.0adminorcludumporcl_ora_460.trc:

ORA-00600: 內部錯誤程式碼, 引數: [2662], [0], [2080349279], [0], [2109503153], [4194313], [], []

Fri Nov 25 17:23:09 2011

Errors in file d:oracleproduct10.2.0adminorcludumporcl_ora_460.trc:

ORA-00600: 內部錯誤程式碼, 引數: [2662], [0], [2080349279], [0], [2109503153], [4194313], [], []

Fri Nov 25 17:23:09 2011

Error 600 happened during db open, shutting down database

USER: terminating instance due to error 600

Fri Nov 25 17:23:09 2011

Errors in file d:oracleproduct10.2.0adminorclbdumporcl_pmon_2992.trc: