ORA-00600 4193的解决

最近有客户的数据库数据文件出现错误,导致不能启动。
经过恢复后,数据文件状态正常,数据库似乎可以open.
(注意是状态正常,不代表数据库完全没问题,因为恢复过程中可能造成数据文件,表,索引的数据块损坏。)
 
启动数据库后,又报错ORA-00600 4193,导致数据库不能打开。
顺便提一句,我对数据库版本还是9i的系统的单位表示出极大的鄙视。话说这个单位还是一个重要的国家机器,把某个系统的数据库运维这么重要的工作交给别人,按理说应该相对有个健康的方案。结果呢,无备份,无备机,9i小垃圾版本。QNMD,玩不死才怪。再说说9i,身边的前辈都是做9i出来的,我以前也在某发达国家一个大型金融企业做过9i,那维护成本一个高,所以某国人也升级成了10g,那个死板的民族都可以,我们为啥不做?不过就是因为这样,也造就了早期一群DBA高手(就维护数据库和排查错误而言)。9i的bug真是如滔滔江水连绵不绝,又如黄河泛滥一发而不可收拾。特别是内存和数据块级别的错误,简直fuck了,尼玛碎片处理有木有,DB良心狗叼走。
 
吐槽N久,言归正传,ora-00600 4193是个常见错误,网上转载无数。总结一下以下三种办法:
1.数据库开启的情况下,重建undotbs,然后重新指定到新undotbs上。
2.未打开情况下,修改undo_management  参数为 manual或者(也有说并且的)提供新的回滚段。
 
继续吐槽,有且仅有一句:转载请负责,不实验下你永远不知道对不对。
 
对我来说用了以上的办法,数据库还是未打开,继续4193.
最后用了各种方法,连蒙带骗,修改undo_management  参数为auto,加了10几个回滚段(错一次要改一下回滚段的名字,试验中发现的,可能是数据块连续错误效应?),总算起来了数据库。但是非常fuck的是,无论什么操作(包括无数人都说对的重建undotbs,对你妹啊),都告诉你ora-00600 4193。换句话说,数据库起来了用不了,跟没起来区别不大。
 
继续吐槽,国内的技术文章有些很好,但遇到比较偏的问题的时候,真心垃圾,不懂的装懂,懂的又不肯多说。想找找谷歌和雅虎日本,又被河蟹~ 天朝技术人真是苦逼。
看了几篇非主流的技术文章,说的很好,就是说undo上有数据块错误,虽然没给出解决方案,但是我想可能是undotbs上的错误,于是用了最后一招,修改undo_management  参数为 manual,然后删除undo上所有的回滚段。
drop rollback segmet "_SYSSMU1$"
注意要加"",注意一定是回滚段offline状态,否则后果可能不堪设想。当然也可能删不了,哈哈。
 
这时数据库会提示你:滚,删尼玛,不让删。哼哼,那是因为安全级别不够,改一下spfile参数,把那个级别改成4就可以了。(具体哪个参数叫什么我忘了,很容易查的)
 
最后结果,数据库:重启db,ora-600 4193错误消失。我:被折腾死。
善后:保险起见,重建重指定undotbs;exp/imp数据库。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26865454/viewspace-746930/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/26865454/viewspace-746930/

你可能感兴趣的:(ORA-00600 4193的解决)