该文件在数据库启动时创建，用于操作系统对数据库的锁定。当数据库启动时获得锁定，数 据库关闭时释放。在系统出现异常时，可能数
现象
c:\users\陈>sqlplus "/as sysdba"
sql*plus: release 11.2.0.1.0 production on wed oct 10 13:31:28 2012
copyright (c) 1982, 2010, oracle. all rights reserved.
connected to:
oracle database 11g enterprise edition release 11.2.0.1.0 -production
with the partitioning, olap, data mining and real application testing options
sql> shutdown immediate
database closed.
database dismounted.
oracle instance shut down.
sql> startup nomount
ora-01078: failure in processing system parameters
lrm-00109: could not open parameter file 'e:\app\cswggod\product\11.2.0\dbhome_1
\database\initorcl.ora'
原因：缺失initorcl.ora
解决方法：
1.复制initorcl.ora文件
c:\users\陈>e:
--------复制initorcl.ora备份文件
e:\app\cswggod\product\11.2.0\dbhome_1\database>copy e:\app\cswggod\admin\orcl\p
file\init.ora.7182012101127 initorcl.ora
已复制1 个文件。
e:\app\cswggod\product\11.2.0\dbhome_1\database>dir
驱动器e 中的卷是workware
卷的序列号是027b-a992
e:\app\cswggod\product\11.2.0\dbhome_1\database 的目录
2012/10/10 13:34
2012/10/10 13:34
2012/08/18 10:02
2012/08/18 10:04 2,048 hc_orcl.dat
2012/10/08 15:51 1,973 initorcl.ora
2.启动数据库
c: \users\陈>sqlplus "/as sysdba"
sql*plus: release 11.2.0.1.0 production on wed oct 10 13:31:28 2012
copyright (c) 1982, 2010, oracle. all rights reserved.
connected to:
oracle database 11g enterprise edition release 11.2.0.1.0 - production
with the partitioning, olap, data mining and real application testing options
sql> startup nomount
oracle instance started.
total system global area 1071333376 bytes fixed size 1375792 bytes variable size 528482768 bytes database buffers 536870912 bytes redo buffers 4603904 bytes sql> shutdown immediate
ora-01507: database not mounted
oracle instance shut down. sql>
sql> startup
oracle instance started.
total system global area 1071333376 bytes fixed size 1375792 bytes variable size 528482768 bytes database buffers 536870912 bytes redo buffers 4603904 bytes database mounted.
database opened.
3.附录-数据库启动过程
1)nomount
这一步只和参数文件有关，如果在这一步就出现问题，那么通常可能是系统配置(如内核参 数等)存在问题，需要检查是否分配了足够的系统资源。
2)mount
这一步需要从参数文件中获得控制文件位置，读取其中内容，校验数据文件的存在性。除此之外还会去校验口令文件。oracle 缺省查找 orapw
--------------------------------------------
该文件在数据库启动时创建，用于操作系统对数据库的锁定。当数据库启动时获得锁定，数 据库关闭时释放。在系统出现异常时，可能数据库已经关闭，但锁定并未释放，或者因为后 台进程未正常停止等原因，会导致下次数据库无法启动。解决办法就是重启服务器，或者手工释放共享内存段。
3)open
这一步将进行检查点和完整性的检查。如果检查全部通过，则打开数据库，否则给出错误警 告，停止打开数据库。
-------------------------------------------------------数据库的启动验证--------------------------------------
○1 . 第一次检查数据文件头中的 checkpoint cnt 是否与对应控制文件中的 checkpoint cnt
一致。此步骤检查用以确认数据文件是否来自同一版本，而不是从备份中恢复而来
（在热备份模式下，数据文件检查点被冻结，但检查点计数不会被冻结，会一直修改） 在 oracle10g 中用 8 级转储获得控制文件信息。
sql> alter session set events 'immediate trace name controlf level 8';
在 oracle9i 中用 10 级转储。
----------------------------------------------------------------------------------------------------------------------------
○2 . 第二次检查数据文件头的开始 scn 和控制文件中记录的该文件的的结束 scn 是否一致。如果一致，则不需要对那个文件进行恢复。
部分控制文件转储内容：
222 data file records
223 ***************************************************************************
224 (size = 428, compat size = 428, section max = 100, section in-use = 5,
225 last-recid= 8, old-recno = 0, last-recno = 0)
226 (extent = 1, blkno = 11, numrecs = 100)
227 data file #1:
228 (name #7) /u01/app/oracle/oradata/orcl/system01.dbf
229 creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
230 tablespace 0, index=1 krfil=1 prev_file=0
231 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
232 checkpoint cnt:52 scn: 0x0000.0007ba16 02/18/2011 16:30:22
233 stop scn: 0xffff.ffffffff 02/16/2011 11:07:26
234 creation checkpointed at scn: 0x0000.00000009 06/30/2005 19:10:11
235 thread:0 rba:(0x0.0.0)
236 enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
----------------------------------------------------------------------------------------------------------------------------
在数据库出现问题时，提示中给出的可能是不完整的信息，而告警日志中则记录了完整的错 误过程和错误号。
说明:
控制文件中记录的 scn 指最后一次成功完成的检查点 scn； 数据文件头中的记录的 scn 指数据文件最后一次成功完成的检查点 scn；
此外，在控制文件和数据文件头都记录一个检查点计数(chkpt cnt)，而且数据文件头还记录了一个 控制文件检查点计数(ctl cnt)。但这个 ctl cnt 要比控制文件中的 ctl cnt 小 1。这是因为，当检查
点更新控制文件和数据文件头上的 chkpt cnt 信息时，在更新控制文件之前，可以
获得当前的 ctl cnt
,这个信息被记入了数据文件。之所以这么做，是因为不能保证更新控制文件上的 chkpt cnt 一定 会成功，记录之前的 ctl cnt 可以确保上一次的 chkpt cnt 是成功 完成的。
