谢谢老大，我脑子里的思路又亮堂了许多

QUOTE:

---

最初由 Ian 发布
data block里面不是也有SCN吗？和文件头里面的SCN有什么关系？什么时候被更新？代表的是是什么含义？

---

data  block 里面的SCN是当 block 被更改的时候的 SCN
而数据文件有那么多 block，自然不同的 block有不同的 SCN
block中存在 block  SCN  和 ITL 中的commit SCN

block SCN 又在块头和块位都有，若不一致意味着block损坏（热碑可能出现这个情况，需要从redo  log中拷贝回来，若是正在修改的过程中由于进程死掉则 pmon负责清理。若 由于一些以外发生这样的不一致的情况，则查询的时候出现 1578 错误，当然该错误号也可能是 物理磁盘损坏，这里表示逻辑的损坏！）这个头和尾的 SCN 的检查时机跟这两个参数有关：
db_block_checking                    boolean FALSE
db_block_checksum                    boolean FALSE

该2参数信息请查阅 http://tahiti.oracle.com

而ITL 中的 commit  SCN 则跟 consistent gets  and  delay  block  cleanout 有关


数据文件头的 SCN 是检查点发生时更新的
代表着 当  恢复的时候从这个 SCN 点 开始在 log  file 中寻找 redo 开始做恢复

接触Oracle没多久 SCN一直觉得很棘手 看了biti写的领悟了很多东西 想谈谈自己的看法不对之处望请指正 谢谢
1.不论事务有无提交redo中的SCN都会加1，Oracle是通过“提交记录”来断定此事务是否已经提交（uncommit的没提交记录）以便回滚。
2.control中有三种SCN分别为，“system SCN”“datafile SCN”“last SCN”。数据文件头中有一种SCN“start SCN”。当Oracle启动时数据文件头中的SCN（也就是start SCN）会先和datafile SCN比较再和last SCN比较。当系统正常运行时last SCN始终为0,datafile SCN start SCN和system SCN同步。当系统干净关闭时last SCN被置为和datafile SCN start SCN相等。当系统下次启动时，start SCN和datafile SCN比较时候，若start SCN<datafile SCN则说明datafile"老",若start SCN>datafile SCN则说明控制文件"老".start SCN=datafile SCN时则比较start SCN和last SCN,若发现last SCN为0则要求"实例恢复"/"崩溃恢复".system SCN的存在或许是因为"脱机表空间"和"只读表空间"吧,因为其数据文件对应的datafile SCN被冻结(有点不太肯定).

QUOTE:

---

最初由 biti_rainy 发布

检查点的发生，跟写日志文件是没有必然联系的
检查点通知 DBWR 写数据文件，写完后ckpt更新控制文件头和数据文件头

---

According to Rama Velpuri's book, CKPT updates controlfiles, not their headers. It makes sense because if you look at a controlfile dump, the header doesn't even have an SCN. But the file body has sections for each datafile, and therefore each of them has an SCN to be updated.

It's odd that most books and also documentation don't even say CKPT updates controlfiles.

Follow-up to bellsz's original message. In controlfiles, the stop SCN is not a very big number; it's in fact set to infinity when the database is open. Also, SCNs are incremented for many reasons, mostly due to recursive transactions. Read Steve Adams and Hemant Chitale's answers at
http://groups.google.com/groups? ... ngnet_nospam.com.sg

Yong Huang

QUOTE:

---

最初由 Yong Huang 发布


According to Rama Velpuri's book, CKPT updates controlfiles, not their headers. It makes sense because if you look at a controlfile dump, the header doesn't even have an SCN. But the file body has sections for each datafile, and therefore each of them has an SCN to be updated.

It's odd that most books and also documentation don't even say CKPT updates controlfiles.

Follow-up to bellsz's original message. In controlfiles, the stop SCN is not a very big number; it's in fact set to infinity when the database is open. Also, SCNs are incremented for many reasons, mostly due to recursive transactions. Read Steve Adams and Hemant Chitale's answers at
http://groups.google.com/groups? ... ngnet_nospam.com.sg

Yong Huang

---

thanks ,笔误  
应该是 检查点更新 数据文件头 和   控制文件 ，在不同的场合总是有时会犯这样的错误

控制文件中记录了 所有数据文件的状态信息  和 control_file_record_keep_time   天以内的日志文件的信息


In controlfiles, the stop SCN is not a very big number; it's in fact set to infinity when the database is open
---------------   可以说无穷，也可以说 very  very  big  number ,i  think
实际上数据库打开的时候，把 stop SCN 置为  0x FFFF.FFFFFFFF  而已

