关于checkpoint cnt和checkpoint scn

« 使用DBMS_SUPPORT包 | Blog首页 | Oracle中模拟及修复数据块损坏 »

关于checkpoint cnt和checkpoint scn

作者：eygle |【转载时请以超链接形式标明文章出处和作者信息及本声明】
链接：http://www.eygle.com/archives/2004/06/checkpoint_scn_ckpcnt.html

站内相关文章|Related Articles

自我调整检查点的参数约束

resize datafile 与 checkpoint

DB link与检查点(checkpoint)和SCN

Oracle Fast-Start Fault Recovery选件

Oracle7.3.4 Checkpoint行为研究

通过试验说明checkpoint cnt 和checkpoint scn的关系

1.在不同条件下转储控制文件

SQL> alter session set events 'immediate trace name CONTROLF level 10';

Session altered.

SQL> alter tablespace system begin backup;

Tablespace altered.

SQL> alter session set events 'immediate trace name CONTROLF level 10';

Session altered.

SQL> alter system checkpoint;

System altered.

SQL> alter session set events 'immediate trace name CONTROLF level 10'
2 /

Session altered.

SQL> alter tablespace system end backup;

Tablespace altered.

SQL> alter session set events 'immediate trace name CONTROLF level 10';

Session altered.

notes:

alter session set events 'immediate trace name CONTROLF level 10';

用于转储控制文件.

2.获得以下跟踪文件信息(仅研究system表空间记录,请注意红色部分):

a.正常情况下转储控制文件

