scn详解

 1.scn的定义

SCN（System Change Number）,也就是通常所说的系统更改号，是数据库中非常重要的一个数据结构。

SCN用以标志数据库在某个时刻提交的版本。在事务提交时，他被赋予一个唯一的标识事务的SCN。SCN同时也被认为是oracle的内部时钟机制，可被看做是逻辑时钟，，每个数据库都有一个全局的SCN生产器。

SCN 在数据库中是惟一的，并是随时间而增加的，但是可能并不是连续的。除非重建数据库，不然SCN的值永远不会被重置为0.

SCN 在数据库中是无处不在的，常见的事务表、控制文件、数据文件头、日志文件、数据块头等都记录着SCN的值。

冠以不同的前缀，SCN也有不同的名称，如检查点SCN（checkpoint SCN）、resetlogs SCN等。

2.SCN的获取方式

可以使用 dbms_flashback.get_system_change_number获得：

SQL>select dbms_flashback.get_system_change_number from dual;

    1781917309

可以理解，这里返回的SCN，也是目前redo log file最新的SCN记录。因为commit后的交易才会有SCN，而一旦commit就会立刻写入redo log file中。

3.SCN的进一步说明

系统当前SCN并不是在任何数据库操作发生时都会改变，scn通常在事务提交或回滚时改变。在控制文件、数据文件头、日志文件、数据块头都有SCN，但其作用各不同。

(1).数据文件头包含了该数据文件的checkpoint SCN，表示该数据文件最近一次执行检查点操作时的scn。

从控制文件的dump 文件，可以看到如下内容：

DATA FILE #1:
  (name #7) D:\ORACLE\PRODUCT\10.2.0\ORADATA\TSDB\SYSTEM01.DBF
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
 tablespace 0, index=1 krfil=1 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:172 scn: 0x0000.6a35da8d 09/07/2011 10:52:40
 Stop scn: 0xffff.ffffffff 09/07/2011 09:47:56
 Creation Checkpointed at scn:  0x0000.00000009 08/30/2005 13:50:22
 thread:0 rba:(0x0.0.0)

.....

sql>alter system checkpoint;

系统已更改。

sql>alter session set events 'immediate trace name file_hdrs level 10'；

会话已更改。

在D:\oracle\product\10.2.0\admin\tsdb\udump中找到刚刚转储的文件。

(name #7) D:\ORACLE\PRODUCT\10.2.0\ORADATA\TSDB\SYSTEM01.DBF
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
 tablespace 0, index=1 krfil=1 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:173 scn: 0x0000.6a3602ef 09/07/2011 13:46:34
 Stop scn: 0xffff.ffffffff 09/07/2011 09:47:56
 Creation Checkpointed at scn:  0x0000.00000009 08/30/2005 13:50:22
 thread:0 rba:(0x0.0.0)

....

（2）日志文件中包含了Low SCN 和Next SCN.

Low SCN 和Next SCN这两个SCN表示日志文件包含有介于Low SCN 和Nex tSCN的重做信息，对于current的日志文件（当前正在使用的日志文件），其最终SCN不可知，所以Next SCN被置为无穷大，也就是ffffffff。

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- --------------
         1          1         23   52428800          1 YES INACTIVE
   1781824259 04-9月 -11

         2          1         25   52428800          1 NO  CURRENT
   1781897818 06-9月 -11

         3          1         24   52428800          1 YES INACTIVE
   1781855546 05-9月 -11

SQL> select dbms_flashback.get_system_change_number from dua

GET_SYSTEM_CHANGE_NUMBER
------------------------
              1781925818

SQL>alter system switch logfile;

系统已更改

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- --------------
         1          1         26   52428800          1 NO  CURRENT
   1781925959 07-9月 -11

         2          1         25   52428800          1 YES ACTIVE
   1781897818 06-9月 -11

         3          1         24   52428800          1 YES INACTIVE
   1781855546 05-9月 -11

可以看出scn 1781925818显然位于log group#为2的日志文件中，该日志包含了SCN自1781897818到1781925959的redo信息。oracle需要根据Low SCN 和Nex tSCN来确定需要恢复的信息位于哪一个日志和归档文件中。