检查点及SCN号（二）

 

四、SCN的管理方式

Oracle对SCN的管理，分为单节点和RAC两种方式：

1.单节点的instance中

单节点的instance中，SCN值存在SGA区，由system commit number latch保护。任何进程要得到当前的SCN值，都要先得到这个latch。

2.RAC/OPS环境中

Oracle通过排队机制(Enqueue)实现SCN在各并行节点之间的顺序增长。

 

具体有两种方法：

Lamport算法：

又称面包房算法，先来先服务算法。跟很多银行采用的排队机制一样。客户到了银行，先领取一个服务号。一旦某个窗口出现空闲，拥有最小服务号的客户就可以去空闲窗口办理业务。

Commit广播算法：

一有commit完成，最新的SCN就广播到所有节点中。

上述两种算法可以通过调整初始化参数max_commit_propagation_delay来切换。在多数系统 (除了Compaq Tur64 Unix)中，该参数的默认值都是700厘秒(centisecond)，采用Lamport算法。如果该值小于100厘秒，Oracle就采用广播算法，并且记录在alert.log文件中。

 

五、SCN的种类

（1）Commit SCN

当用户提交commit命令后，系统将当前scn赋给该transaction。这些信息都反映在redo buffer中，并马上更新到redo log 文件里。

（2）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方式打开时，该表空间就无法再改回在线状态。

（3）Checkpoint SCN

当数据库内存的脏数据块(dirty blocks)写到各数据文件中时，就发生一次checkpoint。数据库的当前checkpoint scn值存在x$kccdi.discn中。Checkpoint scn在数据库恢复中起着至关重要的作用。无论你用何种办法恢复数据库，只有当各个数据库文件的checkpoint scn都相同时，数据库才能打开。

虽然参数“_allow_resetlogs_corruption”可以在checkpoint scn不一致时强制打开数据库，但是这样的数据库在open后必须马上作全库的export，然后重建数据库并import数据。

（4）Resetlog SCN

数据库不完全恢复时，在指定时间点后的scn都无法再应用到数据库中。Resetlog时的scn就被设成当前数据库scn，redo log也会被重新设置。

（5）Stop SCN

Stop scn记录在数据文件头上。当数据库处在打开状态时，stop scn被设成最大值0xffff.ffffffff。在数据库正常关闭过程中，stop scn被设置成当前系统的最大scn值。在数据库打开过程中，Oracle会比较各文件的stop scn和checkpoint scn，如果值不一致，表明数据库先前没有正常关闭，需要做恢复。

（6）High and Low SCN

Oracle的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。

SQL> col recid format 9999

SQL> col requence# format 9999

SQL> col first_change# format 9,999,999,999,999

SQL> col next_change# format 9,999,999,999,999

SQL> select recid,sequence#,first_change#,next_change# from v$log_history where rownum<6;

RECID SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

----- ---------- ------------------ ------------------

484 484 1,928,645,840,091 1,928,645,840,436

485 485 1,928,645,840,436 1,928,645,840,636

486 486 1,928,645,840,636 1,928,778,045,209

487 487 1,928,778,045,209 1,929,255,480,725

488 488 1,929,255,480,725 1,930,752,214,033

 

六、SCN号与oracle数据库恢复的关系

SCN号与oracle数据库恢复过程有着密切的关系，只有很好地理解了这层关系，才能深刻地理解恢复的原理，从而才能很好地解决这方面的问题。

SCN与CHECKPOINT CKPT进程在checkpoint发生时，将当时的SCN号写入数据文件头和控制文件，同时通知DBWR进程将数据块写到数据文件。

CKPT进程也会在控制文件中记录RBA(redo block address),以标志Recovery需要从日志中哪个地方开始。与checkpoint相关的SCN号有四个，其中三个存在控制文件中，一个存放在数据文件头中。

这四个分别是：

（1）System Checkpoint SCN

当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中。

我们可以通过下面SQL语句查询：

select checkpoint_change# from v$database;

（2）Datafile Checkpoint SCN

当checkpoint完成后，ORACLE将Datafile Checkpoint SCN号存放在控制文件中。

我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt SCN号。

select name,checkpoint_change# from v$datafile;

（3）Start SCN号

ORACLE将Start SCN号存放在数据文件头中。

这个SCN用于检查数据库启动过程是否需要做media recovery.

我们可以通过以下SQL语句查询：

select name,checkpoint_change# from v$datafile_header;

（4）End SCN号

ORACLE将End SCN号存放在控制文件中。

这个SCN号用于检查数据库启动过程是否需要做instance recovery.

我们可以通过以下SQL语句查询：

select name,last_change# from v$datafile;

在数据库正常运行的情况下，对可读写的，online的数据文件，该SCN号为NULL.

 

试验内容如下：

在执行检查点进程之前SCN号如下：

（1）System Checkpoint SCN

SQL>select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

------------------

4609061

（2）Datafile Checkpoint SCN

SQL>select name,checkpoint_change# from v$datafile;

NAME                                    CHECKPOINT_CHANGE#

-------------------                     ------------------

D:\BOCO\OPENVIEW\ORADATA\OPENVIEW\user01.dbf        4609061

（3）Start SCN

SQL>select name,checkpoint_change# from v$datafile_header;

NAME                                    CHECKPOINT_CHANGE#

-------------------                     ------------------

D:\BOCO\OPENVIEW\ORADATA\OPENVIEW\user01.dbf        4609061

（4）End SCN

SQL>select name,last_change# from v$datafile;

 

执行alter system checkpoint后的SCN号如下：

（1）System Checkpoint SCN

SQL>select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

------------------

4609630

（2）Datafile Checkpoint SCN

SQL>select name,checkpoint_change# from v$datafile;

NAME                                    CHECKPOINT_CHANGE#

-------------------                     ------------------

D:\BOCO\OPENVIEW\ORADATA\OPENVIEW\user01.dbf  4609630

Start SCN

SQL>select name,checkpoint_change# from v$datafile_header;

NAME                                    CHECKPOINT_CHANGE#

-------------------                     ------------------

D:\BOCO\OPENVIEW\ORADATA\OPENVIEW\user01.dbf  4609630

End SCN

SQL>select name,last_change# from v$datafile;

 

SCN不连续原因可能如下：

1.当发生日志组切换的时候

2.当符合LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target参数设置的时候

3.当运行ALTER SYSTEM SWITCH LOGFILE的时候

4.当运行ALTER SYSTEM CHECKPOINT的时候

5.当运行alter tablespace XXX begin backup，end backup的时候

6.当运行alter tablespace ,datafile offline的时候;

（文章来自网络，如有侵权请来信告知，本站将在第一时间删除。）