系统改变号(SCN)详解

系统改变号SCN

  System Change Number

  我们看到的SCN一串数字,由时间通过函数算出来的,或者通过函数将SCN转成时间,简单的理解,SCN相当于时间。

  两个时间的比较就是两个字符串比较,但是计算机内部比较倾向于数字之间的比较

  时间使用来比较先后以及比较新旧的。所以在Oracle数据库中用的较多,可以经常在数据库接触到SCN,通过SCN的大小来判断数据的新旧或者先后顺序。

SQL> select dbms_flashback.get_system_change_number,SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) from dual;

 SCN在数据库中的应用

   1.控制文件

    系统SCN

      select checkpoint_change# from v$database;

    

    文件SCN

      select name,checkpoint_change# from v$datafile;

    

    结束SCN

      select name,last_change# from v$datafile;

    

    检查点信息

     增量检查点并不会去更新数据文件头,以及控制文件中的数据库SCN以及数据文件条目的SCN信息,而只是每3秒由CKPT进程去更新控制文件中的low cache rba信息,也就是检查点的位置。

select CPDRT,
CPLRBA_SEQ||'.'||CPLRBA_BNO||'.'||CPLRBA_BOF "Low RBA",
CPODR_SEQ||'.'||CPODR_BNO||'.'||CPODR_BOF "On disk RBA",CPODS,CPODT,CPHBT FROM x$kcccp;

CPDRT---检查点队列中的脏块数目

CPODS---是On disk RBA的SCN

CPODT---是On disk RBA的时间戳

CPHBT----是心跳

  控制文件有三个SCN号,假设系统有四个数据文件,在控制文件中有一个系统SCN,对于每个数据文件有文件SCN,针对四个文件还有一个结束SCN,在文件的头部有开始SCN,目的只有一个保证数据文件的一致性!!

  正常的情况下,数据库打开以后,系统SCN,在控制文件中的文件SCN,和开始SCN是相等的,因为数据库正常运行中,所以结束SCN应该是空。

  数据库正常关闭以后,会将buffercache的所有缓存写到磁盘上,同时使用关闭时间点更新系统SCN,文件SCN和头部SCN。同时并将终止SCN设置成与其他三类SCN一样。

  当数据库正常关闭以后,系统SCN,文件SCN,开始SCN,结束SCN都是一样的

  如果数据库非正常关闭,此时的终止SCN是空的,当数据库下一次启动后就会发现终止SCN为空,也就是知道数据库非正常关闭,需要进行恢复。但是当进行恢复时,Oracle发现其他三类SCN是一样的,唯独终止SCN为空,此时Orace就知道,需要做实例恢复。

Oracle在做实例恢复的时候:

        1.需要部分redolog日志,不需要所有的redolog,不需要归档log

        2.需要的日志,在控制文件中记录着LRBA和O你 disk RBA,Oracle只找这段日志。而这段日志存在在redolog中。

redolog的状态:I 、Active 、current

   当日志跑完了后,证明数据已经恢复,此时就可以正常的使用数据库了。

  Oracle判断是否进行实例恢复是通过这些SCN的!!

  SCN的作用:保证数据库的数据的一致性!!!

 

假设一种情况:

    关闭数据库,此时将四个数据文件中的一个文件删除换成一个旧的备份文件,那么在oracle在祁东的时候就会发现,该文件的开始SCN与系统SCN和文件SCN是不一样的,这时Oracle通过日志将SCN跑成一样的。

  在行业中经常说的一句话: 跑日志----目的:提升SCN

  通过SCN可以判断文件的新旧,如果是旧的文件,旧的SCN,那么就会通过跑日志,将SCN更新成新的。实际上,就是将新文件进行恢复。

  以上是四个SCN关联起来的作用。对于以后进行数据的恢复有很大的帮助。

  每一个日志条文件的头部都有两个SCN,一个叫first,另个叫next

  first是这一条日志的第一个SCN号,而next为最后一个SCN号(下一条日志的第一个SCN)

  那么first和next记录的是这个日志文件所有的SCN号的范围

 

假设:有一个控制文件,四个dbf数据文件,还有日志文件

  数据库在正常运行的期间,会有四个SCN号,分别是控制文件的系统SCN,文件SCN,结束SCN以及文件头部的开始SCN,除了结束SCN为空,其他三个SCN是相等的。

查看系统SCN和文件SCN

select name,checkpoint_change# from v$datafile;

在查看日志文件当前文件的SCN

select * from v$log;

  这些SCN相等的,假如说这时数据库崩溃,此时需要恢复文件,只需要恢复884269之后文件即可,需要用到的日志就是当前日志即可(current)

  此时做一个操作,执行两次强制日志切换,再去查看系统 文件以及firstSCN号

 

   这时原来的current变为active(884269)

 

   在这种状态下,数据库如果崩溃,需进行日志恢复,需要用到61号日志开始一直到63号日志,也就是三个日志。

  文件的SCN号主要用来标识文件的新旧程度

  当做日志切换的时候,系统的SCN号是不发生改变的,这四类SCN号的主要作用标志着文件的新旧程度以及一致程度。

  其实在控制文件中是有具体的LRBA地址,具体oracle恢复时去找LRBA地址进行恢复

 

  此时做另外一个操作,将buffer_cache中的所有脏块写入磁盘,此时在查看日志

 

   日志状态由原来的active变为inactive

  active----代表日志文件中的日志所对应的脏缓冲区未写入磁盘 代表日志不能被覆盖

  脏缓冲区还未写回去意味着实例恢复的时候还需要active的日志

 

  控制文件中的3个SCN号以及dbf头部的SCN号记录的是日志文件中的current和active日志的SCN号

  在控制文件中的SCN号只是用来确定使用哪个日志文件进行恢复,而在日志之中,并不是所有的日志都要用到,控制文件中的LRBA地址决定的是使用日志文件中的哪些日志进行恢复。

系统,文件,起始SCN对应的是日志文件中最老的active日志的firstSCN号。

  当检查点队列发生的时候,系统 ,文件,结束,起始SCN没有被更新,只是更新了控制文件中的LRBA地址。

  而这四个SCN什么时候会更新呢?只有在数据库关闭的时候会更新。

  而三个SCN什么时候会更新呢?只有日志状态的active变成inactive才会更新。

 

  数据库非正常关闭的话,结束SCN为空,此时oracle会知道需要进行数据库恢复,但是当dbf文件被替换成旧的dbf时,需要用到归档日志和redolog日志一起将dbf文件恢复到最新。

 

  做一个操作, 将数据库关闭,将控制文件以及四个dbf文件全部换成旧的,当oracle启动对四类SCN号进行判断的时候,是没有办法确定四个文件是新还是旧,需要看redolog中的on disk RBA(redolog中current的最后一条日志)会比四个SCN号要新,所以要恢复,仅仅使用redolog是没有办法进行恢复的。还需要归档日志。

查询以往日志的first和next

select recid,sequence#,first_change#,next_change# from v$log_history where rownum<6;

  数据块有SCN,日志有SCN,假设块是新的,日志是旧的,那么在跑日志的时候,发现日志的SCN会比块的SCN旧,日志会略过块,空跑。

  所以对于实例恢复时,跑日志是可以多,但不能少。

 

 Oracle有一个参数,fast_start_mttr_target

参考博文:https://blog.csdn.net/qq_36249352/article/details/80704548

 

  

posted @ 2019-12-29 15:02  KAJIA1  阅读(1322)  评论(0编辑  收藏  举报