oracle 22922,EXP-00056 :遇到ORACLE错误 22922 导致数据库频繁宕机

在遇到这个问题的时候，首先登陆数据库，然后查询test 这张表，在查询到17299行时，报ORA-00600的错误。猜测可能是由于LOB字段引起的错误。定位到这些有问题的行后，尝试用delete 和update有问题的行时，都报ORA -00600 的错误。然后数据库就开始宕机。重启后，每隔10-15分钟自动宕机。

在重启数据库的时候，查看数据库的alert 日志发现，发现数据库在open 后，数据库尝试回滚一个事务，ORACLE Instance qcdb (pid = 8) - Error 600 encountered while recovering transaction (3, 21) on object 405872.

每隔五分钟一次，尝试四次后，

报ORA-27300: OS system dependent operation:invalid_process failed with status: 0

ORA-27301: OS failure message: Error 0

ORA-27302: failure occurred at: skgpstime3

ORA-27144: attempt to kill process failed

ORA-00474: SMON process terminated with error

然后数据库自动的宕机。非常的有规律

数据库open 后，查询v$rollstat后，发现所有的回滚段均是正常的状态，查询v$rollname后，发现3号回滚段的名称是_SYSSMU3$。

查看回滚事务的object_id=405872 就是删除没有成功的表test ,因此就更加肯定，是因为那么没有成功的事务，在数据库重启的时候，SMON进程尝试回滚这个僵死的事务，但是没有成功，造成数据库的宕机。

查看了相关的dump 文件

/export/home/oracle10/oracle/app/admin/qcdb/bdump/qcdb_smon_930042.trc

认为可能是数据库的BUG，QC数据库的版本是10.2.0.1 ，非常的低，存在很多BUG，决定升级到10.2.0.5.在备份了数据库的home 目录后(数据文件、控制文件、日志文件、参数文件之前已经备份完成)，开始升级，升级到10.2.0.5后，在升级数据字典时，发现数据库宕机问题任然存在。决定先采取规避错误的办法，完成数据字典的升级，采取的措施是，在数据库open 后设置两个事件10061、10513 。10513 事件是禁止SMON恢复死事务，10061 事件禁止SMON清理临时段。

ORA-10513:trun off wrap source compression

ORA-10061:disable SMON from cleaning temp segment

还修改了一个参数：fast_start_parallel_rollback :事务并行恢复。

但是这些设置后，然后不能解决数据库宕机问题，然后决定在启动的时候加入这些参数，重新的创建pfile ,用pfile 启动，(这些启动的模式是startup upgrade 数据库升级模式)，这样解决了数据库的宕机问题，完成了数据库的升级操作。

升级完成后，直接stratup 还是有问题，最后，采取了_offline_rollback_segment=’_SYSSMU3$’的办法，暂时的解决数据库不回滚数据库僵死的事务，但是QC业务还是不能正常的使用。后面oracle工程师把_SYSSMU3$回滚段删除(具体为什么要删除，原因也不是很清楚，是按照文档上面做的)，数据库又重新的宕机，而且时间更快，最后，采取了用昨天的冷备全部还原的方式，回到了最处的状态。重新的设置隐含参数，打开数据库，至此数据库宕机问题解决，但是最根本的问题并没有彻底的解决。

总结：10.2.0.1 的数据库的Bug非常的多，正常情况下，我一致性关闭数据库后，在重启数据库的时候，就不可能有事务的回滚，但是我们的库却一直在回滚事务。还有很多奇怪的问题。报一些奇怪的错误。以后，大家在正常情况下，尽量把自己的库的版本生的稍微高一点。还有备份大于一切，如果有备份的话，也是很容易就能解决此事。