文章是WORD 拷贝上来的 可能有些乱 可以参见原件http://www.namipan.com/d/REDO%20Research%2003.doc/c0614a0b20c896d9ae7895fa62ae15c4a503cada009e0000
纳米盘的下载链接
首先 这个文章的主题是讨论REDO 的CHECK POINT。或者说都有什么样的CHECK POINT 什么时候触发。
今天论坛的人提到 为什么自己在ALTER SYSTEM SWITCH LOGFILE 和ALTER SYSTEM CHECKPOINT的时候REDO文件的状态不一致呢?当SWITCH之后 之前CURRENT的文件会变成ACTIVE 而 当发布了CHECKPOINT 之后就变成了INACTIVE?
听说目前 有INCREMENT CHECKPOINT 和COMPLETE CHECKPOINT;那么这两种情况分别都属于什么类型的CHECKPOINT 呢?还有没有另外的CHECKPOINT之说呢?
今天我们就来扯一下关于REDO的check point 类型。
首先我们都知道 CHECK POINT的作用都是为了减轻CRASH时候的恢复工作,当CHECK POINT发生时DBWR将数据刷至硬盘 所以当我们在T1时间做了一个CHECKPOINT又在T2 CRASH了,那么当恢复的时候只需要应用T1-T2之间的REDO即可。因为之前的修改已近被写入了硬盘,这样会大大减少重做的工作量。
那么接着讨论REDO 的CHECK POINT类型
首先介绍一个参数log_checkpoints_to_alert 当设置为TRUE的时候 便会把CHECK POINT的变动写到ALTER文件当中,也就让我们对REDO的CHECK POINT 有迹象可寻。
首先第一句话
Thu Jun 25 21:19:09 2009
Incremental checkpoint up to RBA [0x34.f350.0], current log tail at RBA [0x34.f599.0]
第一个Incremental checkpoint 讲的是增量检查点,这个是ORACLE 8 新引入的机制,每一个脏数据块都会记录在检查点队列,按照LOW RBA(REDO BYTE ADDRESS)分配,无论数据如何修改他在队列中的顺序不会被改变,DBWR 按照LRBA的顺序从DRITY LIST中写出,同时CKPT进程也在不断地更新控制文件头中的LRBA(揣测跟CHECK POINT原理差不多,恢复的时候只需要根据LRBA之后的数据重做即可,如果连REDO都没写出……那么数据肯定也是没写出不需要恢复了……)
下面就来观测一下……
alter session set events 'immediate trace name controlf level 10;
THREAD #1 - status:0x2 flags:0x0 dirty:52
low cache rba:(0x34.f374.0) on disk rba:(0x34.f5cb.0)
on disk scn: 0x0000.001a973b 06/25/2009 21:22:05
可惜此时已经比发布INCREMENTAL检查点的时候晚了3分钟了…… 因为CKPT进程在偷偷更新控制文件头中的LRBA信息 所以我们看到的要比当时的CHECKPOINT时间要大得多;但是还没有刷至检查点队列的尾
ONDISK 是指当前写至的RBA ,这样当CRASH的时候只需要定位 LRBA 和ON DISK RBA之间的重做信息就可以重做当时的情况了 跟COMPLETE CHECKPOINT 同理。
接下来 看看如何触发COMPLETE CHECKPOINT;
就像我们知道的~ REDO 的刷新条件 每1/3 满,COMMIT 或满1M 将REDO 写至硬盘。
那么另外还有 当DBWN需要强制写出的时候 也需要先写出REDO 然后再写出DATABUFFER
1是 DBWR在寻找LRU LIST上的空闲空间时会将脏数据块写出,此时会激发REDO(推测是RBA)
2 是LRU LIST 的DRITY BUFFER 达到阀值的时候 也会把他写出;(默认25%)(此时会激发COMPLETE CHECK POINT);
试验
select * from v$datafile
CHECKPOINT TIME
2009-6-25 22:00:36;
create table test tablespace test as select * from dba_objects
INSERT INTO TEST SELECT * FROM DBA_OBJECTS 反复10次;变成一张大表
紧接着 UPDATE TABEL TEST SET OBJECT_ID=1;
查看LOG
Thu Jun 25 22:14:57 2009
Beginning log switch checkpoint up to RBA [0x36.2.10], SCN: 1753558
Thread 1 advanced to log sequence 54
Current log# 2 seq# 54 mem# 0: F:\ORACLE\PRODUCT\10.2.0\ORADATA\SHCATALOG\REDO02.LOG
Current log# 2 seq# 54 mem# 1: F:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\REDOLOG002
Beginning log switch checkpoint up to RBA [0x37.2.10], SCN: 1758352
Thread 1 advanced to log sequence 55
Current log# 1 seq# 55 mem# 0: F:\ORACLE\PRODUCT\10.2.0\ORADATA\SHCATALOG\REDO01.LOG
Current log# 1 seq# 55 mem# 1: F:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\REDOLOG001
Thu Jun 25 22:15:06 2009
Completed checkpoint up to RBA [0x36.2.10], SCN: 1753558
Thu Jun 25 22:15:07 2009
Beginning log switch checkpoint up to RBA [0x38.2.10], SCN: 1763793
Thread 1 advanced to log sequence 56
Current log# 3 seq# 56 mem# 0: F:\ORACLE\PRODUCT\10.2.0\ORADATA\SHCATALOG\REDO03.LOG
Current log# 3 seq# 56 mem# 1: F:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\REDOLOG003
Thu Jun 25 22:15:13 2009
Completed checkpoint up to RBA [0x37.2.10], SCN: 1758352
Thu Jun 25 22:15:15 2009
Beginning log switch checkpoint up to RBA [0x39.2.10], SCN: 1769674
Thread 1 advanced to log sequence 57
Current log# 2 seq# 57 mem# 0: F:\ORACLE\PRODUCT\10.2.0\ORADATA\SHCATALOG\REDO02.LOG
Current log# 2 seq# 57 mem# 1: F:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\REDOLOG002
Thu Jun 25 22:15:22 2009
Completed checkpoint up to RBA [0x38.2.10], SCN: 1763793
Thu Jun 25 22:15:23 2009
Beginning log switch checkpoint up to RBA [0x3a.2.10], SCN: 1773676
Thread 1 advanced to log sequence 58
Current log# 1 seq# 58 mem# 0: F:\ORACLE\PRODUCT\10.2.0\ORADATA\SHCATALOG\REDO01.LOG
Current log# 1 seq# 58 mem# 1: F:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\REDOLOG001
截止至此,一共做了4次LOG SWITCH CHECKPOINT 和3次complete checkpoint ;
Select * from v$datafile
Checkpoint chage ,checkpoint time
1763793 2009-6-25 22:15:07
但是一个很有趣的问题是 出现了一个叫做 log switch checkpoint的CHECK POINT 这个到底是什么东东呢? LOG SWITCH? 干嘛用的?
Completed checkpoint up to RBA [0x38.2.10], SCN: 1763793
Thu Jun 25 22:15:23 2009
Beginning log switch checkpoint up to RBA [0x3a.2.10], SCN: 1773676
Thread 1 advanced to log sequence 58
Current log# 1 seq# 58 mem# 0: F:\ORACLE\PRODUCT\10.2.0\ORADATA\SHCATALOG\REDO01.LOG
Current log# 1 seq# 58 mem# 1: F:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\REDOLOG001
Thu Jun 25 22:19:11 2009
Incremental checkpoint up to RBA [0x38.e243.0], current log tail at RBA [0x3a.a9b6.0]
Thu Jun 25 22:20:21 2009
Completed checkpoint up to RBA [0x39.2.10], SCN: 1769674
Completed checkpoint up to RBA [0x3a.2.10], SCN: 1773676
仔细查看 不难发现 LOG SWITCH 和Incremental checkpoint 的RBA 并非是一样的
这个LOG SWITCH时应该更新的是数据文件头和CONTROLE FILE指出当前使用的是哪个LOG 而 Incremental checkpoint check point 只是更新控制文件说明重做从何处开始.
alter session set events 'immediate trace name file_hdrs level 10';
Tablespace #8 - TEST rel_fn:7
Creation at scn: 0x0000.00128751 06/19/2009 23:46:28
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x29243a5f scn: 0x0000.00164079 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
prev reset logs count:0x2915d943 scn: 0x0000.0008297b prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
recovered at 06/25/2009 20:04:31
status:0x4 root dba:0x00000000 chkpt cnt: 154 ctl cnt:153
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.001b106c 06/25/2009 22:15:23
thread:1 rba:(0x3a.2.10)
也就是说当重做发生时 SMON 会根据数据文件头定位的REDO文件序号和控制文件中的RDBA来定位从哪个REDO的那个块开始进行重做。
小弟亦是一厢推测,如有哪位大大有更明确的定论 希望能够告知。
Flying_warrior
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/21818314/viewspace-607577/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/21818314/viewspace-607577/