love wife love life —Roger的Oracle/MySQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

Deep in ora-00600 [4193]

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL数据恢复博客

本文链接地址: Deep in ora-00600 [4193]

这是一个网友的问题,10201的windows环境,非归档,无备份,数据库open的时候报常见的ORA-00600 4193错误。

这个错误很常见,我们也分析过多次,这里再次来看下网友这里的情况。其中alert log如下:

对于ORA-00600 4193错误,Oracle docs是这样解释的:

通过查看网友传的alert log信息,发现这哥们进行了大量的操作,几乎把所有的恢复动作都试了一遍。如下:

我们可以看到他使用了event 来屏蔽smon的回滚段,使用了隐含参数强制打开,使用了undo参数来修改表空间。据说还使用了强制
offline 回滚段的一些参数。

实际上,针对这个问题,我们先不管怎么解决,首先我们需要分析为什么Oracle这里会报这个错误?

首先有几个问题:

1) Oracle 在open的过程之中是执行什么sql报错的?
2) 为什么会报错
3)如果强制屏蔽回滚段是否有影响?

对于第一个问题,很简单,我们搜索trace就很容易定位到是这个SQL在执行时报错的:

进一步搜索,我们还可以定位到Oracle在执行这个递归SQL时,是在操作什么回滚段的时候报错的(这里是US#表示回滚段编号):

很明显,我们可以看到,本质上Oracle是在对回滚段_SYSSMU1$ 进行update时出现问题了。
现在我们来回答第2个问题,Oracle为什么会报错呢?  我们再来看下这个ORA-00600错误:
ORA-00600: 内部错误代码, 参数: [4193], [65], [71], [], [], [], [], []

根据文档的解释,这个错误的意思是redo record的seq和undo record的seq不匹配导致。

那么这里的65和71到底是什么意思呢 ? 这个错误的格式是这样: ORA-600 [4193] [a] [b]

a 即 65,表示undo record seq
b 即 71,表示redo record seq.

那么Oracle这里为什么会得出一个不一致的结果呢?很明显,65 是不等于71的。

从网友提供的Trace文件,我们可以看到这样一段信息:

很明显,这是redo相关信息,这里的seq 为0x0047,转换之后即为71. 原来,这就是ora-00600错误的b 值的来源.

那么ora-00600错误的a值,65又是哪儿来的呢 ? 从前面的UBA信息,我们可以知道,这个事务对应的undo block是:0x0040019f

那么我们来看下这个undo block中的内容是什么样的? 搜索block地址,我们发现这是一个system的block,显然是system 回滚段
的block,如下:

我们根据前面的UBA:uba: 0x0040019f.0047.07  定位到该事务的信息应该是undo block的第7个record中,当我们定位到第7个record时,
我们可以看到,这里的seq其实却是41,转换为10进制就是65. 这也就是ORA-00600这个错误的由来.
最后我们来回答第3个问题,那么就如果强制屏蔽回滚段是否有影响呢?很明显,网友这里的对象是obj 15,这是一个核心对象。
强制的屏蔽回滚段肯定是不妥的。其实处理方法有很多种,针对类似的问题我已经在道森Oracle培训的特殊恢复课程中讲过多次了。

备注:这里只是简单分析一下问题,如果你遇到类似的问题,请联系我!

 

Leave a Reply

You must be logged in to post a comment.