oracle检查点系列：checkpoint小议

oracle检查点系列：checkpoint小议

一：什么是checkpoint?IXPUB技术博客;_OLC8Dp1g
checkpoint是一个数据库事件，它将已修改的数据从高速缓存刷新到磁盘，并更新控制文件和数据文件。IXPUB技术博客 BFi4I_Ji7Ip

f2jL8mop^sw0二：什么时候发生checkpoint?IXPUB技术博客\Y-rGF!Z
我们知道了checkpoint会刷新脏数据，但什么时候会发生checkpoint呢？以下几种情况会触发checkpoint。
2z_k8v1GE I01.当发生日志组切换的时候IXPUB技术博客7EPt%k{y
l
2.当符合LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target参数设置的时候
|T,dfUW0IXDBA.NET技术社区IXPUB技术博客{j}+rx-w&W4o ax5B
3.当运行ALTER SYSTEM SWITCH LOGFILE的时候IXPUB技术博客-c\2w%y|U,e
4.当运行ALTER SYSTEM CHECKPOINT的时候
'x4r*Gz-L%o05.当运行alter tablespace XXX begin backup，end backup的时候
Pp"p1H,}z?06.当运行alter tablespace ,datafile offline的时候;IXPUB技术博客pEpRNY


CE ^W1br+w \0三：增量检查点（incremental checkpoint）
:V.?:H3lX!RP P1{8yW0oracle8以后推出了incremental checkpoint的机制，在以前的版本里每次checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘，巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了checkpoint queue机制，每一个脏块会被移到检查点队列里面去，按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。

增量检查点并不去更新数据文件头，只是在控制文件中记录了checkpoint progress record这个区域，记下low rba,on-disk rba等信息。这些信息就可以用来快速恢复。IXPUB技术博客+rk5q
sM%F

 IXPUB技术博客IN0K5Sve

（解释）每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。IXPUB技术博客9WQE;VcL/}
     这里应该是只更新控制文件，每3秒不是更新数据文件，记录checkpoint的执行情况，这个说法，没错，但不够详细，应该说，由于增量检查点和checkpoint  queue的原理，ckpt进程每次只是告诉dbwr，写dirty  buffer将要一直写到最新这个位置，仅仅是告诉dbwr一个checkpoint queue  中的结束点，而ckpt每3秒钟，在控制文件中报告一下dbwr最新写入的位置。这样使得，比如数据库要做恢复的时候（instance  recovery）可以从这个最新位置开始做恢复，而不是从数据文件中的checkpoint  scn开始做恢复，这样将缩短恢复时间，尤其是instance  crash的情况下启动更快。IXPUB技术博客 _t.~+R @ ?
另外要注意的是，检查点发生的时候，ckpt去更新数据文件头和控制文件，并不是把当前检查点发生时候的scn更新进去，而是把上一次dbwr写入已经完成的检查点发生时候的  scn更新进去，也就是说，更新控制文件和数据文件头是滞后于检查点的发生的，这个从恢复的原理也很容易理解，因为检查点发生的时候dirty buffer还没有写入，自然不能立即更新成当前的scn了。IXPUB技术博客,p~6{^)k#Z`

6E3~'n-YH$z,t3K WDs0四：数据字典

:Q)q#{3u] Q4G@I0完全检查点IXPUB技术博客e^ ]&hj?u
select * from X$KCCRT where indx=0;IXPUB技术博客+R5AN1Z3Y
IXPUB技术博客'~1lW.F'Y
ADDR           INDX    INST_ID      RTNUM      RTSTA RTCKP_SCN        RTCKP_TIM             RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO RTCKP_RBA_BOF RTCKP_ETB         RTOTF      RTOTB      RTNLF      RTLFH      RTLFT      RTCLN      RTSEQ RTENB            RTETS    RTDIS            RTDIT                     RTLHP RTSID            RTOTSIXPUB技术博客0w r d @\&w
-------- ---------- ---------- ---------- ---------- ---------------- -- -------------------- ---------- ---------------- --------------------IXPUB技术博客2] u4E.B'e7o:JC9v&^
4084B228          0          1          1         15 720368521        06/25/2004 18:49:37           1           949             2     16 0600000000000000          2          0          3          1          3          1        949 1                05/16/2004 13:29:03  0                                               1389 tbdb2in1         06/12/2004 12:30:50
.G_4L,WtGi4KUT+[T3_0
0X0gr8Ek[I0这里显示了上一次的完全检查点是在06/25/2004 18:49:37发生，所以我们推断06/25/2004 18:49:37发生了一次日志切换，再去操作系统上去看生产的归档，果然18：49有一个归档生产。
6Uu1K0tGcN;^{1u/CI3gA0-rw-r-----    1 oracle   oinstall 83532800 Jun 25 18:49 1_948.dbfIXPUB技术博客'NFQ1nULNG xb*s

;?1a `1[I0IXPUB技术博客'd0IW
k$Cy
增量检查点IXPUB技术博客8b4I8@7s\EY0G
SQL> select * from X$KCCCP where indx=0;
3vR%gq4oVv0IXPUB技术博客J^1K\'}td.@p
ADDR           INDX    INST_ID      CPTNO      CPSTA      CPFLG      CPDRT      CPRDB CPLRBA_SEQ CPLRBA_BNO CPLRBA_BOF  CPODR_SEQ  CPODR_BNO  CPODR_BOF CPODS                CPODT                   CPODT_I      CPHBT CPRLS                 CPRLC      CPMID  CPSDR_SEQ  CPSDR_BNO  CPSDR_ADBIXPUB技术博客)I(M,?#lv(b-y
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------IXPUB技术博客Np`pn$q$?
4084B45C          0          1          1          2          0      10762      29753        949      76847          0        949     106814              0 721554970        06/25/2004 21:05:10   529794310  529036227 1                 526310932 1413781667        949              1          0IXPUB技术博客
da+B_5m\v3^E
IXPUB技术博客,r`'P uVV#b
这里显示了low-rba,on-disk rba,checkpoint time等信息。IXPUB技术博客F!r9_|f*L8VB

 IXPUB技术博客|4OBQA2}(cqv

 IXPUB技术博客 c3yp"W(y8XN

案例分析：IXPUB技术博客_:?;UUvT0Y'zF$O

各位前辈，看到此章，非常有感，，，IXPUB技术博客'A8y`0W,Y;|l
但有一事请各位帮忙，我们单位现在数据库老是有时快，有时慢，是不是跟这个有关系。我该从哪方面开始查！IXPUB技术博客8gO5?8W"Q({Pd^z kL

答：不能肯定是他拉，你慢是指什么意思？是不是同一个语句有时慢有时快吗，如果是这样，那要结合你的statspack来分析，一般来说每个应用都有高峰期和低峰期，看你慢的时候，你的事务量是不是很高（可以在这段时间增加statspack的频率），load的情况如何，是不是有什么耗资源的应用定期在跑（找出这些语句，需要优化他），每秒的重做量是不是很高。io的使用情况，是不是有很多序列读等待还是序列写等待，来合理优化索引IXPUB技术博客P1Y}3y)^W
  你说的检查点是不是是一个可能的原因，当然有可能，如果没有合理的设置log_buffer大小，logfile放在读写比较差的磁盘上，检查点的频繁程度，合理设置fsfr_start_mttr_target,看看在statspack中存在下面的等待事件
S]}*H,~!s0IXPUB技术博客mxxz0[
1.log file switch(archiving needed)IXPUB技术博客D d!k#n6`4w b,\!k4f
  
^.zQBp9G0日志切换的时候由于日志组循环使用了一圈但日志归档还没有完成，通常是io有严重问题，
b$\ r%A z1w0  可增大日志文件和增加日志组，调整log_archive_max_processesIXPUB技术博客5P)]8|/h&]
  (checkpoint incomplete)
