Home >Database >Mysql Tutorial >ORA-00600 4193的解决

ORA-00600 4193的解决

WBOY
WBOYOriginal
2016-06-07 17:22:141273browse

最近有客户的Oracle数据库数据文件出现错误,导致不能启动。经过恢复后,数据文件状态正常,数据库似乎可以open.(注意是状态正常

最近有客户的Oracle数据库数据文件出现错误,导致不能启动。
经过恢复后,数据文件状态正常,数据库似乎可以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数据库。

linux

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn