SCN&&CHECKPOINT

==>检查点定义
当用户提交事务,先写日志文件,再写数据文件。
当数据库实例crash时,内存中的Buffer中的数据,没有写入到数据块中;
数据库在重新打开时,需要进行恢复,来恢复Buffer中的数据状态,并确保已经提交的数据被写入到数据块中;
检查点是这个过程中的重要机制,通过它来确定,恢复时哪些重做日志应该被扫描并应用于恢复.

检查点发生后,触发DBWn,CKPT获取发生检查点时对应的SCN,通知DBWn要写到这个SCN为止,DBWR写dirtybuffer是根据Buffer在被首次修改的时候的时间的顺序写出,
也就是Buffer被modify的信息，会进入双向链表的检查点队列,DBWn从队列中批量地写到数据文件。
由于这里有一个顺序的关系,所以DBWn的写的进度被限制,该buffer首次变化时候的scn就是当前所有数据文件块的最新scn,
但是由于无法实时将dbwr的进度记录下来。所以oracle选择了一些策略。其中就包括ckpt进程的检查点。
检查点发生以后,CKPT进程检查checkpointqueue是否过长,如果是,则触发DBWn,将一部分脏块写入数据文件。
checkpoint发生时,一方面通知dbwr进行下一批写操作;另一方面,以3秒的频率将dbwr写的进度反应到控制文件中。即dbwr当前刚写完的dirtybuffer对应的scn写入数据文件头和控制文件,这就是检查点scn。

==>触发条件
从oracle9i开始推出了incremental checkpoint(增量检查点)的机制,来弥补fullthread checkpoint(完全检查点),产生的巨大i/o性能影响，并且oracle引入了双向链表的checkpointqueue机制,每一个脏块会被移到检查点队列里面去,按照lowrdb(第一次对此块修改对应的redoblockaddress)来排列,靠近检查点队列尾端的数据块的lowrba值是最小的,而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变,这样就保证了越早修改的块越早写入磁盘

触发CheckPoint(检查点)条件有很多,比如：
1.通过正常事务处理或正常关闭数据库实例
2.当通过设置初始化参数:
SQL> show parameter log_checkpoint
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_checkpoint_interval              integer     0
log_checkpoint_timeout               integer     1800
强制手段
FAST_START_IO_TARGET；
ALter system checkpoint;
altertablespace...offline;==>offline datafile,不会触发检查点
alter system switch logfile==>将触发完全检查点

==>各种SCN，这里统计的不全
1).SystemCheckpointSCN
当checkpoint完成后,ORACLE将SystemCheckpointSCN号存放在控制文件中。
selectcheckpoint_change#fromv$database;

2)DatafileCheckpointSCN
当一个检查点动作完成之后,Oracle就把每个数据文件的scn单独存放在控制文件中.
我们可以通过下面SQL语句查询所有数据文件的DatafileCheckpoinntSCN号。
selectname,checkpoint_change#fromv$datafile;

3).StartSCN(启动SCN)
checkpoint完成后,将产生的checkpointSCN写入数据文件头(称之为startscn).这个SCN用于检查数据库启动过程是否需要做mediarecovery.
我们可以通过以下SQL语句查询：
selectname,checkpoint_change#fromv$datafile_header;
注意：数据文件头中的检查点SCN(startSCN)与控制文件中记录的数据文件检查点SCN号含义是一样的。
也就是说,一旦发生全局范围以及文件级别的检查点时,不仅会将这时的检查点SCN号记录到控制文件,还会记录在检查点作用的数据文件头部。


4).EndSCN号(stopscn,终止SCN)
每个数据文件在控制文件的记录中都有一个字段叫End SCN。
如果该datafile是offline或read only，该End SCN的值表示对该datafile不会再比这个End SCN更大的重做记录。
如果数据文件是online的并且有一个instance打开database，End SCN是个0xffff.ffffffff值(controlfile里记录的信息)。
这个SCN号用于检查数据库启动过程是否需要做instance recovery.
我们可以通过以下SQL语句查询：
selectname,last_change#fromv$datafile;
在正常的数据库操作过程中,所有正处于联机读写模式下的数据文件的终止scn都为null.

