ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Oracle的SCN相关问题(转载)

Oracle的SCN相关问题(转载)

原创 Linux操作系统 作者:litongbing 时间:2009-05-24 17:47:51 0 删除 编辑

Oracle的SCN相关问题

 

1、SCN的介绍


    Oracle
中的SCN有下面几种:

 

    系统检查点scn(v$database(checkpoint_change#))

当一个检查点动作完成之后,Oracle就把系统检查点的SCN存储到控制文件中

   select checkpoint_change# from v$database;

    数据文件检查点scn (v$datafile(checkpoint_change#))

    当一个检查点动作完成之后,Oracle就把每个数据文件的scn单独存放在控制文件中

        select name,checkpoint_change# from v$datafile;

    数据文件终止scn (v$datafile(last_change#))

    每个数据文件的终止scn都存储在控制文件中。在正常的数据库操作过程中,所有正处于联机读写模式下的数据文件的终止scn都为null

     select name,last_change# from v$datafile;

    数据文件启动scn (v$datafile_header(checkpoint_change#)

    Oracle把这个检查点的scn存储在每个数据文件的文件头中,这个值称为启动scn,因为它用于在数据库实例启动时,检查是否需要执行数据库恢复

     select name,checkpoint_change# from v$datafile_header;

2、SCN的工作机制:

 

    在数据库打开并运行之后,控制文件中的系统检查点scn、控制文件中的数据文件检查点scn和每个数据文件头中的启动scn都是相同的

 

    控制文件中的每个数据文件的终止scn都为null

 

    NORMALIMMEDIATE 关闭数据库的过程中,系统会执行一个检查点动作,这时所有数据文件的终止scn 都会设置成数据文件头中的那个启动scn的值。

 

    在数据库重新启动的时,Oracle将执行两次检查

        看数据文件头中的ckpt计数器是否与对应控制文件中的ckpt计数器一致。若相等,进行第二次检查

        比较文件头中的启动scn和对应控制文件中的终止scn进行比较,如果终止scn等于启动scn,则不需要对那个文件进行恢复

 

    数据库打开之后,存储在控制文件中的数据文件终止scn的值再次被更改为null,这表示数据文件已经打开并能够正常使用了

 

    注:当ABORT强制关闭数据库时不进行检查点处理,所以终止scn仍然为无穷大。在下次启动期间,发现启动scn和终止scn不同,需要进行线程恢复。

 

3、SCN的增加

 

    SCN(System Change Number)只要数据库被修改,就会+1,而不是一定要进行checkpoint,例如DML的发生即使没有提交也会使SCN+1

 

    注:SCN增加并不代表会在数据文件头中表现出来,而是需要等到checkpoint执行后才写入(当然可能已经增加了很多)

 

    如果一个DML导致产生事务,则会产生一个SCN。这个意思是说如果一个事务包含多个dml,则只有第一个初始产生事务的dml产生scn,提交的时候又是一个scn,如果一个事务只有一个dml,拿看起来就是dml产生一个scn,提交或者回滚产生一个scn

 

    Oracle 10g内部的SCN会默认不管有没有动作,每隔3s自动增加一次。其他需要增加的情况则再加。

 

    只有ckpt进程才会修改文件头中的checkpoint计数器和SCNDBWR只会修改数据块,即ckpt通知dbwr写数据文件,写完之后 ckpt更新控制文件和数据文件头。此时若DBWR发现数据块的log block还没有被写入日志文件,则在dbwr写块之前通知llgwrlog buffer中的日志写入log文件。

 

    注:总结一下,日志切换必定出发ckpt,但ckpt不一定会出发llgwr,但是一定会触发dbwr

 

 

4、其他的SCN

 

    日志文件头中包含了Low scnNext scn,表示给日志文件包含有从Low scnNext scnredo record

 

    注:当系统运行时,日志文件的Next scn同样为无穷大。而且需要注意:在恢复时不是用日志文件中的Low scnNext scn来选择恢复的日志文件,而是通过数据文件头中的信息。

 

    数据块中的SCN

    data block里面的SCN是当block被更改的时候的SCN,而数据文件有那么多 block,自然不同的block有不同的SCNblock中存在block SCNITL中的commit SCNblock SCN 又在块头和块位都有,若不一致意味着block损坏。而ITL中的commit SCN则跟consistent gets and delay block cleanout有关。

    v$database中的checkpoint_change# dbms_flashback.get_system_change_number 不同。前者是作为数据库的最后一次checkpoint是的SCN,而后者是系统的最新SCN,所以一般后者都会比前者大,而当刚做完 checkpoint时两者会差不多。

 

    begin backup命令发出后,相关数据文件的checkpoint scn被冻结(以及状态标志被改变),其他一切照旧。例如:日志切换时checkpoint count正常递增/检查点照常写文件,自然文件中的数据块内的各种scn也照常递增。

 

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

请登录后发表评论 登录
全部评论

注册时间:2009-05-13

  • 博文量
    59
  • 访问量
    204101