Oracle SCN与检查点详解
1.SCN的定义
SCN(SystemChangeNumber),也就是通常所说的系统改变号,是数据库中非常重要的一个数据结构。
SCN用以标识数据库在某个确切时刻提交的版本。在事务提交时,它被赋予一个惟一的标识事务的SCN。SCN同时被作为Oracle数据库的内部时钟机制,可被看作逻辑时钟,每个数据库都有一个全局的SCN生成器。
作为数据库内部的逻辑时钟,数据库事务依SCN而排序,Oracle也依据SCN来实现一致性读(ReadConsistency)等重要数据库功能。另外对于分布式事务(DistributedTransactions),SCN也极为重要,这里不作更多介绍。
SCN在数据库中是惟一的,并随时间而增加,但是可能并不连贯。除非重建数据库,SCN的值永远不会被重置为0。
一直以来,对于SCN有很多争议,很多人认为SCN是指SystemCommitNumber,而通常SCN在提交时才变化,所以很多时候,这两个名词经常在文档中反复出现。即使在Oracle的官方文档中,SCN也常以SystemChange/CommitNumber两种形式出现。到底是哪个词其实不是最重要的,重要的是需要知道SCN是Oracle内部的时钟机制,Oracle通过SCN来维护数据库的一致性,并通过SCN实施Oracle至关重要的恢复机制。SCN在数据库中是无处不在的,常见的事务表、控制文件、数据文件头、日志文件、数据块头等都记录有SCN值。
冠以不同前缀,SCN也有了不同的名称,如检查点SCN(CheckpointSCN)、ResetlogsSCN等。
2.SCN的获取方式
可以通过如下几种方式获得数据库的当前或近似SCN。
SQL>SELECTdbms_flashback.get_system_change_numberFROMDUAL; GET_SYSTEM_CHANGE_NUMBER ------------------------ 6051905241299 SQL>
3.SCN的进一步说明
系统当前SCN并不是在任何的数据库操作发生时都会改变,SCN通常在事务提交或回滚时改变。在控制文件、数据文件头、数据块、日志文件头、日志文件changevector中都有SCN,但其作用各不相同。
(1)数据文件头中包含了该数据文件的CheckpointSCN,表示该数据文件最近一次执行检查点操作时的SCN。
对于每一个数据文件都包含一个这样的条目,记录该文件的检查点SCN的值以及检查点发生的时间,这里的CheckpointSCN、StopSCN以及CheckpointCnt都是非常重要的数据结构.
4.检查点
许多文档把Checkpoint描述得非常复杂,为我们正确理解检查点带来了障碍,结果现在检查点变成了一个非常复杂的问题。实际上,检查点只是一个数据库事件,它存在的根本意义在于减少崩溃恢复(CrashRecovery)时间。
当修改数据时,需要首先将数据读入内存中(BufferCache),修改数据的同时,Oracle会记录重做信息(Redo)用于恢复。因为有了重做信息的存在,Oracle不需要在提交时立即将变化的数据写回磁盘(立即写的效率会很低),重做(Redo)的存在也正是为了在数据库崩溃之后,数据可以恢复。
最常见的情况,数据库可能因为断电而Crash,那么内存中修改过的、尚未写入文件的数据将会丢失。在下一次数据库启动之后,Oracle可以通过重做日志(Redo)进行事务重演(也就是进行前滚),将数据库恢复到崩溃之前的状态,然后数据库可以打开提供使用,之后Oracle可以将未提交的事务进行回滚。
在这个过程中,通常大家最关心的是数据库要经历多久才能打开。也就是需要读取多少重做日志才能完成前滚。当然用户希望这个时间越短越好,Oracle也正是通过各种手段在不断优化这个过程,缩短恢复时间。
检查点的存在就是为了缩短这个恢复时间。
当检查点发生时(此时的SCN被称为CheckpointSCN),Oracle会通知DBWR进程,把修改过的数据,也就是此CheckpointSCN之前的脏数据(DirtyData)从BufferCache写入磁盘,当写入完成之后,CKPT进程更新控制文件和数据文件头,记录检查点信息,标识变更。
CheckpointSCN可以从数据库中查询得到:
SQL>selectfile#,NAME,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,'yyyy-mm-ddhh24:mi:ss')CPTfromv$datafile; FILE#NAMECHECKPOINT_CHANGE#CPT -------------------------------------------------------------------------------------------------------------------------------- 1/u01/app/oracle/oradata/orcl/system01.dbf60519052399952016-05-0504:14:32 2/u01/app/oracle/oradata/orcl/sysaux01.dbf60519052399952016-05-0504:14:32 3/u01/app/oracle/oradata/orcl/undotbs01.dbf60519052399952016-05-0504:14:32 4/u01/app/oracle/oradata/orcl/users01.dbf60519052399952016-05-0504:14:32 5/u01/app/oracle/oradata/orcl/example01.dbf60519052399952016-05-0504:14:32 6/u01/app/oracle/oradata/orcl/DEV_odi_user.dbf60519052399952016-05-0504:14:32 7/u01/app/oracle/oradata/orcl/apex_01.dbf60519052399952016-05-0504:14:32 8/u01/app/oracle/oradata/orcl/APEX_6121090681146232.dbf60519052399952016-05-0504:14:32 8rowsselected
在检查点完成之后,此检查点之前修改过的数据都已经写回磁盘,重做日志文件中的相应重做记录对于崩溃/实例恢复不再有用。
检查点的频度对于数据库的恢复时间具有极大的影响,如果检查点的频率高,那么恢复时需要应用的重做日志就相对得少,恢复时间就可以缩短。然而,需要注意的是,数据库内部操作的相关性极强,过于频繁的检查点同样会带来性能问题,尤其是更新频繁的数据库。所以数据库的优化是一个系统工程,不能草率。
更进一步可以知道,如果Oracle可以在性能允许的情况下,使得检查点的SCN逐渐逼近Redo的最新变更,那么最终可以获得一个最佳平衡点,使得Oracle可以最大化的减少恢复时间。
为了实现这个目标,Oracle在不同版本中一直在改进检查点的算法。
总结
以上就是本文关于OracleSCN与检查点详解的全部内容,希望对大家有所帮助。感兴趣的朋友可以参考:oracle数据库启动阶段分析 、OracleEBS工具选项:关闭其他表单修改方法 、 oracle虚拟专用数据库详细介绍 等。有什么问题可以随时留言,小编会及时回复大家的。