5).TS干净ENDSCN
数据字典TS$有两列表示,表空间干净结束SCN(SCNWRP和SCNBAS组合表示).如在对数据文件发出检查点操作后,数据文件检查点SCN被记录到TS$中作为表空间干净结束SCN。
==>各SCN之间关系
1）数据库运行期间的scn值
在数据库打开并运行之后,控制文件中的系统检查点、控制文件中的数据文件检查点scn和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.

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

3）数据库重启过程中scn作用
在数据库重新启动的时候,Oracle将文件头中的那个启动scn与数据库文件检查点scn(控制文件中)进行比较,
如果这两个值相互匹配,那么不需要MediaRecovery,oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn,
如果这两个值也一致,就意味着所有对数据库的修改都没有在关闭数据库的过程中丢失,因此这次启动数据库的过程也不需要任何恢复操作(即不需要实例恢复),
此时数据库就可以打开了。当所有的数据库都打开之后,存储在控制文件中的数据文件终止scn的值再次被更改为null,这表示数据文件已经打开并能够正常使用了。

还需要注意的是:
在数据库重新启动的时候,Oracle首先比较datafile头中的那个启动scn(startSCN)与控制文件中记录的(每个)数据库文件检查点scn,
如果他们都相互匹配,那么不需要MediaRecovery.但是如果只是控制文件中记录的数据文件检查点(多个数据文件,对应多个SCN),
与(对应的)数据文件头中的启动SCN(startscn)相同,而在每个在线的可读可写的数据文件“之间”,他们的检查点SCN不相同,那么也要求MediaRecovery.

==>为什么需要System checkpoint SCN号与Datafile Checkpoint SCN号
1.对只读表空间,其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。这三个SCN在表空间处于只读期间都将被冻结。

2.如果控制文件不是当前的控制文件,则System checkpoint会小于Start SCN或END SCN号。记录这些SCN号,可以区分控制文件是否是当前的控制文件。
Recovery database using backup controlfile
当有一个StartSCN号超过了SystemCheckpoitSCN号时,则说明控制文件不是当前的控制文件,
因此在做recovery时需要采用using backup controlfile。这是为什么需要记录System Checkpoint SCN的原因之一。

==>重建控制文件,重建方式分两种（resetlogs和noresetlogs）
1.使用resetlogs选项时,SystemCheckpointSCN为被归为0,
而其中记录的各个数据文件的DatafileCheckpointSCN则来自于StartSCN（也就是说可能会从冷备份的数据文件的数据文件头中获取）。
根据上述的描述,此时需要采用usingbackupcontrolfile做recovery.因此情况是SystemCheckpointSCN=0<StartSCN=DatafileCheckpointSCN。

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

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

==>LowSCN与NextSCN
1.在一个事务提交后,会在redolog中存在一条redo记录,同时,系统为其提供一个最新的SCN（通过函数dbms_flashback.get_system_change_number可以知道当前的最新SCN）,记录在该条记录中。如果该条记录是在redolog被清空（日志满做切换时或发生checkpoint时,所有变化日志已经被写入数据文件中）前,则其SCN被记录为redolog的lowSCN。以后在日志再次被清空前写入的redo记录中SCN则成为NextSCN。

2.当日志切换或发生checkpoint时,从LowSCN到NextSCN之间的所有redo记录的数据就被DBWn进程写入数据文件中,
而CKPT进程则将所有数据文件（无论redolog中的数据是否影响到该数据文件）的文件头上记录的StartSCN(通过视图v$datafile_header的字段checkpoint_change#可以查询)更新为NextSCN,
同时将控制文件中的System Checkpoint SCN（通过视图v$database的字段checkpoint_change#可以查询）、
每个数据文件对应的Datafile Checkpoint（通过视图v$datafile的字段checkpoint_change#可以查询）也更新为NextSCN。
但是,如果该数据文件所在的表空间被设置为read-only时,数据文件的StartSCN和控制文件中DatafileCheckpointSCN都不会被更新。




===========================
相关交流信息
QQ群: 330218614
Email: 623009431@qq.com
Blog: http://blog.csdn.net/trsenzhang
============================