关于日志切换和检查点的疑惑！！！！！

kevindream0509

原帖由 Yong Huang 于 2009-7-5 04:21 发表


Thanks for the correction. When I wrote that, I had in my mind two concepts "fast vs slow checkpoint" (which determines checkpoint priority) and "complete vs incremental checkpoint" (which is about whether to write *all* buffers on the checkpoint queue). I searched on Metalink and Google and realized the first concept is old, used in Oracle 8 or older, and it seems to be the same as the second one. That is, there's only one concept, not two independent "orthogonal" concepts. Oracle just quietly renamed fast to complete and slow to incremental. The renaming is a good move, because it's really not about speed, but about how much the checkpoint queue is processed.

With that understanding, I pulled my book from the shelf, "Oracle8 Backup and Recovery Handbook" by Rama Velpuri, published in 1998. On p.244, three's a table listing all types of checkpoints. Since this book is hard to find and there's no ebook version, let me summarize here (some post-Oracle8 concepts are not listed of course):

These checkpoints are fast: alter system checkpoint (local or global), alter tablespace begin backup or offline (normal, temporary), instance shutdown (normal, immediate), log file switch stuck.

These checkpoints are slow: alter system switch logfile, log file switch normal, checkpoint due to log_checkpoint_(timeout|interval).

So is the checkpoint triggered by a logfile switch complete or incremental? According to Rama's book, normally it is incremental, consistent with what you said. It only becomes complete when the switch gets stuck, which Rama clearly explains in a paragraph, as in the case where you only have 2 small logfiles and Oracle can't switch to the other file because checkpoint of that old one is still being checkpointed.

Yong Huang

WOW. Thanks for your reply. I got it!

kevindream0509

原帖由 Yong Huang 于 2009-7-5 04:36 发表


According to Steve Adams' research (http://www.ixora.com.au/q+a/0008/30140320.htm), _db_block_write_batch was replaced by _db_writer_chunk_writes, probably not by a simple parameter renaming, but by some concept change as well. Do you think it's still tunable? If you have any reference, please list it.

Yong Huang

You are right. _db_block_write_batch was replaced by _db_writer_chunk_writes, For the parameter _db_block_chunk_batch ,I have no idea about it...

flying_warrior

原帖由 Yong Huang 于 2009-7-5 04:36 发表


According to Steve Adams' research (http://www.ixora.com.au/q+a/0008/30140320.htm), _db_block_write_batch was replaced by _db_writer_chunk_writes, probably not by a simple parameter renaming, but by some concept change as well. Do you think it's still tunable? If you have any reference, please list it.

Yong Huang

Hey guys ,I'm back~~

for my word   "DBWR max outstanding writes  equals  _db_block_buffers     "   


I'm try to decrease _db_block_buffers  , and I did it ....   it's 2048 now

by the way  it is a realy  damn it hard work~~

and the DBWR max outstanding writes is decrease to 2048 now~~and the "DBWR write chunk" is 102..

but This is something entirely new ,when the _db_block_buffers   outnumber of 4096 the "DBWR max outstanding writes  " is not increase any more,

it very strange and interesting~~~ i have no idea about it, may be some one else limited it~

so i think "_db_block_write_batch " is replaced by "DBWR max outstanding writes"  in 10G  and it's not replaced by " _db_writer_chunk_writes"
because in the section  of IXORA 's document =>"mystery.doc" ->"Tuning the Write Batch Size Limit" it said
"  The DBWR batch size limit is controlled by the _DB_BLOCK_WRITE_BATCH parameter. The value of this parameter is derived from other parameters, and can be seen in X$KVII"

select
  kviidsc,
  kviival
from
  sys.x$kvii
where
  kviitag in (’kcbswc’, ’kcbscc’)
/

KVIIDSC                    KVIIVAL
-------------------------- -------
DB writer IO clump             100
DB writer checkpoint clump       8

but now the ’kcbswc’ is "DBWR max outstanding writes"
and ’kcbscc’ is disappeared

soi think "DBWR max outstanding writes"  is entirly instead of "DB writer IO clump and DB writer checkpoint clump "  →consult my test before..

and by the way  

原帖由 kevindream0509 于 2009-7-4 11:53 发表
oracle 8i以后 完全检查点只有在alter system checkpoint 以及非shutdown abort之外的正常关闭数据库的情况下才会触发
而增量检查点每隔三秒钟以及日志切换时启动
增量检查点是根据检查点队列将脏数据写到数据文件中，检查点队列中所挂载的脏数据buffer header链表是按数据块第一次被修改的时间先后顺序实现的。在控制文件中每隔三秒中，也就是俗称检查点的“心跳”，找出当前检查点队列上的第一个buffer header，并将该buffer header中所记录的LRBA（这个LRBA也就是checkpoint position了）记录到控制文件中去。buffer header除了记录LRBA之外如果是日志切换引发的增量检查点，还会将checkpoint position记录到每个数据文件头中。当一批脏数据块写完之后，就会将其对应的buffer header从检查点队列中摘下。
因此，对于Yong Huang的Indeed they're different.这句话表示赞同，但是后面一句But I don't think you can say the second case (触发的) is incremental. It's still complete表示疑问。
如果想法有不对之处，请多多请教。。。

首先 我不认为log switch checkpoint equals increament checkpoint
因为LOG SWITCH 时不会触发INCREAMENT CHECKPOINT 并且 2种检查点并非完全一致 LOG SWITCH 只会将RBA 推进到新文件的第2个BLOCK的第10字节
而增量RBA 则是会推进至不同的块位
个人认为   LOG SWITCH 是另一种专门用来推进 LOG BUFFER 中的RBA至新文件头的CHECKPOINT AND 条件下激发COMPLETE CHECKPOINT的一种检查点 并非是增量检查点也并非是完全检查点

另外，我也没有发现每三秒一次增量检查点触发的情形，如果实验证明 请指明 谢谢~~

Yong Huang

> 首先 我不认为log switch checkpoint equals increament checkpoint
> 因为LOG SWITCH 时不会触发INCREAMENT CHECKPOINT 并且 2种检查点并非完全一致 LOG SWITCH
> 只会将RBA 推进到新文件的第2个BLOCK的第10字节
> 而增量RBA 则是会推进至不同的块位

Interesting. Do you have any reference for that? Or your own test?

> 个人认为   LOG SWITCH 是另一种专门用来推进 LOG BUFFER 中的RBA至新文件头的CHECKPOINT AND 条件下激发COMPLETE
> CHECKPOINT的一种检查点 并非是增量检查点也并非是完全检查点

Did you omit a word (and possibly a punctuation mark) after "AND"? I have a hard time to follow your grammar.

> 另外，我也没有发现每三秒一次增量检查点触发的情形，如果实验证明 请指明 谢谢~~

When kevindream0509 says incremental checkpoint occurs at the heartbeat of once per 3 seconds, he doesn't mean there must be a checkpoint every 3 seconds. I think what he means is that if there're dirty buffers that should be checkpointed, they'll be checkpointed at the moment of the 3 second heartbeat. If there's no data change, of course there's no checkpoint at all.

Yong Huang

flying_warrior

原帖由 Yong Huang 于 2009-7-6 22:34 发表
> 首先 我不认为log switch checkpoint equals increament checkpoint
> 因为LOG SWITCH 时不会触发INCREAMENT CHECKPOINT 并且 2种检查点并非完全一致 LOG SWITCH
> 只会将RBA 推进到新文件的第2个BLOCK的第10字节
> 而增量RBA 则是会推进至不同的块位

Interesting. Do you have any reference for that? Or your own test?
首先当TRACE LOG CHECKPOINT的时候 我们会发现每次LOG SWITCH 只会将RBA增进到0x36.2.10
这也就是我推测LOG SWTICH CHECKPOINT<>INCREMNET CHECKPOINT的起点；
接着向下看当我发动LOG SWITCH  命令时，ALERT.LOG中记录


Beginning log switch checkpoint up to RBA [0x25.2.10], SCN: 775856
Thread 1 advanced to log sequence 37
  Current log# 3 seq# 37 mem# 0: F:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG

此时我的RBA向0x25.2.10推进
这时DUMP controlfile 发现
THREAD #1 - status:0x2 flags:0x0 dirty:41
low cache rba0x24.b28e.0) on disk rba0x25.2.0)
on disk scn: 0x0000.000bd6b0 07/06/2009 23:13:20
此时的LRBA并未被推进至新文件的头。之后即使增进了一次RBA 也依旧是0X24的。所以我认为这2个检查点并非相同。



> 个人认为   LOG SWITCH 是另一种专门用来推进 LOG BUFFER 中的RBA至新文件头的CHECKPOINT AND 条件下激发COMPLETE
> CHECKPOINT的一种检查点 并非是增量检查点也并非是完全检查点

Did you omit a word (and possibly a punctuation mark) after "AND"? I have a hard time to follow your grammar.

哦 漏词了……  其实我想说的是，LOG SWITCH CHECKPOINT 是用来增进RBA的文件号的CHECKPOINT
并且在全日志处于ACTIVE的情况下用来触发完全检查点的一种检查点。
后来经过一片文章http://www.click2earth.com/post/74.html 觉得似乎 日志文件序号的更改并非是由LOG SWITCH CHECKPOINT 来实现的，
从上面的实验可以得出 1次日志切换检查点发生后 又发生了增量检查点。可是增量检查点的日志序号并没有改变。
这也就否定了我的想法。
同时参考上面链接文章中的一段

日志切换触发的是normal checkpoint，而不是大家所说的增量checkpoint，只不过log switch checkpoint的优先级非常低，当一个log switch checkpoint发生的时候它并不会立即的通知DBWn进程去写数据文件，但是当有其它原因导致checkpoint或者是写入数据文件的RBA超过log switch checkpoint的checkpoint RBA的时候，这次的log switch checkpoint将会被标记成完成状态，同时更新控制文件和数据文件头.
这样看起来 日志切换 仅仅是更新了控制文件和数据文件头，而不能直接影响到LOG BUFFER写出增量检查点时的文件序号。

> 另外，我也没有发现每三秒一次增量检查点触发的情形，如果实验证明 请指明 谢谢~~

When kevindream0509 says incremental checkpoint occurs at the heartbeat of once per 3 seconds, he doesn't mean there must be a checkpoint every 3 seconds. I think what he means is that if there're dirty buffers that should be checkpointed, they'll be checkpointed at the moment of the 3 second heartbeat. If there's no data change, of course there's no checkpoint at all.

Yong Huang

借着这次试验，我确实可以否定不是3秒一次，或者依据heartbeat
THREAD #1 - status:0x2 flags:0x0 dirty:21
low cache rba0x25.278.0) on disk rba0x25.2fd.0)
on disk scn: 0x0000.000bd9e9 07/06/2009 23:33:23
resetlogs scn: 0x0000.0008297b 07/01/2009 01:18:24
heartbeat: 691541292

THREAD #1 - status:0x2 flags:0x0 dirty:26
low cache rba0x25.278.0) on disk rba0x25.304.0)
on disk scn: 0x0000.000bd9f5 07/06/2009 23:33:43
resetlogs scn: 0x0000.0008297b 07/01/2009 01:18:24
heartbeat: 691541305

DIRTY 增加了，HEARTBEAT 增加了，时间也增加了 但是Low cache rba 没有增加。

lsq_008

学习了

天淋降

来看一下