今天的技术问答是刘晨兄的一个问题，提问来自于我新书中的一个实验，刘晨兄非常认真，对我书中的很多细节都进行了测试。

看到这个错误，如果出现end-of-file这类的错误信息，基本可以断定数据库实例是宕了。

找到刘晨兄提到的页码标示，原来和我书中的测试结果有一些差别。

我书中的结果类似这样的形式：

错误代码也完全不同，这个问题该怎么解释呢，这个应该是一个很细节的问题。

首先网络上关于这个错误有很多种说法，很多我不认同。

我们先来复现一下问题，找了一套11.2.0.3的环境测试了一下。

先初始化数据

然后复现问题，错误和刘晨兄的描述是一致的。

这个时候我迅速去查看最开始描述问题的博客和书稿记录。发现当时没有详细记录当时的测试版本，印象中应该是10g的环境。

当然碰到这个问题，先来快速修复一下。

好了，问题能够解决了，我们就来分析这个问题。网络上有一些说法，我带着疑问进行了复现，发现应该不是描述的那样。

网络上的观点1：非归档模式的影响。但是经过我的测试，发现不存在所说的那种情况。

网络观点2：存在多个数据文件，我创建了表空间，包含多个数据文件，也不存在这种问题。

后面还有一些说法，我就不一一列举了，不能猜。

对于这个问题，TOM给出了一些解释，是他很早的一个帖子中的回答。

commit;

还有一位朋友的复现：

我在他们的基础上也做了一些复现，但是还是发现有一些奇怪之处，有些复现不了。问题的原因是什么呢。

其中一个原因是在11.2.0.2后引入了一个隐含参数_datafile_write_errors_crash_instance，在我的新书第125~126页也有提及。在之前版本中，归档模式下发生文件写入错误时，Oracle会自动将数据文件离线；从11.2.0.2开始数据库实例会crash而不是离线数据文件。

我们来看看这个问题怎么来试一试。

默认是TRUE,我们改为false

SQL> alter system set "_datafile_write_errors_crash_instance"=false;

System altered.

其实还有更多的因素影响，目前先分析到这里，这也让我对这个问题有了更新的认识，当然我在书中提到的那个场景是完全恢复，在备份的基础上随便玩都可以，只是表现形式会有差别。也是书中问题所要表达的本质。