一、Oracle 数据库启动原理

Oracle 数据库由两个核心部分组成：

• Oracle Instance（实例）：由 SGA（系统全局区）和后台进程组成。
• Oracle Database（数据库）：由数据文件、控制文件和联机重做日志文件等物理文件组成。

Oracle 启动的本质是：

先启动实例，再通过控制文件关联数据库，最后打开数据文件和联机重做日志文件，使数据库能够正常提供服务。

完整启动过程：

SHUTDOWN（数据库关闭）
    |
    v
获取 ORACLE_SID
    |
    v
查找初始化参数文件 SPFILE / PFILE
    |
    v
读取初始化参数
    |
    v
分配 SGA 内存
    |
    v
启动 Oracle 后台进程
    |
    v
NOMOUNT（实例启动）
    |
    v
读取 CONTROL_FILES 参数
    |
    v
定位并打开控制文件
    |
    v
MOUNT（数据库装载）
    |
    v
读取数据库物理结构信息
    |
    v
定位数据文件和联机重做日志文件
    |
    v
检查数据库文件状态和 SCN
    |
    +------ 文件一致 ------+
    |                      |
    |                      v
    |                OPEN（数据库打开）
    |
    +------ 需要实例恢复 ------+
                           |
                           v
                    前滚 Roll Forward
                           |
                           v
                    数据库可以打开
                           |
                           v
                    事务回滚 Roll Back
                    （可能继续在后台进行）

注意：上图为逻辑流程。Oracle 的事务恢复不一定全部完成后才允许普通用户访问数据库。实例恢复的缓存恢复阶段完成后，数据库可以打开，部分未提交事务的回滚可以在后台继续进行。

二、第一阶段：NOMOUNT（启动实例）

2.1 NOMOUNT 阶段的核心作用

NOMOUNT 是 Oracle 数据库启动的第一个阶段。

此时：

• Oracle 实例已经启动。
• SGA 内存已经分配。
• Oracle 核心后台进程已经启动。
• 尚未打开控制文件。
• 尚未关联数据库。
• 尚未打开数据文件和联机重做日志文件。

NOMOUNT = 内存 + 后台进程。

2.2 ORACLE_SID 的作用

SID（System Identifier）用于在操作系统层面标识 Oracle 实例。

例如：

export ORACLE_SID=orcl

Oracle 根据当前实例标识和启动方式查找初始化参数文件。

在 Oracle Linux 上，默认查找路径通常位于：

$ORACLE_HOME/dbs/

典型的参数文件包括：

spfileorcl.ora
spfile.ora
initorcl.ora

默认搜索顺序通常为：

spfile<SID>.ora
      |
      v
spfile.ora
      |
      v
init<SID>.ora

如果使用：

STARTUP PFILE='/path/init.ora';

则会按指定路径读取参数文件。

初始化参数文件包含：

• SGA 内存配置
• PGA 内存相关配置
• CONTROL_FILES 控制文件路径
• DB_NAME 数据库名称
• PROCESSES 最大进程数量
• UNDO_TABLESPACE 撤销表空间
• 其他数据库初始化参数

2.3 分配内存并启动后台进程

Oracle 读取初始化参数后，开始分配 SGA 内存并启动后台进程。

SGA 的主要组成：

注意：PGA 是进程私有内存，不属于 SGA。

主要后台进程：

当实例内存和必要后台进程启动完成后，数据库进入 NOMOUNT 状态。

2.4 NOMOUNT 阶段可以执行的操作

常见操作：

STARTUP NOMOUNT;

可以用于：

• CREATE DATABASE 创建数据库。
• CREATE CONTROLFILE 重建控制文件。
• 部分初始化参数维护。
• 检查实例相关参数。

查看实例状态：

SELECT instance_name, status
FROM v$instance;

预期：

INSTANCE_NAME    STATUS
-------------    -------
orcl             STARTED

2.5 NOMOUNT 启动失败分析

常见原因：

原因一：参数文件不存在或无法读取

可能出现：

ORA-01078
LRM-00109

检查：

