1.控制文件概念
任何用户包括数据库管理员都不能修改控制文件中数据。
每一个控制文件只属于一个数据库，一个数据库不只一个控制文件，每个控制文件中内容完全一样。
如ORACLE不能访问控制文件，数据库将无法正常工作，如数据库的所有控制文件都出问题，那么这个数据库就需要进行恢复。因此建议将控制文件备份多个（2个以上）并放置在不同的物理磁盘上。
2.控制文件中的信息：
1.数据库的名字，取自初始化参数说明的数据库名字或CREATE DATABASE语句中所使用的名字
2.数据库创建时间戳，是数据库创建时产生的。
3.数据库标识符，是创建数据库时ORACLE自动生成的。
4.联机重做日志文件的名字和准确位置，增加删除修改重做日志文件时，ORACLE会修改相关信息。
5.当前日志的序列号，是在日志切换时ORACLE记录的。
6.检查点信息CHECKPOINT，是在产生校验点时ORACLE记录的以及SCN。
7.日志的历史信息，是在日志切换时ORACLE记录的。
8.归档日志文件的准确位置和状态，是在重做日志文件被归档（复制到归档日志文件）时ORACLE记录的
9，数据文件的名字和准确位置，增加删除修改数据文件名字，ORACLE会修改相关信息。
10.表空间的相关信息，增加删除表空间时，ORACLE会修改相关信息。
11.备份准确位置和状态，这些信息是由恢复管理器记录的。
3.SCN
SCN system change number,是数据库中非常重要的一个数据结构，用以标识数据库在某个确切时刻提交的版本，事务提交时，被赋予一个唯一标示事务的SCN。SCN同时作为ORACLE数据库内部时钟机制，可称为逻辑时钟，每个数据库都有一个全局SCN生成器。事务依SCN排序，ORACLE也根据SCN实现一致性读read consistecy等功能，通过SCN实现ORACLE的恢复机制.
SCN是数据库中唯一的，并随时间而增加，可能不连续。除非重建数据库，SCN值永不会重置为0.，SCN更详细见：http://blog.csdn.net/haibusuanyun/article/details/11590983
SQL>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
1549848
通过v$database视图查询数据库当前SCN值
SQL>select current_scn from v$database;
系统当前SCN并不在任何数据库操作发生时都改变。通常在事务提交或回滚时改变 。
数据文件头中包含了该数据文件的checkpoint scn，表示该数据文件最近一次执行检查点操作时的SCN.
日志文件中包含LOW SCN 和NEXT SCN。表示该日志文件中包含了LOW SCN 和NEXT SCN之间的重做信息，对于CURRENT即当前正在使用的日志文件，最终SCN不可知，所以设置为无穷大-Ffffff。
ORACLE恢复时可以根据低SCN和高SCN确定所需要的恢复信息位于哪一个日志或归档日志中。各种SCN查询详见：http://blog.csdn.net/haibusuanyun/article/details/11590735
SQL>select group#,sequence#,status,first_change#,next_change# from v$log;
GROUP# SEQUENCE# STATUS FIRST_CHANGE# NEXT_CHANGE#
-------------------- ---------------- ------------- ------------
4 57 INACTIVE 1542114 1545862
5 58 CURRENT 1545862 2.8147E+14
6 54 INACTIVE 1511031 1513282
4.检查点--chkpoint
检查点是一个数据库事件，存在的意义在于减少崩溃恢复crash recovery时间，检查点事件由后台进程CKPT触发，当检查点发生时，CKPT通知DBWR进程将脏数据库dirtybuffer写出到数据文件上，更新数据文件头及控制文件上的检查点信息。数据文件头的SCN是CHECKPOINT SCN.
检查点工作原理：
在数据库中，进行数据修改时，需要先将数据读和内存中buffer cache,修改数据同时，ORACLE会记录重做redo信息用于恢复，有了重做日志信息存在，ORACLE不需要在事务提交时commit立刻将变化的数据写回磁盘，因为立刻写效率会低。重做信息存在也为数据崩溃后，数据可以恢复。如断电，内存中修改过未写入数据文件的数据丢失，下一次数据库启动时，可以通过重做日志进行事务重演（不管是否提交），即前滚。将数据库恢复至崩溃前状态，然后数据库可以打开提供使用，之后ORACLE将未提交的事务回滚。
检查点存在是为了缩短上述数据恢复的时间。当检查点发行时，此时的SCN称为checkpoint scn,ORACLE会通知DBWR，把修改过的数据，即此checkpoint scn之前的脏数据dirty data从buffer cache写入磁盘，写入完成后，CKPT进程会相应更新控制文件和数据文件头，记录此检查点信息，标识变更。
检查点完成后，此检查点之前修改过后 数据都已经写出到数据文件，重做日志中的相应重做记录对于实例恢复已经无用。
查询checkpoint scn 检查点
SQL>select file#,checkpoint_change#,to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss')cptime from v$datafile;
FILE# CHECKPOINT_CHANGE# CPTIME
---------------------------- -------------------
1 1545862 2013-02-04 20:50:27
2 1545862 2013-02-04 20:50:27
常规检查点与增量检查点
常规检查点按特定条件触发，log_checkpoint_interval, log_checkpoint_timeout , log switch等条件，触发时同时更新数据文件头及控制文件中记录检查点信息。从8I开始，只有SHUTDOWN以及ALTER SYSTEM CHECKPOINT会触发完全检查点
Log switch 触发的也是增量检查点，但是会使数据文件头与控制文件信息同步
执行增量检查点时，DBWR从检查点队列按照LOW RBA顺序写出，先修改的数据可以被按优先顺序写出，实例检查点因此可以不被增进，同时CKPT进程阶段性使用轻量级控制文件更新协议将当前最低RBA写入控制文件，CKPT在进行轻量级更新时，不改写控制文件中数据文件中检查点信息以及数据文件头信息，只记录控制文件检查点SCN，controlfile checkpointed at scn 并根据增量检查点写出增进RBA信息。
通过增量检查点，数据库可以将全部写出改为增量渐进写出，从而极大减少对于数据库性能的影响，而检查点队列进一步将RBA和检查点关联起来，从而可以通过检查点确定恢复的起点。
初始化参数log_checkpoint_to_alert决定是否将检查占执行情况记入警告日志文件。默认false不记入
SQL>show parameter log_checkpoints_to_alert
NAME TYPE VALUE
----------------------------------------------- -------
log_checkpoints_to_alert boolean FALSE
5.控制文件与数据文件头信息
控制文件的SCN指最后一次成功完成的检查点SCN，数据文件头中记录的checkpoint at scn指数据文件中记录的最后一次成功完成检查点SCN。正常情况下两都相等。
此外在控制文件和数据文件头都记录一个检查点计数chkpt cnt，而且数据文件头还记录了控制文件检查点计数，ctl cnt。当检查点进程更新控制文件和数据文件头的chkpt cnt 检查点计数时，在更新控制文件之前，可以获得当前 ctl cnt ，这个信息被记入数据文件。因为不能保证更新控制文件上的chkpt cnt一定成功，如突然断电，记录之前成功的ctl cnt，可以确保上一次的checkpoint是成功完成。
如果当前数据文件中chkpt cnt是60，控制文件中记录的是70，ORACLE判断数据文件是从备份中恢复，或者文件故障，需要进行介质恢复。
如果控制文件是从备份中恢复的，数据文件的chkpt cnt大于控制文件的chkpt cnt，说明控制文件是旧的。
Low cache rba 指在cache中，最低的RBA地址，在实例恢复或崩溃中，需要从这里开始恢复（是cache中数据的起点）。On disk rba是磁盘上最高的重做值，在进行恢复时应用重做至少要达到这个值(是数据文件中数据的最高值)。
正常shutdown 数据库时执行了完全检查点，所有脏数据写入数据文件。在控制文件信息部分，对每个数据文件都有一个checkpoint scn和stop scn，用于进行启动时检查数据是否一致。