OracleBlog.cn -天堂向左 DBA向右

今天在建表空间的时候，数据库不知道被谁停了，在建的时候报oracle not avaliable，等再次确认没有“雷锋”帮我shutdown数据库之后，startup了数据库。启动时，没有报错，提示数据库已经mount、已经open。

可是，再次重建表空间的时候，却报错了数据文件已经存在：

检查了一下这个数据文件，发现在v$datafile中能找到，且状态是offine状态，但是在dba_data_files中找不到：

为了能新（重）建表空间，尝试把表空间drop，但是报错表空间已经不存在：

那只能先offline drop 数据文件了（数据库在非归档模式）：

ok！！在此以为总大功告成了吧，来我们重建表空间！可是接下来的事情却让人那么的沮丧：

由于ts_data_r_001g_001.dbf文件一直存在，无法offline drop，无论怎么操作，都能在v$datafile中看到它，那么我索性就干脆先把它online在尝试offline drop吧：

这里，终于看到ts_data_r_001g_001.dbf再次执行offline drop之后，状态变成recover了……（但是也奇怪，如果offline drop了，这里应该也是看不到才对呀）。

好，我们现在再试试重建表空间：

不幸的是，这个该死的ts_data_r_001g_001.dbf始终无法去掉！！

开始想偏方了……我为何不建一个表空间ts_data_r，且用另外一个数据文件ts_data_r_001g_002.dbf，等建立之后，我再drop tablespace，这样不就可以把ts_data_r_001g_001.dbf一起干掉了吗？

orz……终于把oracle惹毛了，直接把我的session断掉了！！此时去看alertlog中，一堆600的报错：

仔细看了一下报600错之前的alertlog，偶滴神！！原来alertlog中在意外宕机再次启动的时候，已经有报错信息和相关处理建议了。本来觉得v$datafile是mount时候能查到的视图，dba_data_files是open时候能查到的视图，2者不一致，能用绝招就是重建控制文件，但是……死活想用别的办法解决，就是不想重建控制文件！！-_-!!偶TMD还真固执：

最后，shutdown immedate，挂死，pmon切出大量600报错的日志，再尝试shutdown abort，终于关闭。再次startup，smon切出大量日志，提示数据库mount、数据库open，open之后，用alter database backup controlfile to trace as ‘/oracle/111.txt’获取重建控制文件的脚本，修改脚本中ts_data_r_001g_001.dbf存在的这个文件。再尝试shutdown immediate，正常关闭，再次startup 到nomount后重建控制文件，open resetlogs，终于……搞定了！：

        本次故障解决的过程其实难度并不大，但是给了我们一个教训：对于异常宕机，再次启动，虽然在启动的时候不提示什么，但是只要是异常宕机，就一定要看alertlog！！