假如log file switch没有产生checkpoint,会产生什么情况?

cqubityj

手工执行alter system switch logfile应该是完全检查点，会写出dirty块。

晶晶小妹

再补充一点，日志切换的时候一定会产生检查点．

solearn

原帖由 solearn 于 2008-3-12 14:14 发表


fly_bug说的对，结果就是crash recovery不能实现。

推翻自己的想法了。
在有增量检查点的情况下，log file switch的作用只是更新控制文件和数据文件头。

solearn

原帖由 cqubityj 于 2008-3-12 14:46 发表
手工执行alter system switch logfile应该是完全检查点，会写出dirty块。

我觉得alter system switch logfile时仍然是增量检查点。

可以看到，当执行这一命令时，在alert文件中很快会看到complete checkpoint的提示。不过我认为，这是由target rba规则决定的。即，target rba和检查点队列末端之间的距离应小于最小日志文件的90%。

fly_bug

原帖由 solearn 于 2008-3-12 16:51 发表


推翻自己的想法了。
在有增量检查点的情况下，log file switch的作用只是更新控制文件和数据文件头。

log file switch虽然是触发增量检查点，但我觉得还是有它特殊的地方，也就是必须保证被覆盖的redo log 对应的数据块已经被写入数据文件。

棉花糖ONE

原帖由 fly_bug 于 2008-3-12 17:03 发表

log file switch虽然是触发增量检查点，但我觉得还是有它特殊的地方，也就是必须保证被覆盖的redo log 对应的数据块已经被写入数据文件。

cqubityj

原帖由 fly_bug 于 2008-3-12 17:03 发表

log file switch虽然是触发增量检查点，但我觉得还是有它特殊的地方，也就是必须保证被覆盖的redo log 对应的数据块已经被写入数据文件。

这个应该是由　“target rba和检查点队列末端之间的距离应小于最小日志文件的90%”　来保证的。

cqubityj

原帖由 solearn 于 2008-3-12 16:56 发表


我觉得alter system switch logfile时仍然是增量检查点。

可以看到，当执行这一命令时，在alert文件中很快会看到complete checkpoint的提示。不过我认为，这是由target rba规则决定的。即，target rba和检查点队列末端之间的距离应小于最小日志文件的90%。

如果alter system switch logfile也是增量检查点的话，会有问题。考虑一下频繁手工切换日志情况：
先假设手工切换日志也是增量检查点，即dbwr不一定写出dirty块。
有两个在线日志A和B，假设都是100M，当前正在写的日志是A并且A只写1ｋ。同时假设检查点队列的开始RBA这时也在A中。这时手工切换日志，当前日志变成B。B写了1k后，我马上又切换日志，这时就需要重用A了。如果在这期间没有触发dbwr去写dirty块的话，那么就无法重用A了。这时检查点队列中的内容只有2K，肯定小于100M＊0.9。所以target rba规则在这段时间内是不能触发dbwr写的。
而如果手工切换是完全检查点的话，就没这个问题了。切换时就触发dbwr写了，以前的日志就可以重用了。

fly_bug

原帖由 cqubityj 于 2008-3-12 17:59 发表


如果alter system switch logfile也是增量检查点的话，会有问题。考虑一下频繁手工切换日志情况：
先假设手工切换日志也是增量检查点，即dbwr不一定写出dirty块。
有两个在线日志A和B，假设都是100M，当前正在写的日志是A并且A只写1ｋ。同时假设检查点队列的开始RBA这时也在A中。这时手工切换日志，当前日志变成B。B写了1k后，我马上又切换日志，这时就需要重用A了。如果在这期间没有触发dbwr去写dirty块的话，那么就无法重用A了。这时检查点队列中的内容只有2K，肯定小于100M＊0.9。所以target rba规则在这段时间内是不能触发dbwr写的。
而如果手工切换是完全检查点的话，就没这个问题了。切换时就触发dbwr写了，以前的日志就可以重用了。

[ 本帖最后由 fly_bug 于 2008-3-12 22:26 编辑 ]

hanson

原帖由 cqubityj 于 2008-3-12 17:59 发表


如果alter system switch logfile也是增量检查点的话，会有问题。考虑一下频繁手工切换日志情况：
先假设手工切换日志也是增量检查点，即dbwr不一定写出dirty块。
有两个在线日志A和B，假设都是100M，当前正在写的日志是A并且A只写1ｋ。同时假设检查点队列的开始RBA这时也在A中。这时手工切换日志，当前日志变成B。B写了1k后，我马上又切换日志，这时就需要重用A了。如果在这期间没有触发dbwr去写dirty块的话，那么就无法重用A了。这时检查点队列中的内容只有2K，肯定小于100M＊0.9。所以target rba规则在这段时间内是不能触发dbwr写的。
而如果手工切换是完全检查点的话，就没这个问题了。切换时就触发dbwr写了，以前的日志就可以重用了。

这应该是增量检查点。oracle官方教材上已经说明白的。
你可以将log_checkpoints_to_alert设置为true，然后不对数据库进行任何的操作，而仅仅是尝试进行日志切换，然后检查alert.log，你会发现检查点完成的时间会很长，从而甚至导致出现Checkpoint not complete。这就是因为增量检查点优先级较低导致的。如果是完全检查点，它的优先级是最高的，不会导致Checkpoint not complete的出现。

如果日志切换不进行增量检查点，那想象一下，当前数据库里一个脏块也没有，同时fast_start_mttr_target也设置的很大。
目前数据库里有2组日志文件，它们全是空的，没有redo entry。
然后我修改一条记录，并提交，从而在1号日志文件里产生了redo。然后手工进行日志切换到2号日志文件，然后再次手工切换到1号日志文件。如果不发生检查点，也就是没有将checkpoint queue上第一个脏块所对应的LRBA作为CKPT Position而写入控制文件，那oracle如何知道这时1号日志文件里包含的redo所对应的脏块还没有写入数据文件呢？它也没有办法知道是否应该覆盖1号日志文件。因此一旦发生日志切换，就必须触发检查点，从而将checkpoint Position放入到1号日志文件里去。