如何知道incremental checkpoint的进度

本帖最后由 kevin.zhang 于 2010-11-26 17:42 编辑

增量检查点,一个很重要的概念,能够理解了还是对更好的理解oracle有很大帮助。
其实oracle就是这样,单独一个概念都不难,难得是和其它组件和概念结合在一起共同运作,然后在自己脑海中推演,
对他们建立起完美的逻辑体系。
本文转自dbsnake.com。
原帖地址:
http://dbsnake.com/2010/11/inc-ckpt-frequency.html
回复中有dbsnake(cui hua) 大师对我的指点,有兴趣的也可以去看下,下面是引用:


如何知道incremental checkpoint的进度By cui hua on November 19, 2010 3:15 PM | 8 Comments

有朋友问我:"incremental checkpoint似乎看不见,摸不着,我怎么知道我系统里incremental checkpoint发生的频率呢,或者说我如何才能知道incremental checkpoint的进度?"
首先要说明的是,什么是incremental checkpoint
These disjointed activities
of writing buffers in ascending low RBA order and periodically recording the lowest low RBA in the control file constitute incremental checkpoint
注意这里理解incremental checkpoint最为关键的地方就是上述我标明的两个单词----disjointed activities
接着我们来说上述问题的答案:
Oracle里有一个内存结构X$KCBBES,以indx4的条件去查询上述结构,列reason的值就是当前系统的number of db block buffers written to the disk for incremental checkpoint,换句话说,这就可以用来衡量严格意义上的incremental checkpoint的进度
X$KCBBES = [K]ernel [C]ache [B]uffer Management Buffer Event Statistics
Column

Type

Comments

------------------

------

---------------

ADDR
RAW(4)

Address

INDX

NUMBER
Reason / Priority / Savecode number

INST_ID

NUMBER
Instance id

REASON
NUMBER
Count of buffers written for this REASON

PRIORITY
NUMBER
Count of buffers written at this PRIORITY

SAVECODE
NUMBER
Count of occurrences of return to write buffers
indx的具体含义为:
KCBB_INVALID

0
invalid reason
KCBB_PING

1
Ping write
KCBB_HIPR_CKPT

2
High priority thread checkpoint
KCBB_IRCV_CKPT

3
Instance recovery checkpoint
KCBB_MDPR_CKPT

4
Medium priority thread checkpoint
                                  (typically due to incremental checkpoint)
KCBB_AGING

5
Aging writes
KCBB_MRCV_CKPT

6
Media recovery checkpoint
KCBB_LOPR_CKPT


7
Low priority thread checkpoint
KCBB_TBSP_CKPT

8
Tablespace checkpoint
KCBB_REUSE_OBJ

9
Reuse
object
KCBB_REUSE_RNG
10
Reuse block range
KCBB_DBUF_LMT

11
Limit dirty buffers
我们看一个实际的例子,如下的这个系统中午大家都吃饭去了,很闲,还没有达到触发DBWn进程写dirty buffer的条件,所以Checkpoint Queue上的Checkpoint Position(即low cache RBA)在一段时间内始终没有发生变化:
11:49:52 SQL> select indx,reason from x$kcbbes where indx=4;

INDX
REASON
---------- ----------

4
4404345
11:52:44 SQL> select indx,reason from x$kcbbes where indx=4;

INDX
REASON
---------- ----------

4

4404345
11:56:46 SQL> select indx,reason from x$kcbbes where indx=4;

INDX
REASON
---------- ----------

4
4404345
12:08:33 SQL> select indx,reason from x$kcbbes where indx=4;

INDX
REASON
---------- ----------

4
4404345
即此时的incremental checkpoint虽然也在不停的发生,但从严格意义上说,并不能算真正的incremental checkpoint,因为只是CKPT进程每隔3秒去更新一下control文件(记录下low cache RBA),DBWn进程始终没有写Checkpoint Queue上的dirty buffer(所以low cache RBA没有变化)。
下午1点半,大家吃完饭回来了,开始干活了,真正意义上的incremental checkpoint一下子变得频繁起来:
13:31:17 SQL> select indx,reason from x$kcbbes where indx=4;

INDX
REASON
---------- ----------

4
4404345
13:35:22 SQL> select indx,reason from x$kcbbes where indx=4;

INDX
REASON
---------- ----------

4
4404580
13:38:37 SQL> select indx,reason from x$kcbbes where indx=4;

INDX
REASON
---------- ----------

4
4404583
13:42:15 SQL> select indx,reason from x$kcbbes where indx=4;

INDX
REASON
---------- ----------

4
4409684



标签: 暂无标签
kevin.zhang

写了 32 篇文章,拥有财富 308,被 10 人关注

转播转播 分享分享 分享淘帖
回复

使用道具

成为第一个吐槽的人

您需要登录后才可以回帖 登录 | 加入社区

本版积分规则

意见
反馈