注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Oracle专业打杂

定会重回巅峰……

 
 
 

日志

 
 

SCN和CHECKPOINT  

2014-02-06 09:48:05|  分类: oracle |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
============================================
===================SCN和CHECKPOINT================
============================================
关于Oracle SCN,常有两种叫法:一种是系统改变号(System Change Number),另一种是系统提交号(System Commit Number)。从狭义上讲,事务的提交和回滚是引起SCN值递增的主要原因,但引起SCN值的操作还有很多,如延迟块的清理等。
  Oracle SCN的作用主要有:
    1)一致性读
    2)保证事务的唯一性
    3)物理备份恢复机制贵重根据判断点
timestamp_to_scn、scn_to_timestamp用于在SCN和系统时间之间进行转换。
控制文件中的SCN很多,最重要的有3类:数据库SCN、数据文件SCN和checkpoint progress record中的SCN。
  1)数据库SCN通常表示最近一次全量CHECKPOINT操作时的SCN,可以查询V$Database获取该SCN,如下所示:
    SQL>select checkpoint_change# from v$database;
    2)数据文件SCN,可以通过v$datafile查询保存在控制文件中的数据文件SCN,该SCN主要有以下三种形式。
      数据文件头。该SCN是判断控制文件和数据文件是否一致的标准之一。可以通过v$datafile.checkpoint_change# 查询。
      STOP SCN。该SCN在数据库处于打开状态或者异常关闭时为无穷大,即OXFFFF.FFFFFFFF。如果数据库正常关闭,则和v$datafile.checkpoint_change#值相同。可以通过v$datafile.last_change#查询。
      CRETION SCN。表示数据文件创建时的SCN,可以通过v$datafile.creation_change#查询。

CHECKPOINT PROGRESS RECORDS中的ON DISK SCN表示当前系统最新RBA对应的SCN,由CKPT进程每3秒更新一次.如果数据库异常宕机,那么CRASH RECOVER时服务器进程至少要应用到该SCN为止.当系统比较空闲时,CHECKPOINT PROGRESS RECORDS信息能比较精确地反映数据库的运行状态.

数据文件头中的SCN,值可以从v$datafile_header中查询,主要分为以下4类:
  1)CREATION_CHANGE#表示数据文件创建时的SCN,该值也保存在控制文件中.
  2)CHECKPOINT_CHANGE#表示数据文件头当前的SCN,该值也保存在控制文件中.
  3)RESETLOGS_CHANGE#表示数据库以RESETLOGS方式打开时的SCN.
   4)CHANGE#表示数据文件头冻结时的SCN.

日志文件头中的SCN v$log_history
  1)FIRST_CHANGE#表示该在线日志文件被重用时的SCN.
  2)NEXT_CHANGE#表示该日志文件重用结束时的SCN.
  3)RESETLOGS_CHANGE#表示数据库以RESETLOGS方式打开时的SCN.

CHECKPOINT是数据库的一个内部动作,这个动作由CKPT进程发引,它的主要作用如下:
  1)在数据文件头和控制文件中记录SCN值,作为数据库中恢复的起点,在更新数据文件头期间,数据文件冻结,数据文件越多,CHECKPOINT的成本越高.
  2)调用DBWR(Database Writer)进程将脏块安全地写入数据文件中,从而腾出更多的BUFFER CACHE空间给其他数据块使用.
  3)减少数据库异常宕机之后的CRASH RECOVER时间,这是最根本的目的.

Oracle引进CHECKPOINT的根本目的就是减少未写进数据文件的脏块数量,加快数据库异常宕机后的启动速度.

全量CHECKPOINT和增量CHECKPOINT对用户都是透明的,而增量CHECKPOINT只不过是将全量CHECKPOINT要写的脏块分时间分批次写到数据文件中而已,此操作可以极大地减少对数据库性能的影响.

当显式设置FAST_START_MTTR_TARGET为某个非0值时,Oracle开启自动增量CHECKPOINT.反之,DBWR进程写脏块的频率降低,数据库异常宕机后的恢复时间可能会延迟.

当Oracle发起一个事务需要更改数据时,如果所涉及的数据快不在BUFFER CACHE中,那么Oracle服务进程先会将相关数据快从数据文件中读进BUFFER CACHE进行更改(直接路径读除外),更改后的数据快被称为脏快(DIRTY BLOCK).当事物提交或者回滚时,基于性能上的考虑,脏块并不会立刻写至数据文件中,而是LGWR进程优先将脏块的信息写至ONLINE REDOLOG,只有当LGWR进程返回写成功之后,事务才算提交成功.这就是Oracle为了保证不丢数据的"日志优先写"原则.

"日志优先写"原则带来的问题就是当数据库异常宕机时,可能会仍有部分块在BUFFER CACHE的脏缓冲区列表中,并没有写进数据文件.所以在启动数据库时,首先会由服务器进程进行实例恢复(CRASH RECOVER,又叫前滚)即服务器进程扫描ONLINE REDOLOG,在BUFFER CACHE中重构未写进数据文件的脏块信息之后,会通知DBWR进程将脏块写进数据文件中.

============================================
=====================END====================
============================================
  评论这张
 
阅读(110)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017