echo $ORACLE_SID
echo $ORACLE_HOME
ls -l $ORACLE_HOME/dbs/

原因二：SGA 内存不足或共享内存配置异常

可能出现：

ORA-00845
ORA-27102

检查：

free -h
df -h /dev/shm

原因三：初始化参数配置错误

例如：

ORA-00821
ORA-01078

处理方法：

• 检查初始化参数。
• 查看 Alert Log。
• 修正参数配置。
• 重新执行 STARTUP。

NOMOUNT 失败的排查重点：SID、参数文件、内存、操作系统资源和后台进程。

三、第二阶段：MOUNT（装载数据库）

3.1 MOUNT 阶段的核心作用

Oracle 完成 NOMOUNT 后，开始读取控制文件。

控制文件路径通常由初始化参数决定：

SHOW PARAMETER control_files;

例如：

/u01/app/oracle/oradata/ORCL/control01.ctl
/u01/app/oracle/fast_recovery_area/ORCL/control02.ctl

Oracle 打开控制文件，将实例与数据库关联。

此时：

• 实例已经启动。
• 控制文件已经打开。
• 数据库已经装载。
• 数据文件尚未作为正常打开的数据库供用户访问。
• 数据库仍不能提供普通业务读写服务。

MOUNT = 实例 + 控制文件 + 数据库关联。

3.2 控制文件记录哪些信息？

控制文件是 Oracle 数据库非常重要的物理元数据文件。

主要记录：

1. 数据库名称及标识。
2. 数据文件名称、编号和路径。
3. 联机重做日志组及成员信息。
4. 表空间相关信息。
5. 检查点及 SCN 信息。
6. 日志序列和归档相关信息。
7. 数据库备份与恢复所需的部分元数据。

Oracle 根据控制文件中的信息，进一步定位数据库的数据文件和联机重做日志文件。

3.3 MOUNT 阶段可以执行的操作

STARTUP MOUNT;

常见操作：

-- 查看数据库状态
SELECT name, open_mode
FROM v$database;

-- 开启归档模式（需满足相应前置条件）
ALTER DATABASE ARCHIVELOG;

-- 执行需要在 MOUNT 状态下进行的数据库恢复
RECOVER DATABASE;

-- 打开数据库
ALTER DATABASE OPEN;

3.4 MOUNT 阶段启动失败分析

原因一：控制文件不存在

可能出现：

ORA-00205
ORA-00210

原因二：控制文件无法访问

可能原因：

• 文件权限错误。
• 文件路径错误。
• 磁盘未挂载。
• 文件丢失。
• 文件损坏。

检查：

SHOW PARAMETER control_files;

操作系统检查：

ls -l /u01/app/oracle/oradata/ORCL/
df -h

原因三：控制文件与数据库身份信息不匹配

例如数据库名称、控制文件或恢复状态不一致。

应检查 Alert Log 和对应 ORA 错误，不要直接删除或重建控制文件。

MOUNT 失败的排查重点：CONTROL_FILES 参数、控制文件路径、权限、完整性和数据库身份信息。

四、第三阶段：OPEN（打开数据库）

4.1 OPEN 阶段的核心作用

数据库进入 MOUNT 状态后，Oracle 根据控制文件中的记录定位数据库物理文件。

主要包括：

控制文件
   |
   +---- 数据文件 system01.dbf
   |
   +---- 数据文件 sysaux01.dbf
   |
   +---- 数据文件 undotbs01.dbf
   |
   +---- 数据文件 users01.dbf
   |
   +---- 联机重做日志 redo01.log
   |
   +---- 联机重做日志 redo02.log
   |
   +---- 联机重做日志 redo03.log

这些路径只是示例，实际位置以控制文件和数据库视图为准。

Oracle 需要检查文件是否可访问，以及数据库是否满足打开条件。

4.2 OPEN 阶段的 SCN 检查

SCN（System Change Number）是 Oracle 用来标识数据库逻辑变化顺序的重要编号。

数据库打开时，需要结合：

• 控制文件中的检查点信息。
• 数据文件头中的检查点信息。
• 数据文件状态和恢复标记。
• 联机重做日志的可用性。
• 数据库上一次关闭状态。

