今天的技术问答是刘晨兄的一个问题，提问来自于我新书中的一个实验，刘晨兄非常认真，对我书中的很多细节都进行了测试。
看到这个错误，如果出现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.
其实还有更多的因素影响，目前先分析到这里，这也让我对这个问题有了更新的认识，当然我在书中提到的那个场景是完全恢复，在备份的基础上随便玩都可以，只是表现形式会有差别。也是书中问题所要表达的本质。
dangran 这个问题我们来看看怎么