关于REDO CKPT 的一点研究

文章是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/