“三个钟”的故事:假设一个公司只有三个员工,每个员工有自己的一个钟。该公司规定,每天早晨8:30上班。有一天,非常不幸,三个员工的钟的时间各不相同,在没有其他外部因素的帮助下,他们无法确定当前的确切时间,他们无法上班,该公司无法正常的OPEN
像任何一家公司一样,不同的员工具有不同的技能专长,负责不同的工作,但是一个成功的项目,需要一个优秀的项目经理,来保持,督促项目中的成员各自工作步调相互一致。在Oracle
在这篇文章当中,我们将详细,深入的讨论检查点和检查点进程的作用。
注:这篇文章主要参考Http://www.AskGuoYu.com
大多数关系型数据库都采用“在提交时并不强迫针对数据块的修改完成”而是“提交时保证修改记录(以重做日志的形式)写入日志文件”的机制,来获得性能的优势。这句话的另外一种描述是:当用户提交事务,写数据文件是“异步”的,写日志文件是“同步”的。这就可能导致数据库实例崩溃时,内存中的DB_Buffer
检查点和检查点进程的操作的三个步骤:
A、系统触发一个检查点,系统并记录该检查点时刻的Checkpoint SCN
B、该Checkpoint RBA
C、完成2步骤后,CKPT
只有上面三个步骤完成,才表示系统的检查点已经被推进,推进了日志文件,数据文件,控制文件到一个新的“同步点”。
检查点只发生在下列情形:
管理员使用:Alter system checkpoint
实例被正常的关闭;
特别注意:日志切换并不导致一个完全检查点的发生。
如何确定哪些DB_Buffer中的数据块需要被写到磁盘上,是一个蛮复杂的算法。大致思想就是:所有dirty data按照Low RBA
二、触发的条件
这里需要明白两个概念“完全检查点和增量检查点”的区别。
增量检查点(incremental checkpoint)
oracle8以后推出了incremental checkpoint的机制,在以前的版本里每checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘,巨大的i/o对系统性能带来很大影响。为了解决这个问题,oracle引入了checkpoint queue机制,每一个脏块会被移到检查点队列里面去,按照low rdb(第一次对此块修改对应的redo block address)来排列,靠近检查点队列尾端的数据块的low rba值是最小的,而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变,这样就保证了越早修改的块越早写入磁盘。每隔3秒钟ckpt会去更新控制文件和数据文件,记录checkpoint执行的情况。
在运行的Oracle
需要说明的是,alter system switch logfile也将触发完全检查点的发生。
alter database datafile ... offline不会触发检查点进程。
如果是单纯的offline datafile,那么将不会触发文件检查点,只有针对offline tablespace的时候才会触发文件检查点,这也是为什么online datafile需要media recovery而online tablespace不需要。
对于表空间的offline后再online这种情况,最好做个强制的checkpoint比较好。
上面几种情况,将触发完全检查点,促使DBWR
另外,一般正常运行期间的数据库不会产生完全检查点,下面很多事件将导致增量检查点,比如:
在联机热备份数据文件前,要求该数据文件中被修改的块从DB_Buffer
l
l
l
等命令都会触发增量检查点。
三、检查点位置的影响因素
相比传统检查点(也就是指那些有明确含义的检查点)
文件的“异步机制”的同步,我们感兴趣的内容终究要归结到:系统崩溃时,“异步的距离”将需要系统多少时间来进行恢复?事实上,Oracle
A、FAST_START_MTTR_TARGET
我们都希望当实例崩溃后,恢复需要读取的日志流尽可能的短,恢复需要的时间尽可能的短。这样,我们会将FAST_START_MTTR_TARGET
难以说明设置FAST_START_MTTR_TARGET
数据库在“事务”当中发生变化,Oraccle
我们知道,当应用程序提交(Commit)某个事务时,先是日志写入进程(LGWR)将Log Buffer
检查点出现,将推动检查点时刻前的日志文件中所参考的数据块的修改,已经被DBWR
可以看出,检查点的出现,可以让数据库在运行时,“定期”的维护日志文件,数据文件进行状态一致性。有些类似于我们生活中:不同的公司定期的账目结清,当一个检查点完成后,大家都承认,这个时间之前的一切账目已经结清。