这是一个网友的问题，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培训的特殊恢复课程中讲过多次了。

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