建表空间的时候数据库宕机

今天在建表空间的时候,数据库不知道被谁停了,在建的时候报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!!

相关文章

6条评论

  1. re NinGoo:你们alertlog是怎么做监控的呢,是grep ORA的关键字吗?

    re David.Guo:你的网站偶也常去的,不过,不可能每篇文章都记得住呀~~

  2. 其实,DBA不仅是个技术职位,管理和沟通也很重要,如果从管理制度上杜绝大于一个技术人员在同一时间对数据库进行操作就不会出现这个问题;同时,如果是很好的沟通,这个问题应该也可以避免。其实,绝大部分的问题都是人为操作不当,而混乱的管理和不畅的沟通扮演着重要角色。技术、沟通能力和项目管理能力是DBA,特别是高级DBA的必备技能。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据