判断数据库是否需要恢复。

注意：不能简单理解为“所有数据文件头 SCN 必须与控制文件 SCN 完全相等”。

因为不同数据文件可能具有不同的检查点状态，Oracle 会根据恢复规则判断文件是否一致、是否需要介质恢复或实例恢复。

4.3 OPEN 阶段启动失败分析

情况一：数据文件不存在

可能出现：

ORA-01157
ORA-01110

检查：

SELECT file#, name
FROM v$datafile;

情况二：数据文件需要介质恢复

可能出现：

ORA-01113
ORA-01110

此时需要根据数据库恢复状态、备份和归档日志进行处理。

情况三：联机重做日志文件异常

可能出现：

ORA-00313
ORA-00312

检查：

SELECT group#, member
FROM v$logfile;

情况四：数据库需要实例恢复

如果数据库上一次异常关闭，Oracle 通常会在 OPEN 过程中自动进行实例恢复。

如果恢复所需文件完整且可访问，实例恢复通常不需要 DBA 手动干预。

OPEN 失败的排查重点：数据文件、联机重做日志、SCN、文件状态和恢复需求。

五、Checkpoint（检查点）机制

5.1 什么是检查点？

Checkpoint 是 Oracle 数据库控制恢复工作量和维护数据库文件一致性的重要机制。

它涉及：

• 将符合检查点要求的脏数据块写入数据文件。
• 更新控制文件中的检查点信息。
• 在相应检查点类型下更新数据文件头中的检查点信息。
• 推进实例恢复所需的起始位置。

检查点不是简单地清空 Buffer Cache。

检查点写出脏块后，相关数据块仍然可以保留在缓存中供后续访问。

5.2 什么是脏块？

当 Oracle 修改数据时：

读取数据块
    |
    v
加载到 Database Buffer Cache
    |
    v
执行 UPDATE / INSERT / DELETE
    |
    v
修改缓存中的数据块
    |
    v
形成 Dirty Buffer（脏块）
    |
    v
DBWn 在适当时机写入数据文件

脏块是指缓存中的数据块发生了修改，且相关修改尚未全部写入数据文件。

5.3 Checkpoint 的主要目的

1. 减少实例故障后的恢复工作量。
2. 定期推动脏数据块写入磁盘。
3. 支持数据库的一致关闭。
4. 管理实例恢复需要扫描的 Redo 范围。
5. 协调数据库文件的检查点状态。

5.4 Checkpoint 与 SCN 的关系

Oracle 使用检查点 SCN 和相关恢复元数据，确定恢复需要从哪里开始。

可以理解为：

Redo Log：

旧日志记录                            新日志记录
    |                                     |
    v                                     v
----+----------+--------------------------+
               ^
               |
          Checkpoint 位置
               |
               v
       实例恢复需要从适当的
       Redo 位置开始处理

增量检查点的位置与缓存中尚未写出的较早修改有关，但不能把所有检查点类型都理解成完全相同的机制。

检查点相关信息保存在控制文件中；某些检查点也会更新数据文件头。

5.5 CKPT 和 DBWn 的区别

CKPT 通常不负责实际写入数据块，真正执行数据块写盘的是 DBWn。

5.6 Oracle 常见检查点类型

1. 线程检查点（Thread Checkpoint）

针对某个 Redo Thread 推进检查点。

常见触发场景包括：

• 一致关闭数据库。
• 执行 ALTER SYSTEM CHECKPOINT。
• 联机重做日志切换过程中产生的相关检查点活动。

注意：日志切换不意味着切换瞬间必须将所有脏块全部写完。

2. 表空间和数据文件检查点

针对指定表空间或数据文件执行检查点相关操作。

例如：

• 表空间正常脱机。
• 表空间切换为只读。
• 某些备份或文件维护操作。

3. 增量检查点（Incremental Checkpoint）

Oracle 通过持续写出脏块，逐步推进实例恢复起点。

作用：

• 避免每次检查点都集中写出大量数据块。
• 平滑数据库 I/O 压力。
• 控制实例恢复时间。

