Oracle的SCN相关问题 ---载自别人的博客（待验证)

下面摘录一些Oracle控制一致性的方法，来直观得了解一下，DBMS是如何来处理一致性的问题的：

1、SCN的介绍

Oracle中的SCN有下面几种：

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

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

selectcheckpoint_change# from v$database;

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

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

selectname,checkpoint_change# from v$datafile;

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

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

selectname,last_change# from v$datafile;

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

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

selectname,checkpoint_change# fromv$datafile_header;

2、SCN的工作机制：

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

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

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

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

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

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

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

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

3、SCN的增加

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

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

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

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

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

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

4、其他的SCN

①日志文件头中包含了Lowscn、Next scn，表示给日志文件包含有从Low scn到Next scn的redorecord

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

②数据块中的SCN

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

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

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

 

 

了解oracle中的SCN

 

 

从接触oracle到使用过程中，始终能看到SCN的身影，在oracle的备份恢复原理中更是如此。由此看来SCN的重要性不言而喻呀，对其有个综合的了解能够有对其功能有清晰地认识，在oracle中SCN的种类不一中，对SCN理解的时候常常犯晕，偶尔这样，偶尔那样。说白了就是把多种SCN混淆在一起了。

如果结合控制文件，数据文件，redo等文件的dump内容来了解那几种重要的SCN，将会对其有更深的认识。

直接入题：

SCN: System ChangeNumber
SCN是顺序递增的一个数字，在Oracle中用来标识数据库的每一次改动，及其先后顺序。SCN的最大值是0xffff.ffffffff。

Oracle对SCN的管理
单节点的instance中，SCN值存在SGA区，由system commit numberlatch保护。任何进程要得到当前的SCN值，都要先得到这个latch。

RAC/OPS环境中
Oracle通过排队机制(Enqueue)实现SCN在各并行节点之间的顺序增长。具体有两种方法：

Lamport算法：又称面包房算法，先来先服务算法。跟很多银行采用的排队机制一样。客户到了银行，先领取一个服务号。一旦某个窗口出现空闲，拥有最小服务号的客户就可以去空闲窗口办理业务。

Commit广播算法：一有commit完成，最新的SCN就广播到所有节点中。

上述两种算法可以通过调整初始化参数max_commit_propagation_delay来切换。在多数系统(除了Compaq Tur64Unix)中，该参数的默认值都是700厘秒(centisecond)，采用Lamport算法。如果该值小于100厘秒，Oracle就采用广播算法，并且记录在alert.log文件中。

几种重要的SCN
Commit SCN
当用户提交commit命令后，系统将当前scn赋给该transaction。这些信息都反映在redobuffer中，并马上更新到redo log 文件里。

Offline SCN
除了Systemtablespace以外的任何表空间，当我们执行SQL>alter tablespace …offline normal命令时，就会触发一个checkpoint，将内存中的dirtybuffer写入磁盘文件中。Checkpoint完成后，数据文件头会更新checkpoint scn和offline normalscn值。其中数据库文件头的checkpointscn值可通过查询列x$kccfe.fecps得到。

如果执行SQL>altertablespace …offline命令时采用temporary或 immediate选项，而不用normal选项时，offlinenormalscn会被设成0。这样当数据库重启后通过resetlog方式打开时，该表空间就无法再改回在线状态。

Checkpoint SCN
当数据库内存的脏数据块(dirtyblocks)写到各数据文件中时，就发生一次checkpoint。数据库的当前checkpointscn值存在x$kccdi.discn中。Checkpointscn在数据库恢复中起着至关重要的作用。无论你用何种办法恢复数据库，只有当各个数据库文件的checkpointscn都相同时，数据库才能打开。

虽然参数“_allow_resetlogs_corruption”可以在checkpointscn不一致时强制打开数据库，但是这样的数据库在open后必须马上作全库的export，然后重建数据库并import数据。

Resetlog SCN
数据库不完全恢复时，在指定时间点后的scn都无法再应用到数据库中。Resetlog时的scn就被设成当前数据库scn，redolog也会被重新设置。

Stop SCN
Stop scn记录在数据文件头上。当数据库处在打开状态时，stopscn被设成最大值0xffff.ffffffff。在数据库正常关闭过程中，stopscn被设置成当前系统的最大scn值。在数据库打开过程中，Oracle会比较各文件的stop scn和checkpointscn，如果值不一致，表明数据库先前没有正常关闭，需要做恢复。

High and Low SCN
Oracle的Redo log会顺序纪录数据库的各个变化。一组redolog文件写满后，会自动切换到下一组redo log文件。则上一组redo log的high scn就是下一组redo log的lowscn。
在视图v$log_history中，sequence#代表redolog的序列号，first_change#表示当前redo log的low scn，列next_change#表示当前redolog的high scn。

代码

SQL > col recid format 9999
SQL > col requence# format 9999
SQL > col first_change# format 9 , 999 , 999 , 999 , 999
SQL > col next_change# format 9 , 999 , 999 , 999 , 999
SQL > select recid,sequence#,first_change#,next_change# from v$log_history

where rownum <</SPAN>6;

RECID SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
----- ---------- ------------------------------------
484 484 1,928,645,840,091 1,928,645,840,436
485 485 1,928,645,840,436 1,928,645,840,636
486 486 1,928,645,840,636 1,928,778,045,209
487 487 1,928,778,045,209 1,929,255,480,725
488 488 1,929,255,480,725 1,930,752,214,033

关于如何使用参数_allow_resetlogs_corruption，可参见文档http://www.sidibe.net/allow_resetlog.html

点滴总结：

1，在control file,redo log,datafile中都存在SCN值；
2，数据库open时，检查control file中记录的SCN值与数据文件，redolog文件是否一致，如果是，数据库打开，否则，提示错误；假如数据文件SCN值小于controlfile中的SCN值则提示该数据文件需要介质恢复；
3，redo log中存在低SCN，高SCN值两种，当前的redolog文件的高SCN值为无穷大；日志发生切换时，高SCN值更新为系统当前SCN值，新日志文件低SCN值为前日志文件高SCN值加1，高SCN值仍然为去穷大；数据库发生变化，则写redolog文件，同时SCN值会加1。
4，检查点发生时，CKPT更新数据文件头。