本文主要是介绍ORA-00600:存储坏了，修好后报ORA-00600的修复过程，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
存储坏了，修好后挂上，库打不开，处理过程
1，同步控制文件
2，把原来的undo设为空，创建新的UNDO表空间
经过这两步，库就可以开起来了
断电后Oracle数据库就open不了，报了：
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [44437], [17323], [18486], [
内部错误，然后执行以下操作：
recover database using backup controlfile until cancel;
ORA-00448: normal completion of background process
Slave exiting with ORA-283 exception
实例起不来，只能强制的将数据库启动，设置隐藏参数
在mounted下执行：alter system set "_allow_resetlogs_corruption"=true scope=spfile;
设置好后，alter database open;时，又报了以下错误：
ORA-00600: internal error code, arguments: [2662], [3600], [2803761690],
[3600], [2803771391], [12583040], [], [], [], [], [], []
结合以前处理过的600错误的经验，这个2662是scn不一致导致的错误，此时只能跳跃的人为干预将scn提高到一个值，其实
也只能是提高，应该没办法降低，在没有备份的情况下。
以为我数据库实例崩溃了，不能打开数据库，只能到mounted状态下，所以只能按照以下方式来提升SCN：
通过10015事件，在mount状态下
alter session set events '10015 trace name adjust_scn level 1';
其中的1是增加1亿，没记错的话，当然这个不是非常重要。
如果数据库可能打开的话，那么按照以下处理：
alter session set events 'IMMEDIATE trace name adjustT_scn level 1';
我记得有一次采用这个方式，提高的scn值很有限，因为一个是SCN相差非常大，第二是因为11g时默认不让你快速提高scn值得，
此时只能：
设置隐含参数_minimum_giga_scn 快速递增CURRENT SCN。
注：2012年1月后的PSU中包含隐含参数_external_scnrejection_threshold_hours,此时隐含参数和10015事件会失效。
调整好后执行 alter database open resetlogs；
conn ti/ti
ERROR:
ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [],
[], [], [], []
这个是因为undo表空间坏掉了，处理方式：
alter system set undo_management = manual scope=spfile;
SQL> alter system set undo_tablespace='' scope=spfile;
SQL>shutdown immediate
SQL>startup
SQL>create undo tablespace undotbs2 datafile 'E:\orcl_data\orcl\undotbs2.dbf' size 100M;
----设置undo管理方式为 ’自动‘
SQL> alter system set undo_management =auto scope=spfile;
----设置undotbs 为新建的undotbs2
SQL> alter system set undo_tablespace = undotbs2 scope=spfile;
----删除原来损坏的undo表空间
SQL> drop tablespace UNDOTBS1 including contents and datafiles;
SQL>shutdown immediate
SQL>startup
此时数据库能打开，就正常了。
此后最好将数据库备份下，有些坏了的表最好重新做一下，肯定会有并发比较高的表不一致的。
这篇关于ORA-00600:存储坏了，修好后报ORA-00600的修复过程的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
