Oracle入门笔记 ——启动

参考教材《深入浅出Oracle》

兴趣 + 勤奋 + 坚持 + 方法 ≈ 成功

DBA生存之四大守则

1.备份重于一切；

2.三思而后行；

3.rm是危险的；

4.你来制定规范；

第一章：数据库的启动和关闭：

Oracle Server主要由两部分组成：Instance 和 Database。

Instance是指一组后台进程/线程和一块共享内存区域，而Database是指存储在磁盘上的一组物理文件。

1.1 数据库的启动：

三个启动步骤：

1.启动数据库倒 nomount 状态；

2.启动数据库倒 mount 状态；

3.启动数据库到 open状态；

1.1.1 启动数据库到nomount状态

在启动的第一步骤，Oracle首先寻找参数文件(pfile/spfile),然后根据参数文件中的3设置，创建实例，分配内存，启动后台进程。

只要拥有了一个参数文件，就可以凭之启动实例(Instance),这一步骤并不需要任何控制文件或数据文件的参与。

在创建数据库时，如果在这一步骤出现问题，那么通常可能是系统配置（内核参数等）存在问题，用户需要检查是否分配了足够的系统资源等。

这里，Oracle 根据参数文件内容，创建了instance，分配了 相应的内存区域， 启动了相应的后台进程。

此时，观察报警日志文件， alert_<sid>.log，可以看到这一阶段的启动过程，读取 参数文件，应用参数启动实例，所有参数文件定义的非缺省参数都会记录在警报日志文件中。

然后后台进程一次启动：

1.1.2 启动数据库到 mount 状态

启动到nomount状态以后，Oracle就可以从参数文件中获得控制文件的位置信息，这一部分信息在参数文件中的记录类似如下所示：Oracle会缺省创建3个控制文件，这三个控制文件

的内容完全一致，是Oracle为安全而采用的镜像手段，在生产环境中，通常应该将3个控制文件放在不同的物理硬盘上，避免因介质故障而同时损坏3个控制文件。

在nomount状态，可以查询 v$parameter 视图，获得控制文件信息，这部分信息来自启动的参数文件；当数据库mount之后，可以查询 v$controllerfile试图获得关于控制文件的信息，

此时，这部分信息来自控制文件：

在mount数据库的过程中，Oracle需要找到控制文件并锁定控制文件。如果控制文件全部丢失就会报错：

因为Oracle的三个缺省控制文件内容完全相同，如果只是损失了其中1~2个，可以复制完好的控制文件，更改为相应的名称，就可以启动数据库；

如果丢失了所有的控制文件，那么就需要恢复或者重建控制文件来打开数据库。

正常mount数据库的过程中， 数据库的警报日志文件仅记录如下信息：

在这一步骤中，数据库需要计算Mount id 并将其记录在文件中，然后开始启动Heartbeat（心跳），每3秒更新一次控制文件。用命令间隔3秒转储2次控制文件信息：

 HeartBeat表明实例已经被特定例程所Mount，这个属性主要用于OPS/RAC环境。

 但是HearBeat在单实例环境中同样存在：

可以从一个内部表（需要以SYS用户登录）中查询到当前的HeartBeat值：

从Oracle 9i 开始 ，Oracle在数据库通过等待事件 controller file heartbeat 来记录这个事件相关的等待：

了解启动的各个步骤，也就可以在发生问题的时候，快速定位，准确判断，从而快速解决问题。

启动到 mount 状态，数据库必须具备另外一个重要文件是口令文件，改文件位于 $ORACLE_HOME/dbs 目录下，缺省的名称为： orapw<sid>

口令文件中存放 sysdba/sysoper 用户的用户名和口令：

在数据库没有启动之前，数据库内建用户是无法通过数据库本身来验证身份的，通过口令文件，Oracle可以实现对用户的身份认证，在数据库未启动之前登录， 进而启动数据库。

如果丢失了口令文件，在 mount 阶段就会出现错误：

对于口令文件，Oracle缺省查找 orapw<sid>文件，如果文件不存在，则继续查找 orapw文件，如果都不存在，则数据库将会出现错误。

如果口令文件丢失，通过 orapw 工具可重建，所以通常的备份策略可以不包含口令文件：

通常在 Linux/Unix平台下， 在 $ORACLE_HOME/dbs目录下，还会存在 lk<SID> ,lk 指 lock ,该文件在数据库启动时创建，用于操作系统对数据库的锁定。

 当数据库启动时获得锁定，数据库关闭时释放。

    有时在系统出现异常时，可能数据库已经关闭，但是锁定并未释放，或者因为后台进程未正常停止等原因，会导致下次数据库无法启动，相关的 错误信息类似如下：

改文件内容通常只有一行，提示不要删除，该文件仅仅用于锁定：

这样的问题很少出现，通常在正常关闭数据库后可以 重新启动。

1.1.3 启动数据库open阶段：

 由于控制文件中记录了数据库中数据文件、日志文件的位置信息、检查点信息等重要信息，所以在数据库的open阶段，Oracle可以根据控制文件中记录的这些信息找到

这些文件，然后进行检查点及完整性检查。

    如果不存在问题就可以启动数据库，如果存在不一致或者文件丢失 则需要进行恢复。

实际在数据库open的过程中，Oracle进行的检查中，包括以下两项：

    第一次检查数据文件头中的检查点技术（Checkpoint cnt）是否和控制文件中的检查点计数（Checkpoint cnt）一致。此步骤检查用以确认数据文件是来自同一个版本，而不是

从备份中恢复而来（因为Checkpoint cnt 不会被冻结，会一直被修改）。

简单看一下跟踪文件信息，

1.正常情况下，转储控制文件。

2.执行 Begin BackUp以后的。

    注意到 Checkpoint  cnt 增加1，对表空间执行 Begin Backup 会触发一次表空间检查点：

3.执行手工检查点：

在表空间热备份模式下，手工执行检查点后，Checkpoint cnt 增加，但是SCN不变。这是由于表空间处于热备份模式数据文件检查点被冻结

（热备份模式下，数据库会生产额外的Redo日志）

4. End Backup后的情况：

此时数据文件头的冻结被取消，SCN开始变化。

。。。

数据库出现故障时，优先检查 alert_<sid>.log ,从中发现出现故障的详细信息。

 

从报警日志查看完整的数据库启动过程：

在完成数据库的验证和恢复过程后，数据库处于一致的状态，还要进行一系列的处理过程：

将Undo段在线等操作，然后数据库可以提供访问，同时SMON可以开始进行事务回滚等。

在启动日志里，有：

Database character is ZHS16GBK

在每次数据库启动的过程中，Oracle都需要判断控制文件中记录的字符集和数据库中的字符集是否相同，如果相符，则记录如上一行日志；如果不符，则以数据库中的字符集为准更新控制文件中的字符集记录。

类似日志如下：

Updating character set in controlfile to ZHS16CGB231280

30页--------------