***************************************************************************
DATA FILE RECORDS
***************************************************************************
(blkno = 0x6, size = 180, max = 100, in-use = 24, last-recid= 574)
DATA FILE #1:
(name #4) /opt/oracle/oradata/hsjf/system01.dbf
creation size=32000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 04/23/2004 01:20:52
Checkpoint cnt:1567 scn: 0x0000.0148181c 06/22/2004 18:58:46
Stop scn: 0xffff.ffffffff 06/22/2004 18:58:05
Creation Checkpointed at scn: 0x0000.000000ae 07/16/2003 03:40:10
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.013b46fd prev_range: 0
Online Checkpointed at scn: 0x0000.013b46fe 05/28/2004 23:37:17
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED

b.执行Begin backup以后的

我们注意到Checkpoint cnt增加了1，此处触发了一次表空间检查点.

***************************************************************************
DATA FILE RECORDS
***************************************************************************
(blkno = 0x6, size = 180, max = 100, in-use = 24, last-recid= 574)
DATA FILE #1:
(name #4) /opt/oracle/oradata/hsjf/system01.dbf
creation size=32000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 04/23/2004 01:20:52
Checkpoint cnt:1568 scn: 0x0000.01481939 06/22/2004 19:02:22
Stop scn: 0xffff.ffffffff 06/22/2004 18:58:05
Creation Checkpointed at scn: 0x0000.000000ae 07/16/2003 03:40:10
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.013b46fd prev_range: 0
Online Checkpointed at scn: 0x0000.013b46fe 05/28/2004 23:37:17
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED

c.执行手工检查点

我们注意到,此时Checkpoint cnt增加，但是scn不再改变

***************************************************************************
DATA FILE RECORDS
***************************************************************************
(blkno = 0x6, size = 180, max = 100, in-use = 24, last-recid= 574)
DATA FILE #1:
(name #4) /opt/oracle/oradata/hsjf/system01.dbf
creation size=32000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 04/23/2004 01:20:52
Checkpoint cnt:1569 scn: 0x0000.01481939 06/22/2004 19:02:22
Stop scn: 0xffff.ffffffff 06/22/2004 18:58:05
Creation Checkpointed at scn: 0x0000.000000ae 07/16/2003 03:40:10
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.013b46fd prev_range: 0
Online Checkpointed at scn: 0x0000.013b46fe 05/28/2004 23:37:17
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED

d.End backup后的情况

此时数据文件头的冻结被取消,scn开始变化

***************************************************************************
DATA FILE RECORDS
***************************************************************************
(blkno = 0x6, size = 180, max = 100, in-use = 24, last-recid= 574)
DATA FILE #1:
(name #4) /opt/oracle/oradata/hsjf/system01.dbf
creation size=32000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 04/23/2004 01:20:52
Checkpoint cnt:1570 scn: 0x0000.01481941 06/22/2004 19:02:39
Stop scn: 0xffff.ffffffff 06/22/2004 18:58:05
Creation Checkpointed at scn: 0x0000.000000ae 07/16/2003 03:40:10
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.013b46fd prev_range: 0
Online Checkpointed at scn: 0x0000.013b46fe 05/28/2004 23:37:17
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED

Checkpoint cnt用于保证在正常操作中使用的数据文件是当前版本
在恢复时防止恢复数据文件的错误版本.Checkpoint cnt是一直递增的,即使表空间处于热备份模式.

由于表空间的创建时间不尽相同,所以不同表空间/数据文件的Checkpoint cnt通常是不同的.

我们知道:

在数据库open的过程中,Oracle要进行两次检查.

第一次检查数据文件头中的Checkpoint cnt是否与对应控制文件中的Checkpoint cnt一致.
如果相等,进行第二次检查.

第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致
如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.

对每个数据文件都完成检查后,打开数据库.同时将每个数据文件的结束SCN设置为无穷大.

历史上的今天...
>> 2006-06-22文章:

新闻:Oracle将在大连建立全球支持中心

Windows Live Messenger正式版发布

DBA警世录:谨慎操作数据字典

>> 2005-06-22文章:

增加了一个"数据库管理员站点导航"页面

黄山云海观日出

使用Oracle9i的新特性Flashback Query恢复误删除数据

By eygle on 2004-06-22 09:58 | Comments (4) | Posted to Internal | Edit |Pageviews:

相关文章	随机文章
自我调整检查点的参数约束 resize datafile 与 checkpoint DB link与检查点(checkpoint)和SCN Oracle Fast-Start Fault Recovery选件 Oracle7.3.4 Checkpoint行为研究	SPFILE参数修改错误的解决办法 10gRAC系列之五-如何启用归档模式终于解决了MSN - Live Messenger 的性能问题有多少病毒可以再来-记大战7y7.us 瑞典游记-别章-丹麦哥本哈根游记 Part I

搜索本站:

留言 (4)

老大，你的前几行的以下语句
SQL> alter session set events 'immediate trace name CONTROLF level 10';

是不是应该是
SQL> alter session set events 'immediate trace name CONTROLF level 12';

会话已更改。

其中10 应该是12呢？

Posted by: cactus0509 at April 25, 2009 7:25 PM

Level 不同采样跟踪的内容就不同，这里不是错误。

Posted by: eygle at April 26, 2009 10:27 AM

我做了一个实验
alter session set events 'immediate trace name CONTROLF level 10'; 只有在9i下才能用。
在10g下，该命令，产生的日志没有
DATABASE ENTRY条目，也没有 CHECKPOINT PROGRESS RECORDS 条目，
而是：
DUMP OF CONTROL FILES, Seq # 461 = 0x1cd
V10 STYLE FILE HEADER:
Compatibility Vsn = 169869568=0xa200100
Db ID=1349740677=0x50736885, Db Name='MYDBA'
Activation ID=0=0x0
Control Seq=461=0x1cd, File size=430=0x1ae
File Number=0, Blksiz=16384, File Type=1 CONTROL
Logical block number 1 (header block)
Dump of memory from 0x08FF7E00 to 0x08FFBE00
8FF7E00 0000C215 00000001 00000000 04010000 [................]
8FF7E10 0000E9EE 00000000 0A200100 50736885 [.......... ..hsP]
8FF7E20 4244594D 00000041 000001CD 000001AE [MYDBA...........]
8FF7E30 00004000 00010000 00000000 00000000 [.@..............]
8FF7E40 00000000 00000000 00000000 00000000 [................]
。。。。。。

一堆这样的鬼东西

Posted by: cactus0509 at May 2, 2009 4:23 PM

你可以用level 8级别转储。

Posted by: eygle at May 3, 2009 9:20 AM

www.eygle.com

关于checkpoint cnt和checkpoint scn

留言 (4)

发表留言: