今早的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: