ITPub博客

首页 > Linux操作系统 > Linux操作系统 > scn4

scn4

原创 Linux操作系统 作者:wengjie_0627 时间:2011-05-19 16:36:26 0 删除 编辑
SCN是标识数据库变化的唯一标识号,数值顺序递增。当执行事务操作DDL或DML时,系统会为每个事务变化生成相应的SCN。其实SCN也分为四种:

* system checkpoint scn(存在于控制文件),它是针对整个DB全局的,只存在一个。在系统执行checkpoint后,oracle会更新当前控制文件中的该值。查看方式:select checkpoint_change# from v$database;

*datafile checkpoint scn(存在于控制文件),针对数据文件而言,所以每个datafile在controlfile中对应一个该值。在执行checkpoint时,oracle会更新controlfile中的各datafile的datafile checkpoint scn。查看方法:select name, checkpoint# from v$datafile;

*end scn(存在于控制文件),也是针对数据文件而言,与datafile对应。其存在主要是为了验证DB startup过程中是否要instance recovery。在DB正常运行时,对于read/write的online数据文件的此SCN为null。查询方法:select name, last_change# from v$datafile;

*start scn(在各个datafile头),其存在是用于检查数据库启动过程中是否要做media recovery介质恢复。查看方法:select checkp_change# from v$datafile_header;

        为了讲清SCN,先看oracle事务中data变化写入数据文件的步骤(没有包含undo log):

        1)事务开始;

        2)在buffer cache中找到需要的数据块,如果没有,则从datafile中载入buffer cache

        3)事务修改buffer cache的数据块,标识该数据块为脏数据,并被写入log buffer中

        4)事务提交,LGWR进程将log buffer中的记录写入redo log file

        5)当发生checkpoint,CKPT进程更新所有datafile中的头部信息,DBWn进程将buffer cache中脏数据写入datafile。

        事务提交时:在redo log中记录一条redo entry,其中就包含系统为其提供的一个SCN。如果该记录是在redo log被清空(日志满做切换时或checkpoint时,所有变化日志被写入数据文件),则此SCN被记录为redo log的low SCN,以后在日志再次被清空前写入的redo记录中的SCN则是Next SCN。

        当日志切换或发生checkpoint(上述第五个步骤)时,从Low SCN到Next SCN之间的所有redo记录的数据就被DBWn进程写入数据文件中,而CKPT进程则将所有数据文件(无论redo log中的数据是否影响到该数据文件)的文件头上记录的Start SCN更新为Next SCN,同时将控制文件中的System Checkpoint SCN、每个数据文件对应的Datafile Checkpoint也更新为Next SCN.但是,如果该数据文件所在的表空间被设置为read-only时,数据文件的Start SCN和控制文件中Datafile Checkpoint SCN都不会被更新。

         此外,SCN还起到了系统“心跳”的作用,每隔3秒会自动刷新一次系统SCN。

         在DB启动时,当System Checkpoint SCN=Datafile Checkpoint SCN=Start SCN的时候,Oracle数据库是可以正常启动的,而不需要做任何的media recovery。而如果三者当中有一个不同的话,则需要做media recovery。

         那什么时候需要做instance recovery呢?其实在正常open数据库的时候,oracle会将记录在控制文件中的每一个数据文件头的End SCN都设置为#FFFFFF(NULL),那么如果数据库进行了正常关闭比如(shutdown or shutdown immediate)这个时候,系统会执行一个检查点,这个检查点会将控制文件中记录的各个数据文件头的End SCN更新为当前online数据文件的各个数据文件头的Start SCN,也就是End SCN=Start SCN,如果再次启动数据库的时候发现二者相等,则直接打开数据库,并再次将End SCN设置为#FFFFFF(NULL),那么如果数据库是异常关闭,那么checkpoint就不会执行,因此再次打开数据库的时候End SCN<>Start SCN这个时候就需要做实例恢复。

         对只读表空间,其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。这三个SCN在表空间处于只读期间都将被冻结。

         如果控制文件不是当前的控制文件(其实就是说,相比当前redo log的SCN来讲,控制文件已经过时了),则System checkpoint SCN会小于Start SCN(Start SCN是来自实际的数据文件头,有比较依据)。记录这些SCN号,可以区分控制文件是否是当前的控制文件。当有一个Start SCN(从当前各个在线数据文件中获得)号超过了System Checkpoit SCN号时,则说明控制文件不是当前的控制文件,因此在做recovery时需要采用using backup controlfile。这是为什么需要记录SystemCheckpoint SCN的原因之一。

         当重建controlfile时,具体分两种方法(resetlogs和noresetlogs)(这里很不理解,后期在学习中理解

         1)使用resetlogs选项时,System Checkpoint SCN为被归为0,而其中记录的各个数据文件的Datafile Checkpoint SCN则来自于Start SCN(也就是说可能会从冷备份的数据文件的数据文件头中获取)。根据上述的描述,此时需要采用using backup controlfile做recovery. 因此情况是 System Checkpoint SCN=0 < Start SCN = Datafile Checkpoint SCN

         2)使用noresetlogs选项时,有一个前提就是:一定要有online redo log的存在。否则就要使用resetlogs选项。这个时候控制文件重建好时,其system checkpoint SCN=Datafile Checkpoint SCN=Lastest Checkpoint SCN in online redo log,我们可以看到Datafile Checkpoint SCN并没有从Start SCN中读取。而是读取了最新的日志文件中的SCN作为自己的数据。此时重建的控制文件在恢复中的作用跟最新的控制文件类似,System Checkpoint SCN(已经读取最新的redo log的checkpoint SCN信息)可能会>Start SCN (因为数据文件可能会从冷备份中恢复),恢复时就不需要加using backup controlfile子句了

        关于backup controlfile的补充:backup controlfile只有备份时刻的archive log信息,并没有DB crash时刻的archive log信息,所以并不会自动应用online redo log,而是提示找不到序号为Lastest Archive log sequence + 1 的archive log,尽管你可以手动指定online redo log来实现完全恢复,但因为一旦使用了using backup controlfile子句,Oracle就视为不完全恢复,必须open resetlogs! 实际上,假如你有旧的控制文件又不想resetlogs,那很简单,使用旧的控制文件mount然后 backup to trace ,然后手工创建控制文件,使用 reuse database … noresetlogs .这样就可以 recover database 自动恢复并open database 而不用 resetlogs 了

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24984814/viewspace-695764/,如需转载,请注明出处,否则将追究法律责任。

上一篇: SCN3
下一篇: FAST_START_MTTR_TARGET
请登录后发表评论 登录
全部评论

注册时间:2011-05-19

  • 博文量
    50
  • 访问量
    30333