我明明 immediate 关库的，怎么就打不开了？！

五一放假期间，某客户的数据库出现故障，据说对方找了一些工程师折腾了一天，都无法将数据库open，其中参考了网络上的很多文章，也使用了一系列隐含参数，均无法将数据库打开。这里我简单的与大家分享一下这个case。

首先我介绍一下整个case的背景，客户在4月30号凌晨通过shutdown immediate停库维护后，启动数据库无法报错，此时发现数据库无法open，期间尝试了各种数据库手段，均失败告终。

我们先来看看相关日志，如下是数据库停库的日志：

我们可以看出，这个数据库确实是以shutdown immediate的方式停止的。客户第一次尝试启动时，发现报错ORA-00600 [2663],如下：

这是一个非常常见的错误,这个错误通常是是跟数据块有关系。我们知道，根据经验，一般来讲，如果current scn (这里是scn base)与dependent scn(scn base)非常接近（且scn wrap都一致或者为0)的情况下，说明scn的差异非常小，通过多次重启数据库的手段，基本上可以绕过这个错误。

果然，通过看客户提供的alert log发现多次重启后，alert log的报错日志变了ORA-00600 [4194]错误，如下：

这是一个看似非常简单的错误，大致意思是说Oracle 在进行事务恢复时发现redo和undo的信息有所出入，因此抛出这个错误。

这里我贴出Oracle MOS的标准解释供大家参考：Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter (文档 ID 281429.1)

上述文档中提到，这个错误其实就是指恢复时发现undo block对应的record 编号与redo block 对应的undo record 编号不一致。通常情况下来讲，都是由于回滚段损坏导致的问题。 这里我们先不去进行alert log的详细分析展开了，以自己的实际操作过程来进行展开分析说明。如下是我的简单恢复过程。

首先我尝试进行正常恢复，并打开数据库：

我们可以看到操作报错，并没有打开数据库。此时查看数据库alert 告警日志，发现正是前面提到的ORA-00600 [4194]错误：

这个ora-00600 错误与前面提到的完全一致。根据我们常规处理这个错误的套路，基本上就是使用undo_management=’manual’ 来尝试绕过，经过测试发现不好使。

进一步查看对应的trace 文件，发现oracle提示说某个块存在异常：

上述的错误其实也很容易解释，简单的讲就是redo应用时出现了异常，而且oracle 明确提升file 1 block 131 这个undo block有问题. 上述的内容是redo block的dump；那么我们来看看对应的undo block 中的前镜像是什么：

我们可以看到完全不匹配，同时我们通过脚本将上述内容进行转换，可以发现是其实是回滚段名称：

其次结合我们前面解释ora-00600  [4194]错误来看，这里undo block 对应的record number是0×20，而redo block中记录的record number是0×2. 这确实是不匹配的。

那么怎么解决这个问题呢？ 能不能通过屏蔽回滚段的方式来解决呢？

我尝试在open之前设置10046 trace，来观察了一下得到了如下结果：

可以看到oracle在执行update  undo$时报错，其中更新的是_SYSSMU1_3724004606$ 这个回滚段。而且我们也可以看到，wait# 中记录的正好是前面报错的file# 1 block 131. 那么通过_corrupted_rollback_segments=(_SYSSMU1_3724004606$)

这种方式是否可以解决这个问题呢？

很遗憾，这里我测试也不行。甚至通过bbed 修改undo$的kdbr记录，将_SYSSMU1 的状态修改为offline，也无法绕过这个ora-00600 4194错误。简直堪称最顽固的ORA-00600 [4194]。

我又检查了一下前面的trace文件，发现所针对这个回滚段头的dump记录，可以确认其中并没有什么活动事务。然后再仔细看我们所遇到的这个ora-00600 [4194]错误，我感觉有点怪异。为什么说怪异呢？

如果说根据Oracle mos的解释文档来看，这里是是没有[a],[b] 值的，因为均为0.

最后我们想到通过修改system 回滚段头来绕过这个错误，如下是操作过程：

注意，这里我们仅仅需要修改ktuxcnfb和ktuxcfbp[1] 即可。其中将ktuxcnfb修改为0，ktuxcfbp[1]中的uba修改为0.

然后再尝试打开数据库，发现顺利打开了数据库，如下：

接着检查了数据库alert log，也没有发现任何的ora-错误。看到最后，或许大家会觉得很奇怪，为什么会出现这样的故障呢 ？  这里我也跟大家一样困惑。

这库是通过shutdown immediate方式正常停止的。我们都知道，这种方式停库之后，整个Oracle数据库的文件都是处于一致的状态，重新启动数据库实例后按理说是不需要再进行实例恢复的。

那么为什么这里又出现了这种情况呢？

针对这个问题，我认为有2种可能性：

1、shutdown immediate之后，数据库写入到操作系统cache，还未完全写入到disk上时，此时数据库主机被强行重启；由于操作系统cache丢失，导致数据库出现了不一致的情况(本文环境是Linux文件系统)。

2、其他程序或软件破坏了Oracle数据库文件的一致性（实际上，经过了解该环境部署了Rose HA软件；而且客户在操作时，据说并没有停止rose ha软件）。

由于客户操作的时间点是凌晨2点，几乎是0业务场景，因此我认为第一种可能性几乎为0；第2种可能性更大。

当然由于我们不了解Rose HA软件的工作机制，这里不便评论。只能说这是一个非常奇怪的case了。值得欣慰的是，通过我们的努力，很快就帮助客户恢复了系统访问，并且无数据丢失。

本文出自数据和云公众号，原文链接