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/