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

cqubityj

原帖由 hanson 于 2008-3-12 23:11 发表


这应该是增量检查点。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号日志文件里去。

1、能否把你看到的oracle官方教材的内容发一下看看。
2、我想讨论问题的是“手工切换日志是增量检查点还是完全检查点”，至于切换日志会产生检查点这一点是确定无疑的。
3、我刚才看了一下checkpoint instructors.ppt,上面说产生完全检查点有两个条件：
a. alter system checkpoint   b.shutdown(except abort)
按照他这个结论来看，手工切换日志确实也是增量检查点。看来是我的理解有些偏差。

solearn

原帖由 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写了，以前的日志就可以重用了。

我分析在你假设的情况下，90% logfile=0.9K。当手工切换时，最小的日志文件应该等于其归档日志大小。因为这个规则的目的在于（引用）：The checkpoint position will never lag the end of the log data by more than one log file。

手工switch不即时写 可以体现在：
当执行alter system switch logfile后，在alter 文件中马上可以看到：Beginning log switch checkpoint up to RBA [0x1c39.2.10]之类的提示，在短时间后可以看到Completed checkpoint up to RBA [0x1c38.2.10]，但Completed checkpoint up to RBA [0x1c39.2.10]则很久也看不到。这说明drwr没有即刻把up to RBA [0x1c39.2.10]的数据块写出，它仍然遵守之前的写出规则。

cqubityj

原帖由 solearn 于 2008-3-13 09:39 发表


我分析在你假设的情况下，90% logfile=0.9K。当手工切换时，最小的日志文件应该等于其归档日志大小。因为这个规则的目的在于（引用）：The checkpoint position will never lag the end of the log data by more than one log file。

手工switch不即时写 可以体现在：
当执行alter system switch logfile后，在alter 文件中马上可以看到：Beginning log switch checkpoint up to RBA [0x1c39.2.10]之类的提示，在短时间后可以看到Completed checkpoint up to RBA [0x1c38.2.10]，但Completed checkpoint up to RBA [0x1c39.2.10]则很久也看不到。这说明drwr没有即刻把up to RBA [0x1c39.2.10]的数据块写出，它仍然遵守之前的写出规则。

你这个说法我还是有疑问。因为我什么时候去手工切换日志数据库是不可能预测的。假如我在A日志写了1K的时候手工切换，如果是按照90% logfile=0.9K，那么在0.9K时就该触发dbwr写了。而这个1K是在我切换的时候数据库才知道的，这时不是已经晚了吗。假设我是在2k的时候切换的，那么不是就要90% logfile=1.8K了。我觉得不太可能是这样的。

komman

还在讨论啊.....精神可嘉

solearn

原帖由 cqubityj 于 2008-3-13 10:12 发表


你这个说法我还是有疑问。因为我什么时候去手工切换日志数据库是不可能预测的。假如我在A日志写了1K的时候手工切换，如果是按照90% logfile=0.9K，那么在0.9K时就该触发dbwr写了。而这个1K是在我切换的时候数据库才知道的，这时不是已经晚了吗。假设我是在2k的时候切换的，那么不是就要90% logfile=1.8K了。我觉得不太可能是这样的。

其实这个说法我也有疑问。我也是猜测：当命令发出后，oracle 才知道这个文件的 大小是1K，才确定了新的target rba从而促使dbwr去写。如果不这样假设，我找不到一个理由来解释上面所说在alert文件里看到的现象（我也没有找到相关资料）。

yywudong

感谢晶晶小妹的指正，
   还有楼上各位对checkpoint的相关讨论，让我又学了不少。但alter system switch logfile到底产生的是不是增量检查点？希望能提供较有说服力的资料，先谢了。
还有一个问题alter system switch logfile与alter system checkpoint 产生的检查点是一样的吗？

hanson

原帖由 yywudong 于 2008-3-14 08:39 发表
感谢晶晶小妹的指正，
   还有楼上各位对checkpoint的相关讨论，让我又学了不少。但alter system switch logfile到底产生的是不是增量检查点？希望能提供较有说服力的资料，先谢了。
还有一个问题alter system switch logfile与alter system checkpoint 产生的检查点是一样的吗？

官方教材的 9i DBA II 第7章 18页
已经明确指出full checkpoint发生的时机：
·SHUTDOWN NORMAL, IMMEDIATE, or TRANSACTIONAL
·ALTER SYSTEM CHECKPOINT

反推导，其他的都不属于full checkpoint。

前面已经讲到如何做试验来验证它了。就是你将checkpoint跟踪到alert.log文件里。然后进行日志切换，你会发现日志切换引起的checkpoint的时间完成很长，从而导致将checkpoint not complete记录到alert.log里。这就是因为增量检查点的优先级较低导致。

烟囱

刚看到这么精彩的话题,学习了.

yywudong

更新了一下，请大家多多赐教。