今天ML的群中女神和travel在纠结一个恢复的问题，11.2.0.3版本，非归档，大概是rm掉current的log，然后重建
controlfille后恢复导致一系列问题，并最终出现ora-600 2662错误，虽然这个错误很常见，但是你发现推进scn
也是无法open，感觉有点怪，远程了女神的电脑，操作不便，最后将文件压缩传过来，我在自己的vmware进行了恢复。

由于环境的差异，所以解压后我先进行rename file操作，如下：

此时,进行recover，会报错ORA-16433，如下：

关于该错误，通过oerr命令可以大概了解一下其含义，如下：

其实，通常来讲，只要上述几个值一样，那么我们的db应该都是可以直接open打开的，然而，这里却不行，read only都不行，我试过。
然后下面就开始我的恢复工作。

第一次尝试恢复：

因为本身是非归档，所以这个不完全恢复的步骤无非是为了后面可以进行open resetlog。然后停库，加入隐含参数进行open：

此时alert log对应的错误如下：

甚至手工执行如下操作都无法open数据库，如下：

++++++++ controlfile dump 片段

可以看到实际上current redo的LWN RBA是对的，为1.2.10，是小于on disk rba (0x1.3.0)的。那么这里为什么会出现这个情况？
猜测可能是写紊乱了。到这里也就比较明白了，仍然是conrolfile有问题。

既然如此，那么我直接将controlfile文件rm掉，然后再次重建。如下：

此时停库，然后在pfile中加入隐含参数：
*._allow_resetlogs_corruption=TRUE
*._allow_error_simulation=TRUE

接着再次进行mount，并进行scn 推进：

这里说明一下是我的alert log里面还出现了数据字典不一致的问题，因为毕竟是强制open的，如下：

seg/obj: 0x12 这是obj$对象，属于bootstrap$核心对象，涉及到这类的对象处理相对麻烦，针对这类情况，数据库open后都建议
把数据导出，然后重建库，我这里就不在继续描述这个ora-600错误了，我博客也有类似的例子。

最后来个小节：

1. oracle通过系统checkpoint scn，datafile checkpoint scn,start scn三者之间的比较来判断数据文件是否需要进行介质恢复.
2. 在redo 线程打开的情况下，即数据库open的情况下，stop scn会被设置为无穷大，当正常关闭时，stop scn等于datafile scn.
这里需要注意的是，stop scn是存放在controlfile中的，网上部分资料说是存在datafile header中，这个说法是错误的。
3. oracle在open之前是先判断是否进行介质恢复，然后再是判断是否进行instance recovery。
4. 关于4种scn的关系如下：

system checkpoint scn — 存放在controlfile中
datafile checkpoint scn –存放在controlfile中
start scn —存放在datafile header中
stop scn —存放在controlfile中

system scn，datafile checkpoint scn，start scn，这3种scn用于判断数据文件是否需要进行介质恢复。这3个相等这不需要介质恢复。
如何这4个都相等，那么就不需要进行实例恢复。stop scn是用于判断是否进行实例恢复的。

5. 如果stop scn比其他的几个scn要大，那么就需要进行instance recover，需要进行扫描redo，实例恢复的起点是low cache rba，终点
是redo log的最末端。