了解oracle中的SCN

从接触oracle到使用过程中，始终能看到SCN的身影，在oracle的备份恢复原理中更是如此。由此看来SCN的重要性不言而喻呀，对其有个综合的了解能够有对其功能有清晰地认识，在oracle中SCN的种类不一中，对SCN理解的时候常常犯晕，偶尔这样，偶尔那样。说白了就是把多种SCN混淆在一起了。如果结合控制文件，数据文件，redo等文件的dump内容来了解那几种重要的SCN，将会对其有更深的认识。直接入题：SCN: System Change NumberSCN是顺序递增的一个数字，在Oracle 中用来标识数据库的每一次改动，及其先后顺序。SCN的最大值是0xffff.ffffffff。Oracle对SCN的管理单节点的instance中，SCN值存在SGA区，由system commit number latch保护。任何进程要得到当前的SCN值，都要先得到这个latch。RAC/OPS环境中Oracle通过排队机制(Enqueue)实现SCN在各并行节点之间的顺序增长。具体有两种方法：Lamport算法：又称面包房算法，先来先服务算法。跟很多银行采用的排队机制一样。客户到了银行，先领取一个服务号。一旦某个窗口出现空闲，拥有最小服务号的客户就可以去空闲窗口办理业务。Commit广播算法：一有commit完成，最新的SCN就广播到所有节点中。上述两种算法可以通过调整初始化参数max_commit_propagation_delay来切换。在多数系统 (除了Compaq Tur64 Unix)中，该参数的默认值都是700厘秒(centisecond)，采用Lamport算法。如果该值小于100厘秒，Oracle就采用广播算法，并且记录在alert.log文件中。几种重要的SCNCommit SCN当用户提交commit命令后，系统将当前scn赋给该transaction。这些信息都反映在redo buffer中，并马上更新到redo log 文件里。Offline SCN除了System tablespace以外的任何表空间，当我们执行SQL>alter tablespace … offline normal命令时，就会触发一个checkpoint，将内存中的dirty buffer写入磁盘文件中。Checkpoint完成后，数据文件头会更新checkpoint scn和offline normal scn值。其中数据库文件头的checkpoint scn值可通过查询列x$kccfe.fecps得到。如果执行SQL>alter tablespace …offline命令时采用temporary或 immediate选项，而不用normal选项时，offline normal scn会被设成0。这样当数据库重启后通过resetlog方式打开时，该表空间就无法再改回在线状态。Checkpoint SCN当数据库内存的脏数据块(dirty blocks)写到各数据文件中时，就发生一次checkpoint。数据库的当前checkpoint scn值存在x$kccdi.discn中。Checkpoint scn在数据库恢复中起着至关重要的作用。无论你用何种办法恢复数据库，只有当各个数据库文件的checkpoint scn都相同时，数据库才能打开。虽然参数“_allow_resetlogs_corruption”可以在checkpoint scn不一致时强制打开数据库，但是这样的数据库在open后必须马上作全库的export，然后重建数据库并import数据。Resetlog SCN数据库不完全恢复时，在指定时间点后的scn都无法再应用到数据库中。Resetlog时的scn就被设成当前数据库scn，redo log也会被重新设置。Stop SCNStop scn记录在数据文件头上。当数据库处在打开状态时，stop scn被设成最大值0xffff.ffffffff。在数据库正常关闭过程中，stop scn被设置成当前系统的最大scn值。在数据库打开过程中，Oracle会比较各文件的stop scn和checkpoint scn，如果值不一致，表明数据库先前没有正常关闭，需要做恢复。High and Low SCNOracle的Redo log会顺序纪录数据库的各个变化。一组redo log文件写满后，会自动切换到下一组redo log文件。则上一组redo log的high scn就是下一组redo log的low scn。在视图v$log_history中，sequence#代表redo log的序列号，first_change#表示当前redo log的low scn，列next_change#表示当前redo log的high scn。

Oracle中数据文件SCN的一致性问题

先来看看以下两个问题:1、数据库正常运行中，所有数据文件的SCN都是一致的吗？ 2、将一数据文件offline后，再将其online时，这个数据文件的SCN会前提吗？假如是，前提到的SCN是怎么确定的？1.数据库正常运行时，所有数据文件的SCN不一定一致。问题在这个所有上，比如Offline表空间，数据文件的SCN会被冻结，而且表空间的数据文件offline/online时又会发生文件检查点，使单个数据文件SCN和数据库其他问题不一致。2.表空间online时，Oracle会取得当前SCN，解冻offline文件SCN，和当前SCN同步。简单的实验就可以清晰地看到这些变化:

SQL> set echo on SQL> @a SQL> alter system checkpoint; System altered. SQL> select file#,checkpoint_change# from v$datafile; FILE# CHECKPOINT_CHANGE# ---------- ------------------ 1 546198149 2 546198149 3 546198149 SQL> select dbms_flashback.get_system_change_number from dual; GET_SYSTEM_CHANGE_NUMBER ------------------------ 546198149 SQL> alter tablespace users offline; Tablespace altered. SQL> select file#,checkpoint_change# from v$datafile; FILE# CHECKPOINT_CHANGE# ---------- ------------------ 1 546198149 2 546198149 3 546198153 SQL> select dbms_flashback.get_system_change_number from dual; GET_SYSTEM_CHANGE_NUMBER ------------------------ 546198159 SQL> alter tablespace users online; Tablespace altered. SQL> select file#,checkpoint_change# from v$datafile; FILE# CHECKPOINT_CHANGE# ---------- ------------------ 1 546198149 2 546198149 3 546198162 SQL> SQL> select dbms_flashback.get_system_change_number from dual; GET_SYSTEM_CHANGE_NUMBER ------------------------ 546198178

如果是单纯的offline datafile，那么将不会触发文件检查点，只有针对offline
tablespace的时候才会触发文件检查点，这也是为什么online datafile需要media recovery而online
tablespace不需要。实验结果是最好的明证。
代码

SQL>
col
recid format
9999SQL>
col
requence# format
9999SQL>
col
first_change# format
9,999,999,999,999SQL>
col
next_change# format
9,999,999,999,999SQL>
select
recid,sequence#,first_change#,next_change#
from
v$log_historywhere
rownum<</span>6;RECID SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
-----
---------- ------------------ ------------------
484484
1,928,645,840,0911,928,645,840,436485485
1,928,645,840,4361,928,645,840,636486486
1,928,645,840,6361,928,778,045,209487487
1,928,778,045,2091,929,255,480,725488488
1,929,255,480,7251,930,752,214,033
关于如何使用参数_allow_resetlogs_corruption，可参见文档http://www.sidibe.net/allow_resetlog.html
点滴总结： 1，在control file,redo log,data file中都存在SCN值；2，数据库open时，检查control file中记录的SCN值与数据文件，redo log文件是否一致，如果是，数据库打开，否则，提示错误；假如数据文件SCN值小于control file中的SCN值则提示该数据文件需要介质恢复；3，redo log 中存在低SCN，高SCN值两种，当前的redo log文件的高SCN值为无穷大；日志发生切换时，高SCN值更新为系统当前SCN值，新日志文件低SCN值为前日志文件高SCN值加1，高SCN值仍然为去穷大；数据库发生变化，则写redo log文件，同时SCN值会加1。4，检查点发生时，CKPT更新数据文件头。