1.2启动数据库到 mount 状态
实例启动到 nomount 状态以后， Oracle 就可以从参数文件中获得控制文件的位置信息， 然后找到控制文件， 并且根据控制文件中记录的数据文件位置进行数据文件的存在性判断。
1.2.1 控制文件的定位
在 Oracle 10g 之前，通常 Oracle 缺省的会创建 3 个控制文件，这三个控制文件的内容完全一致，是 Oracle 为了安全而采用的镜像手段，在生产环境中，通常我们应该将控制文件存放在不同的物理硬盘上，避免因为介质故障而同时损坏三个控制文件。
控制文件信息在参数文件中记录类似如下所示：
从 Oracle 10g 开始，如果设置了闪回恢复区（ Flashback Recovery Area，通常闪回区和数据区位于不同硬盘存储），则 Oracle 缺省的就会将控制文件分布到不同的磁盘组，至此 Oracle才算完成了控制文件的真正镜像安全保护，以下是 Oracle 10g 中的一个输出示范：
在 nomount 状态， 可以查询 vparameter 视图，获得控制文件信息，这部分信息来自启动的参数文件；当数据库 mount 之后， 可以查询 vcontrolfile 视图获得关于控制文件的信息，此时，这部分信息来自控制文件：
在 mount 数据库的过程中， Oracle 需要找到控制文件， 锁定控制文件。 如果控制文件全部
丢失此时就会报出如下错误：
这时候告警日志文件中通常会记录更为详细的信息：
因为 Oracle 的三个(缺省的)控制文件内容完全相同，如果只是损失了其中 1~2 个，可以复第 1 章 数据库的启动和关闭制完好的控制文件，更改为相应的名称，就可以启动数据库；如果丢失了所有的控制文件，那么就需要恢复或重建控制文件来打开数据库。
1.2.2 数据文件的存在性判断
在启动了实例之后，实际上数据库的后台进程已经运行，那么当进一步的 Mount 数据库
之后，后台进程就可以根据控制文件中记录的数据文件信息来验证数据文件是否存在，如果数
据文件不存在，则后台进程将在告警日志文件中记录文件缺失信息，并且在动态视图中记录这
些信息。
对以下数据库进行一个简单测试：
通过以下步骤，移除一个测试文件：
此时检查告警日志文件，则可以发现数据文件的缺失信息：
此时查询数据的动态视图 v$recover_file 可以发现数据库记录了 FILE NOT FOUND 的错误信息：
不过在较新版本（比如 Oracle 11gR2）中， 启动数据库到 Mount 状态时， 在告警日志文件中不再提示数据文件缺失信息。
1.2.3控制文件的 HeartBeat
在正常 Mount 数据库的过程中，数据库的警报日志文件仅记录如下信息：
在这一步骤中，数据库需要计算 Mount id 并将其记录在控制文件中，然后开始启动心跳（ heartbeat），每 3 秒更新一次控制文件。 可以用以下命令间隔 3 秒转储 2 次控制文件信息：
alter session set events ‘immediate trace name CONTROLF level 8’ ;
在 Linux 上用 diff 命令比较 2 个文件可以发现，控制文件在 Mount 状态下发生改变的只有这个 Heartbeat:
Heartbeat 表明实例已经被特定例程所 Mount， 这个属性主要用于 OPS/RAC 环境。但是第 1 章 数据库的启动和关闭Heartbeat 在单实例环境中同样存在。可以从一个内部表（需要以 SYS 用户登录）中查询到当前的 Heartbeat 值（ XKCCCP 的含义为[K]ernel [C]ache [C]ontrolfile management [C]heckpoint[P]rogress） :
SELECT CPHBT from XKCCCP;
从 Oracle 9i 开始， Oracle 在数据库内部通过等待事件 control file heartbeat 来记录这个事件的相关等待；在 Oracle 10g 中，如果使用自动存储管理技术（ ASM - Automatic StorageManagement）， 那么还会增加一个 ASM 实例的心跳事件；以下输出来自 Oracle 10g：
了解了启动的各个步骤，我们也就可以在发生问题的时候，快速定位，准确判断，从而快速解决问题。
