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,用于进行启动时检查数据是否一致。