*F}xUT9{3N0  
5sD%{%uj-E@2J0当日志切换的时候由于日志组循环使用了一圈但将被使用的日志组中的checkpoint还没有完成造成，
8?)i1gLQo$Ms#M4Q$?0  通常是io有严重问题，可增大日志文件和增加日志组IXPUB技术博客2E$X pF#svl6n+`
2.log file sync(这个到可能是log_buffer太大的反作用)
l+w/y)F^B.v!srQcD0  IXPUB技术博客y^s4A8Kb:Q,Yh
当用户commit的时候通知lgwr写日志但lwgr正忙，造成的可能原因是commit太频繁或者lgwr一次写日志时间太长
{O5TZ%Y OM8m0（可能是因为一次log io size太大），可调整_log_io_size，IXPUB技术博客p5s*m2C-y7C
  结合log_buffer,使得(_log_io_size*db_block_size)*n =IXPUB技术博客Y1s \%D5H3p3g0j \
log_buffer,这样可避免和增大log_buffer引起冲突;
};y!}c1WrR0  放置日志文件于高速磁盘上
nQ ~;U+f9B`0
egx1eI1`03.log file single write
X HMbP/[0m%~vQk S0  指出写入到日志文件的标题块.可能表示检查点中等待IXPUB技术博客aA/TEKT

#{%os3XU5TiNw3G1T04.另外dbwr写是不是存在瓶径
,L3OOBB:e5~5F0cache buffers lru chain  是否需要增加
,VH!QtKa0需要异步IO吗还是增加从dbwrIXPUB技术博客+H]od,}7Z

问一下，上面说了ckpt每隔3秒只是更新了控制文件的checkpoint progress record这个区域，那么它是什么时候进行数据文件更新的？当更新了控制文件后，正在更新数据文件时，掉电，会出现什么样的情况呢？

答：数据文件是有dbwr来写的，跟ckpt并没有实质关系。更新控制文件是在更新数据文件之后的动作，所以不用担心，这个时候断电会从上次的ckpt点开始恢复。