? open_cursors? ? ? ? ? ? = 300
? diagnostic_dest? ? ? ? ? = "/u01/app/oracle"
? trace_enabled? ? ? ? ? ? = TRUE
Thu Apr 02 14:59:41 2015
PMON started with pid=2, OS id=5989
Thu Apr 02 14:59:41 2015
VKTM started with pid=3, OS id=5991 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Thu Apr 02 14:59:41 2015
GEN0 started with pid=4, OS id=5995
Thu Apr 02 14:59:41 2015
DIAG started with pid=5, OS id=5997
Thu Apr 02 14:59:41 2015
DBRM started with pid=6, OS id=5999
Thu Apr 02 14:59:41 2015
PSP0 started with pid=7, OS id=6001
Thu Apr 02 14:59:41 2015
DIA0 started with pid=8, OS id=6003
Thu Apr 02 14:59:41 2015
MMAN started with pid=9, OS id=6005
Thu Apr 02 14:59:41 2015
DBW0 started with pid=10, OS id=6007
Thu Apr 02 14:59:41 2015
LGWR started with pid=11, OS id=6009
Thu Apr 02 14:59:41 2015
CKPT started with pid=12, OS id=6011
Thu Apr 02 14:59:41 2015
SMON started with pid=13, OS id=6013
Thu Apr 02 14:59:41 2015
RECO started with pid=14, OS id=6015
Thu Apr 02 14:59:41 2015
MMON started with pid=15, OS id=6017
Thu Apr 02 14:59:41 2015
MMNL started with pid=16, OS id=6019
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle
?
已选择19行。
分析第二个过程mount:
告警日志中：
alter database mount
Thu Apr 02 15:33:03 2015
Successful mount of redo thread 1, with mount id 3864558315
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount
有参数文件中，找到了control_file的位置并锁定控制文件：
SQL> show parameter control_files;
NAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE? ? ? ? ? ? ? ? ? ? ? ? ? ? ? VALUE
------------------------------------ --------------------------------- ------------------------------
control_files? ? ? ? ? ? ? ? ? ? ? ? string? ? ? ? ? ? ? ? ? ? ? ? ? ? /u01/app/oracle/oradata/orcl39
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 39/control01.ctl, /u01/app/ora
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cle/flash_recovery_area/orcl39
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 39/control02.ctl, /u01/app/ora
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cle/oradata/orcl3939/control03
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .ctl
这三个控制文件的大小一样，3个控制文件最好放在不同的物理磁盘上，往控制文件中写信息的时候并发同时写，所以3个控制文件的内容是相同的，但是读取的时候，只读取第一个，如果3个控制文件有一个出错了，oracle就不能启动了。在实际的生产工程中，不建议放在同一磁盘上，这样不利于数据库遇到磁盘介质损坏的恢复。
控制文件中包含了联机重做日志文件和数据文件的位置。
分析第三个过程open:
由于控制文件中记录了数据文件，日志文件的位置，检查点信息等重要的信息，在open阶段时，数据库根据控制文件中记录的这些信息找到这些文件，然后进行检查点及完整性检查。如果没有问题可以启动数据库，如果存在不一致或者文件丢失则需要恢复数据库。关于数据库的一致性性检查在这里不做阐述。
在这三个过程中，每个过程可以查些什么动态性能视图（动态性能视图是在数据库启动时自动创建）:
nomount:
只是启动了实例，启动实例的信息主要来自参数文件，参数文件中记录的信息可以查询，可以查：v$parameter,v$spparameter,v$sga,v$sgastat,v$bh,v$instance,v$option,v$version,v$process,v$session
mount:
此时控制文件被读取，和控制文件相关的视图可以查询，这要有：v$thread,v$controlfile,v$database,v$datafile,v$logfile,v$datafile_header
open:
open之后，所有的动态性能视图都可以查询。