这段时间有点迷惘，不知道接下来干嘛了。想辞职，重新找一份java开发相关的工作，也就意味着这一年多数据库运维、开发的经验就浪费了，而且换到java岗我是否就真的热爱这份职业呢？真不知道干嘛了，毕业一年多，走走停停，各种折腾，24岁了，一无所成。最近迷上了一首歌4 Non Blondes - What's Up唱出了自己的迷茫与无措，希望在25岁的时候听到这首歌是不一样的感觉。
只要使用过oracle database，那么肯定执行过很多次的startup和shutdown的操作，但是你是否关心过这个过程发生了什么？这篇文章主要讲讲oracle启动与停止过程oracle后台发生的事情。
实例与数据库
首先需要弄清楚一些概念性的东西。我们平时只会说数据库是否启动，关闭很少用到实例的概念，说到实例，或许你想到的只是SID这个词。
实例和数据库是两个独立却又相互关联的两个不同的东西，他们都可以独立于彼此而存在。实例存在于内存，包含一大堆后台进程，而数据库存在于磁盘中。数据库和实例的关系可以是one to one或者one to many(例如RAC就是one to many的)，但是绝对不存在一个实例对应多个数据库的情况。
实例启动的时候，会为其分配一个叫System Global Area(SGA)的系统全局区的内存区域以及一系列的后台进程，它们的主要任务是：
- 维护对内部数据的并发访问
- 缓存数据块
- 缓存未写入联机重做日志文件的重做数据
- 存储SQL的执行计划
下图展示了oracle实例的主要组件(图片来自oracle concept)：
每个主机上可以创建多个数据库实例，ORACLE通过system identifier(SID)来唯一标识一个实例。Linux或者Unix下可以通过ORACLE_SID环境变量设置该主机访问的默认SID，当我们通过SQL Net访问数据库时也需要指定ORACLE SID。
在我们安装oracle数据库时，我们会设置两个环境变量，一个是ORACLE_BASE，以及ORACLE_HOME。ORACLE_BASE是安装oracle二进制文件的目录,ORACLE_HOME是数据库软件的安装目录，位于ORACLE_BASE子目录，我们可以在同一个主机上安装不同的数据库软件在独立的ORACLE_HOME下。
从执行startup到可以访问数据库
数据库的启动包括了四个阶段：从SHUTDOWN->NOMOUNT->MOUNT->OPEN,如下图(图片来自ORACLE CONCEPT)：
可以使用STARTUP NOMOUNT、STARTUP MOUNT和STARTUP启动到各个不同的状态。
NOMOUNT
STARTUP NOMOUNT只进行instance的启动，该状态下可以执行数据库的创建、备份以及恢复操作，该阶段会依次完成以下操作：
- 在默认位置查找
server parameter file(spfile),若读取不到，则进一步查找文本格式的initialization parameter file(pfile)，读取参数文件的初始化参数。 - 根据参数文件的设置，分配SGA。
- 启动后台进程
- 打开
alter log以及trace file写入显示参数设置。
pfile参数文件一般默认在ORACLE_HOME/dbs目录下，以init+${ORACLE_SID}.ora方式命名。其中包含了控制文件位置、adump文件地址、UNDO表空间、兼容版本、DB_NAME、内存分配信息等。 实例启动时首先尝试读取spfile，获取失败，再寻找文本格式的pfile，都获取不到则启动失败。此时可以通过以下方式启动实例：
1、通常数据库中会存在一份pfile的克隆文件，文件名以init.ora.数字的方式命名，通过STARTUP PFILE='克隆参数文件地址'方式启动。
2、手动重建参数文件。参数文件的创建还是很简单的，注意__oracle_base、*.audit_file_dest、*.control_files、*.db_recovery_file_dest、*.db_name、*.diagnostic_dest即可,其他非默认参数可以在trace文件中获取，创建pfile，然后指定pfile启动即可。
以上步骤完成后需执行create spfile from pfile命令，否则下次启动时仍需以指定pfile的方式才能启动。
当实例启动后，具备SYSDBA、SYSOPER、SYSBACKUP、SYSDG、SYSKM权限的用户就可以登录了。
MOUNT
该阶段创建实例与数据库之间的关联。实例通过*.control_files定位控制文件位置，并打开控制文件读取数据库相关信息，包括数据文件、redo日志在磁盘中的位置以及名称。
控制文件是实例与数据库沟通的桥梁，控制文件丢失将导致实例无法访问到数据库的信息，从而无法装载数据库。关于控制文件的重建，可以查看我之前写的一篇博文，重建控制文件。控制文件的重建需要定位所有数据文件以及redo日志的位置。
OPEN
只有启动到OPEN状态我们才能对数据库进行正常的操作，这时普通用户才能登陆数据库。当OPEN数据库时，首先会打开除undo以外的，处于online状态的数据文件；然后打开undo数据文件；最后才是打开在线重做日志文件。如果我们关闭数据库的执行shutdown abort，那么在这一步将执行实例恢复的操作。在这个过程我们容易遇到的主要问题有，数据文件的丢失、损坏等情况。
在11G中存在服务器异常关闭后无法自动完成实例恢复的bug，需要手动的完成实例恢复。
从OPEN到SHUTDOWN
首先看下oracle concept中SHUTDOWN数据库的顺序图：
首先会关闭数据文件以及联机重做日志，然后关闭控制文件到NOMOUNT状态，此时实例仍在运行，最后shutdown实例。
SHUTODOWN模式
shutdown命令有ABORT、IMMEDIATE、TRANSACTIONAL、NORMAL四种模式，其产生的行为如下表：
| Database Behavior | ABORT | IMMEDIATE | TRANSACTIONAL | NORMAL |
|---|---|---|---|---|
| Permits new userconnections | × | × | × | × |
| Waits until current sessions end | × | × | × | √ |
| Waits until current transactions end | × | × | √ | √ |
| Performs a checkpoint and closes open files | × | √ | √ | √ |
SHUTDOWN ABORT仅在迫不得已的情况下才使用，例如其他三种模式均无法关闭数据库。该模式不会将checkpoint写入数据文件的header中，也会不将SGA中的缓存的数据写入数据文件和联机重做日志中、以及对当前事物进行回滚，当启动数据库时需要进行实例恢复。
小结
数据库启动时涉及到的参数文件以及控制文件，虽然后期都能手动重建，但是还是需要耗费一些时间的，特别是控制文件的重建。建议在日常的运维中，对控制文件和参数文件都进行一下备份，平时多花一些时间，可以让我们在遇到数据库宕机时节省很多时间。对于控制文件，我们可以创建多份控制文件，放置在不同的磁盘即可。当我们执行alter system命令修改参数时使用scope=both，将修改的参数同时写入spfile和pfile，并对pfile进行备份。
理解数据库启动各个阶段执行的操作，对于我们快速定位无法启动数据库还是很有必要的，只有理解了每个阶段实例会进行哪些操作，我们能大大缩小数据库无法启动到下一个阶段的问题范围。