Oracle 检查点涉及的SCN

1. 检查点涉及的SCN (1). 数据文件中的文件头启动检查点的scn 存储在每个数据文件的文件头中 select name,checkpoint_change#  from v$datafile_header; 在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。    在数据库重新启动的时候,Oracle将文件头中的那个启动scn(存在于各个数据文件里)与数据库文件检查点scn(存在于控制文件里)进行比较，如果这两个值相互匹配，oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn。如果这两个值也一致，就意味着所有数据块的redo记录都已经提交，所有对数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作，此时数据库就可以打开了。  (2).数据文件检查点SCN, 存储在控制文件中: SELECT T.NAME,T.CHECKPOINT_CHANGE#,b.tablespace_name FROM  V$DATAFILE T,dba_data_files b where t.FILE#=b.file_id; (3).数据文件的终止scn 存储在控制文件中 select name,last_change#  from v$datafile;     终止SCN在数据库关闭或者表空间脱机是才会涉及到,在正常的数据库操作过程中，所有正处于联机读写模式下的数据文件的终止scn都为null. 在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。 (4).系统检查点SCN 存储在控制文件中 select  t.CHECKPOINT_CHANGE# from v$database t; (5). 日志文件的scn select t.FIRST_CHANGE# 开始时的SCN,t.FIRST_TIME,t.NEXT_CHANGE#  结束时的SCN from V$log_History  t order by t.FIRST_TIME; 2. 发生完全检查点时: 数据文件头，标识上次处理完的启用scn。 而CKPT进程则将所有数据文件（无论redo log中的数据是否影响到该数据文件）文件头上记录的Start SCN更新为Next SCN; (通过视图v$datafile_header的字段checkpoint_change#可以查询)       同时将控制文件中的System Checkpoint SCN更新为Next SCN; （通过视图v$database的字段checkpoint_change#可以查询） 每个数据文件对应的Datafile Checkpoint）也更新为Next SCN;（通过视图v$datafile的字段checkpoint_change#可以查询)      从Low SCN到Next SCN之间的所有redo记录的数据就被DBWn进程写入数据文件中.     3. 系统是如何产生一个最新的SCN的: 实际上，这个数字是由当时的timestamp转换过来的。每当需要产生一个最新的SCN到redo记录时，系统获取当时的timestamp，将其转换为数字作为SCN。 我们可以通过函数SCN_TO_TIMESTAMP将其转换回timestamp： select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number)  from dual;   也可以用函数timestamp_to_scn将一个timestamp转换为SCN： select timestamp_to_scn(SYSTIMESTAMP) as scn  from dual; 4. SCN除了作为反映事务数据变化并保持同步外，它还起到系统的"心跳"作用——每隔3秒左右系统会刷新一次系统SCN。