增量检查点推进时，CKPT 可以更新控制文件中的相关检查点位置，而不必每次都更新所有数据文件头。

六、实例恢复（Instance Recovery）

6.1 什么情况下需要实例恢复？

实例恢复通常发生在数据库上一次未正常关闭时。

例如：

SHUTDOWN ABORT;

或者：

• 操作系统突然宕机。
• 服务器断电。
• Oracle 实例异常终止。
• 核心后台进程异常导致实例终止。

此时，数据文件中可能存在：

• 已提交但尚未写盘的修改。
• 未提交但已经写盘的修改。

因此数据库需要利用 Redo 和 Undo 恢复一致性。

6.2 实例恢复的两个主要阶段

第一阶段：前滚（Roll Forward / Cache Recovery）

Oracle 根据检查点及恢复信息定位所需的 Redo。

然后重新应用必要的重做记录。

异常关闭
    |
    v
读取控制文件中的恢复信息
    |
    v
确定恢复起点
    |
    v
读取联机重做日志
    |
    v
应用必要的 Redo
    |
    v
恢复数据块修改

前滚会重建已提交和未提交事务相关的必要修改。

所以前滚完成后，数据库块中仍可能存在未提交事务造成的变化。

第二阶段：回滚（Roll Back / Transaction Recovery）

Oracle 利用 Undo 信息处理未提交事务。

前滚完成
    |
    v
识别需要恢复的未提交事务
    |
    v
读取 Undo 信息
    |
    v
撤销未提交事务的修改
    |
    v
完成事务恢复

回滚可以由后台恢复机制处理，部分回滚也可能在访问相关数据时按需进行。

6.3 前滚和回滚示例

假设数据库执行：

-- 事务 A
UPDATE accounts
SET balance = balance + 100
WHERE id = 1;

COMMIT;

随后执行：

-- 事务 B
UPDATE accounts
SET balance = balance - 200
WHERE id = 2;

-- 没有 COMMIT

这时服务器突然断电。

重新启动时：

服务器断电
    |
    v
Oracle STARTUP
    |
    v
检查数据库恢复状态
    |
    v
前滚：
重做必要的事务 A 和事务 B 修改
    |
    v
回滚：
撤销事务 B 未提交的修改
    |
    v
最终保留事务 A 的提交结果

最终结果：

6.4 Redo 和 Undo 的区别

需要特别注意：

Redo 不只是记录已提交事务，未提交事务产生的修改也会生成 Redo。

Undo 本身也会产生 Redo，以支持故障后的恢复。

七、Oracle 启动命令

-- 启动到 NOMOUNT
STARTUP NOMOUNT;

-- 从 NOMOUNT 进入 MOUNT
ALTER DATABASE MOUNT;

-- 从 MOUNT 进入 OPEN
ALTER DATABASE OPEN;

也可以：

-- 直接启动到 MOUNT
STARTUP MOUNT;

-- 完整启动数据库
STARTUP;

查看状态：

SELECT instance_name, status
FROM v$instance;

SELECT name, open_mode
FROM v$database;

典型实例状态：

八、Oracle 启动失败排查总结

查看 Alert Log：

SELECT name, value
FROM v$diag_info
WHERE name = 'Diag Trace';

Oracle 19c 常见的 Alert Log 文本路径形式：

$ORACLE_BASE/diag/rdbms/<db_unique_name>/<SID>/trace/alert_<SID>.log

也可以使用 ADRCI 查看数据库诊断信息。

九、核心总结

Oracle 数据库启动过程可以记为：

SID → 参数文件 → SGA + 后台进程 → NOMOUNT → 控制文件 → MOUNT → 数据文件 + Redo → 恢复检查 → OPEN。

三个阶段的核心区别：

• NOMOUNT：实例启动，内存和后台进程就绪。
• MOUNT：打开控制文件，实例与数据库关联。
• OPEN：打开数据库文件，完成必要恢复，允许正常业务访问。

实例恢复的核心：

Checkpoint 确定恢复起点，Redo 负责前滚，Undo 负责回滚。