oracle 用户管理的完全恢复机制的问题！

Question

我在oracle视频上看到如下介绍：
当数据文件出现介质失败时，使用操作系统即令转储数据文件，并使用sql恢复命令执行重做日志和归档日志，
最终将数据文件恢复到失败点之前的状态。
分为以下2个步骤：
1，当发生介质故障后，利用备份文件来修复损坏或丢失的数据文件。
2，修复数据文件后，因为被修复的数据文件与其他数据文件相比要”旧“
  ，所以这时，数据库中的数据文件并不同步（文件头部信息中的检查点号SCN不同）。
  由于数据文件之间不一致，数据库仍然无法打开，这时候就需要通过sql命令，使用归档日志对数据库进行恢复。
  
恢复命令
1 recover database; 
  用于恢复数据库的多个数据文件，只在mount状态下使用
2 recover tablespace; 
  用于恢复一个或多个表空间的所有数据文件，只在open状态下运行
3 recover datafile 4
  用于恢复一个或者多个数据文件，该命令可以在mount或者open状态下运行
  或者再recover命令中指定归档日志位置，如下：
  recover from 'f:\oracle11g\orcl0025_069817.001' datafile 4; 
  可以可以在recover命令当中指定自动应用归档日志，如下：
  recover automatic datafile 4;

问下，在恢复命令中，为什么recover database、recover tablespace、recover datafile 4中，都提到了恢复数据文件。
但是数据库状态却是mount以及open状态下都可以进行恢复。
这里我有个疑问，oracle启动时候，不是在nomount状态下，读取的是初始化参数文件，在mount状态下读取的是控制文件，只有在open状态下才读取加载数据文件吗？那为什么这里描述中在mount状态下也可以恢复数据文件呢？

Answer 1

我是这样的看法：1、其实一般情况下数据文件坏掉都是在MOUNT状态才可以恢复，如你所说MOUNT状态已经初始化控制文件，此时控制文件已经知道有哪些数据文件以及一些控制信息，它可以平衡数据文件和日志文件的关系；而如果我们需要启动到OPEN状态直接启动时启动不起来的，因为数据文件坏掉了，需要将这个坏掉的数据文件职位OFFLINE状态才可以将实例状态修改为OPEN，在这个状态下恢复数据文件后，然后。2、也就是本身就应该在MOUNT内部恢复的，因为MOUNT内部已经有足够的信息去进行物理恢复，因为此时虽然是联机恢复，但是对于这个坏掉的数据文件的读取并非联机的，也就是可以说即使是OPEN状态下，这个数据文件也是没有被加载的，而MOUNT相当于非联机的状态，它恢复的依据是有一个控制者control file。

Answer 2

正如xieyuooo所说的，open已经是打开datafile了，而对于不一致的datafile是无法online的，也就是说这个datafile的scn还停留在之前，这时候需要进行recover来apply 相关的log,以及在最后一步online时update datafile header, 而mount状态下实际下控制文件已经记录了datafile 的相关信息，包括有检查点，scn，redo log的高低scn, 以及数据文件头控制文件头的信息，这个时候只需要比较这些信息是否满足要求。

Answer 3

可以这样理解吗？ 数据文件离线offline状态下，只能在mount状态下恢复，而在线的只能在open状态下恢复恩？

Answer 4

不是的， 所有都可以在mount下恢复。 

Answer 5

你自己也说了，在open状态下是读取加载数据文件，那显然不能在OPEN状态下恢复啊，你数据文件都是未恢复的错误数据，怎么能允许进入OPEN状态下呢，所以自然要在mount状态下恢复数据文件，恢复好后才能读取正确的数据文件并将状态置入OPEN，同理，如果控制文件损坏，那自然不能在mount状态下恢复，因为你的控制文件都是未恢复的错误数据，怎么能允许进入mount状态下呢，所以自然要在unmount状态下恢复控制文件，恢复好后才能读取正确的控制文件并将状态置为mount

Answer 6

写错个地方   所以自然要在unmount状态下恢复控制文件，恢复好后才能读取正确的控制文件并将状态置为mount   应该是  所以自然要在nomount状态下