DATA FILE #1:
  (name #8) E:\ORACLE\ORADATA\RAINY\SYSTEM01.DBF
creation size=0 block size=8192 status=0xe head=8 tail=8 dup=1
tablespace 0, index=6 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:90 scn: 0x0000.005adc16 08/19/2003 16:40:30
Stop scn: 0xffff.ffffffff 08/18/2003 18:43:36
Creation Checkpointed at scn:  0x0000.0000000b 05/12/2002 16:17:58


***************************************************************************
LOG FILE RECORDS
***************************************************************************
(blkno = 0x15, size = 72, max = 64, in-use = 3, last-recid= 6)
LOG FILE #1:
  (name #3) E:\ORACLE\ORADATA\RAINY\REDO01.LOG
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x32000 seq: 0x00000007 hws: 0x1 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.005ac70f
Low scn: 0x0000.005adc16 08/19/2003 16:40:30
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #2:
  (name #2) E:\ORACLE\ORADATA\RAINY\REDO02.LOG
Thread 1 redo log links: forward: 3 backward: 1
siz: 0x32000 seq: 0x00000005 hws: 0x5 bsz: 512 nab: 0x31fff flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00519b19
Low scn: 0x0000.005680bd 08/18/2003 00:38:58
Next scn: 0x0000.005ac70f 08/19/2003 16:27:15
LOG FILE #3:
  (name #1) E:\ORACLE\ORADATA\RAINY\REDO03.LOG
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x32000 seq: 0x00000006 hws: 0x2 bsz: 512 nab: 0x31ff3 flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.005680bd
Low scn: 0x0000.005ac70f 08/19/2003 16:27:15
Next scn: 0x0000.005adc16 08/19/2003 16:40:30

根据时间选择一年以内查询还有其他的帖子 (默认的只有当前一个月的帖子，很少，本版精华区也有几个，从别处转移过来的，只能在精华区看见而这里看不见，估计是论坛bug)
yong huang 要是有兴趣也可以看看

推出来继续探讨一下...

澄清几个概念
1)系统当前SCN并不是在任何的数据库操作发生时都会改变,SCN是在事务提交或回滚时改变,

2)在控制文件,数据文件头,数据块,日志文件头,日志文件change vector中都有SCN,但其作用各不相同

数据文件头中包含了该数据文件的checkpoint SCN,表示给数据文件最近一次执行检查点操作时的SCN.
日志文件头中包含了low scn,next scn,表示给日志文件包含有从low scn到next scn的redo record.
控制文件中包含了每个数据文件的checkpoint SCN,stop SCN,每个日志文件的low scn,next scn.控制文件中checkpoint scn同数据文件头中checkpoint scn相同,除非数据文件被手工替换掉.控制文件中的low scn,next scn同日志文件中low scn和next scn相同

在数据库正常运行时,控制文件中对应数据文件的stop SCN都是最大值.

在正常关闭数据库的情况下,在关闭前会执行一次检查点工作当oracle会将数据缓冲区上的内容全部写回到磁盘中,然后更新控制文件中对应数据文件的stop SCN,使其等于checkpoint SCN

但在异常当机的情况下,由于最后一次检查点未进行或进行中间被中止,因而在控制文件,就存在部分的数据文件stop SCN为最大值

在数据库重新启动后,会检查控制文件中对应每个数据文件的stop SCN,如果stop SCN不等于控制文件中对应每个数据文件的checkpoint SCN,就会使用日志文件redo从checkpoint SCN开头到stop SCN为止的全部数据库操作.在定位到底是使用哪一个redo log文件时,就用到了日志文件头中的low scn,next scn,也就是说要使用的redo log 的low scn ,next scn必须包含数据文件重做所须的change vector.

在确定了哪个数据文件须redo后,oracle会比较change vector中的SCN和数据文件数据块中的SCN,如果change vector的SCN小于数据块的scn,则跳过此change vector,否则redo

数据块中ITL中还有SCN,但它的作用是用于产生一致性读快照

系统检查点scn(v$database(checkpoint_change#))
数据文件检查点（v$datafile(checkpoint_change#)）
数据文件终止scn(v$datafile(last_change#))

数据文件中存放的检查点
启动scn (v$datafile_header(checkpoint_change#)

1、系统检查点scn
   当一个检查点动作完成之后，Oracle就把系统检查点的SCN存储到控制文件中。
   select checkpoint_change# from v$database
2、数据文件检查点scn
   当一个检查点动作完成之后，Oracle就把每个数据文件的scn单独存放在控制文件
中。
   select name,checkpoint_change# from v$datafile
3、启动scn
   Oracle把这个检查点的scn存储在每个数据文件的文件头中，这个值称为启动scn，
因为它用于在数据库实例启动时，检查是否需要执行数据库恢复。
   select name,checkpoint_change# from v$datafile_header
4、终止scn
   每个数据文件的终止scn都存储在控制文件中。
   select name,last_change# from v$datafile
  在正常的数据库操作过程中，所有正处于联机读写模式下的数据文件的终止scn都为null.
5、在数据库运行期间的scn值
   在数据库打开并运行之后，控制文件中的系统检查点、控制文件中的数据文件检查点scn
和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.

在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn
都会设置成数据文件头中的那个启动scn的值。在数据库重新启动的时候，
Oracle将文件头中的那个启动scn与数据库文件检查点scn进行比较，
如果这两个值相互匹配，oracle接下来还要比较数据文件头中的启动scn和控制文件
中数据文件的终止scn。如果这两个值也一致，就意味着所有数据块多已经提交，所有
对数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程
也不需要任何恢复操作，此时数据库就可以打开了。当所有的数据库都打开之后，
存储在控制文件中的数据文件终止scn的值再次被更改为null，
这表示数据文件已经打开并能够正常使用了。