你所不知道的DBWR----DBWR工作原理简述

digdeep126

有几个地方没有看懂，特请教：
1>dirty buffers inspected如果持续升高，物理读、CR块构造性能一定会受影响。
    这个结论怎么理解？ 该值升高，表示脏块持续增多，物理写增多？
2>从“LRUW写的脏块数”和“检查点写的脏块数”的比值，这个指标差，dirty buffers inspected会很高
    这个结论又如何理解？另外文中没有涉及检查点如何写的内容。

gszoracle

digdeep126 发表于 2012-12-9 14:13
有几个地方没有看懂，特请教：
1>dirty buffers inspected如果持续升高，物理读、CR块构造性能一定会受影响 ...

前面我也提问了vage目前可能没空

gszoracle

digdeep126 发表于 2012-12-9 14:13
有几个地方没有看懂，特请教：
1>dirty buffers inspected如果持续升高，物理读、CR块构造性能一定会受影响 ...

我来说说我的理解。
第一个问：在buffer中寻找空闲块时发现脏块，会把脏块及Checkpoint队列中该脏块前面的脏块移到LURW队列中，后通知DBWR进程写数据文件，写后腾出原来来被脏块所占据的内存供数据库服务使用。被移动的块数累加到计数器中。这些被写入的数据块其实还未提交，它不应该被其他任务看到修改后的值（状态）,如果有其他任务需要读取这些块的数据，Oracle必须一致性读的原则从undo表空间读取前镜像。此外尚未提交的数据块被再次读写的概率极高，他已经被刷出buffer，降低了命中率，若再次读写势必带来更多的IO。
该值增多，意味着数据库中数据不是正常按照检查点规划正常写入数据文件，而是经常出现很多临时紧急的情况需要把数据应急写入文件。会带来额外的IO开消。
正确与否，待各位批评。

vage

gszoracle 发表于 2012-12-9 16:24
我来说说我的理解。
第一个问：在buffer中寻找空闲块时发现脏块，会把脏块及Checkpoint队列中该脏块前面 ...

我想的没这么复杂，
什么样的操作会从LRU中找可重用Buffer，也就物理读和生成CR块。
如果脏块多，dirty buffers inspected高，也就是查找脏块时，跳过的脏块也多。
跳过脏块数达到一定数量，Server进程就要移动脏块到LRUW。
这些操作，都增加了“从LRU中找可重用Buffer”这个操作的时间，所以dirty buffers inspected持续升高，一定会影响物理读和生成CR块。

vage

digdeep126 发表于 2012-12-9 14:13
有几个地方没有看懂，特请教：
1>dirty buffers inspected如果持续升高，物理读、CR块构造性能一定会受影响 ...

什么样的操作会从LRU中找可重用Buffer，也就物理读和生成CR块。
如果脏块多，dirty buffers inspected高，也就是查找脏块时，跳过的脏块也多。
跳过脏块数达到一定数量，Server进程就要移动脏块到LRUW。
这些操作，都增加了“从LRU中找可重用Buffer”这个操作的时间，所以dirty buffers inspected持续升高，一定会影响物理读和生成CR块。

检查点如何写？有啊：
在增量检查点机制中，DBWR触发写操作时，会将脏块从检查点队列移至各个对象的脏对象链表中，在脏对象链表中按块的文件号、块号排序，就可以找到连续的块。
这种算法的确很巧妙，如果将所有脏块一起排序，参与排序的块太多，耗用内存太大，而且有可能影响性能。而不同对象的块，相邻的可能很低，将块按对象分门别类，再排序，的确是个好方法。
根据DUMP结果，块在检查点队列时，状态为obj-flags: object_ckpt_list，当要写脏块时，状态为：obj-flags: object_write_list，同时objq的链表位置有变化。

奈门摩尔

占个位置，买包瓜子，坐等版主大大更新！

digdeep126

vage 发表于 2012-12-9 07:29
是先产生Redo，再修改块，再申请检查点队列Latch，将块链接到检查点队列，然后修改块结束。

既然这样，那我可不可推断：在修改buffer block，产生脏块的事务中，已经将该脏块插入到了检查点队列。进一步推断：所有的buffer cache中的脏块必然进入到检查点队列。

既然这样，那么：
1> LRUW中的脏块来源有几个？只有检查点队列一个来源吗？
2> 脏块是先插入到检查点队列，还是先插入到LRUW？您的结论似乎说：脏块先插入到检查点队列，然后从检查点队列移到LRUW，或者从检查点移到objq。可以这样理解您的结论吗？
3> 如果上面我说的第二点是对的，那么脏块的运动轨迹似乎可以分为两种：     1. update语句导致的所有脏块进入检查点队列 ===>> 增量检查点事件发现ckpt-q很长，于是导致脏块移到obj-q ===>>  然后合并batch，写磁盘 ===>> buffer block变成clean 回到LRU-AUX； 这种方式写的脏块数目，就是“从增量检查点写的脏块数量”。
     2. server process扫描LRU，发现脏块，注意此时该脏块一定在ckpt-q上，于是将ckpt-q上该脏块附近的一些LRBA小的脏块移到LRUW ===>> 然后又移到到LRUW-AUX ===>> 然后再移到obj-q ===>> 然后合并batch，写磁盘。 这种方式写的脏块数目，就是“从LRUW写的脏块数量”。

我的推断是正确的吗？
还有一点：

“是先产生Redo，再修改块，再申请检查点队列Latch，将块链接到检查点队列，然后修改块结束。”
——那么将脏块链接到检查点队列，此时脏块并没有从LRU上摘除吗？因为如果从LRU上摘除了的话，那么server process扫描LRU的时候，就不会发现其上还有脏块了。

希望我的表达，是足够清晰的。

ludal

3、块何时进入检查点队列：当块变脏的时候。


这一点我有异议，瓦鸡，块变脏时候不一定是在灰色链表，在lru链表上，如果块变成dirty了，马上进去检查点队里，是不是rollback操作时候 脏块也会从checkpoint queue里移除，还是只是打上标记为可用？

jym2002

顶个

vage

digdeep126 发表于 2012-12-10 11:10
既然这样，那我可不可推断：在修改buffer block，产生脏块的事务中，已经将该脏块插入到了检查点队列。进 ...

3> 如果上面我说的第二点是对的，那么脏块的运动轨迹似乎可以分为两种：     1. update语句导致的所有脏块进入检查点队列 ===>> 增量检查点事件发现ckpt-q很长，于是导致脏块移到obj-q ===>>  然后合并batch，写磁盘 ===>> buffer block变成clean 回到LRU-AUX； 这种方式写的脏块数目，就是“从增量检查点写的脏块数量”。

大部分是对的，

1. update语句导致的所有脏块进入检查点队列 ===>> 增量检查点事件发现ckpt-q很长，于是导致脏块移到obj-q ===>>  然后合并batch，写磁盘 ===>> buffer block变成clean，到这里，并没有 回到LRU-AUX；这个操作，从检查点队列写，不会改变块在LRU中的位置。 这种方式写的脏块数目，就是“从增量检查点写的脏块数量”。


“是先产生Redo，再修改块，再申请检查点队列Latch，将块链接到检查点队列，然后修改块结束。”
——那么将脏块链接到检查点队列，此时脏块并没有从LRU上摘除吗？因为如果从LRU上摘除了的话，那么server process扫描LRU的时候，就不会发现其上还有脏块了。

是的，脏块同时在LRU和检查点队列。