SCN 使用详细介绍

SCN号概述 :
SCN是当Oracle数据库更新后，由DBMS自动维护去累积递增的一个数字。Oracle数据库中一共有4种SCN，下面对其进行分别介绍:

1)、系统检查点SCN：

      系统检查点SCN位于控制文件中，当检查点进程启动时(ckpt)，Oracle就把系统检查点的SCN存储到控制文件中。该SCN是全局范围的，当发生文件级别的SCN时，例如将表空间置于只读状态，则不会更新系统检查点SCN。  

      查询系统检查点SCN的命令如下:

SQL> select CHECKPOINT_CHANGE# from v$database;
CHECKPOINT_CHANGE#
------------------
          82877910

2）、数据文件SCN：

      当ckpt进程启动时，包括全局范围的（比如日志切换）以及文件级别的检查点（将表空间置为只读、begin backup或将某个数据文件设置为offline等），这时会在控制文件中记录的scn。
      查询数据文件SCN的命令如下 ：

---目前数据文件对应的SCN

SQL>  select file#,checkpoint_change# from v$datafile;
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1           82877910
         2           82877910
         3           82877910
         4           82877910
         5           82877910
         6           82877910
已选择6行。
--将表空间改为只读模式
SQL> alter tablespace users read only;
表空间已更改。
--现在查询数据文件对应SCN

SQL>  select file#,checkpoint_change# from v$datafile;
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1           82877910
         2           82877910
         3           82877910
         4           82890043
         5           82877910
         6           82877910
已选择6行。

--当前系统SCN

SQL>  select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
          82877910

    可以看到4号文件也就是users表空间所属的文件scn值和其他文件不一致，且比系统检查点的scn要大。

3)、结束SCN

      每个数据文件都有一个结束scn，在数据库的正常运行中，只要数据文件在线且是可读写的，结束scn为null。否则则存在具体的scn值。结束scn也记录在控制文件中。

--查看当前表空间状态

SQL> select TABLESPACE_NAME,STATUS from dba_tablespaces;
TABLESPACE_NAME                                              STATUS
------------------------------------------------------------ ----------------
SYSTEM                                                       ONLINE
SYSAUX                                                       ONLINE
UNDOTBS1                                                     ONLINE
USERS                                                        READ ONLY
TEMP1                                                        ONLINE
D_DATA_01                                                    ONLINE

已选择6行。
--查看数据文件介绍scn
SQL> select file#,LAST_CHANGE# from  v$datafile;
     FILE# LAST_CHANGE#
---------- ------------
         1
         2
         3
         4     82890043
         5
         6
已选择6行。

可以看到除了users表空间的结束scn不为空，其他数据文件的结束scn为空。

将数据库至于mount状态，由于该状态下所有的数据文件都不可写，故mount状态下所有的数据文件都具有结束scn。

SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 1071333376 bytes
Fixed Size                  1375792 bytes
Variable Size             494928336 bytes
Database Buffers          570425344 bytes
Redo Buffers                4603904 bytes
数据库装载完毕。
SQL> select file#,LAST_CHANGE# from  v$datafile;
     FILE# LAST_CHANGE#
---------- ------------
         1     82891232
         2     82891232
         3     82891232
         4     82890043
         5     82891232
         6     82891232
已选择6行。

SCN的机制

1)、数据库运行时的SCN

我们先看下oracle事务中的数据变化是如何写入数据文件的：

  1、 事务开始;

  2、 在buffer cache中找到需要的数据块，如果没有找到，则从数据文件中载入buffer cache中;

  3、 事务修改buffer cache的数据块，该数据被标识为“脏数据”，并被写入log buffer中;

  4、 事务提交，LGWR进程将log buffer中的“脏数据”写入redo log file中;

  5、 当发生checkpoint，CKPT进程更新所有数据文件的文件头中的信息，DBWr进程则负责将Buffer Cache中的脏数据写入到数据文件中。

2)、Redo log中的high scn和low scn

Oracle的Redo log会顺序纪录数据库的各个变化。一组redo log文件写满后，会自动切换到下一组redo log文件。则上一组redo log的high scn就是下一组redo log的low scn。在current log中high scn为无穷大。

--可通过查询v$log_history查看 low scn和 high scn。 

sql> select recid,sequence#,first_change#,next_change# from v$log_history

     RECID  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
      1393       1313      82584898     82608965
      1394       1314      82608965     82619517
      1395       1315      82619517     82647345
      1396       1316      82647345     82677530
      1397       1317      82677530     82685759
      1398       1318      82685759     82719962
      1399       1319      82719962     82756769
      1400       1320      82756769     82777339
      1401       1321      82777339     82816842
      1402       1322      82816842     82850955
      1403       1323      82850955     82871231

      1404       1324      82871231     82877910
已选择1123行。

--查看currnet redolog中的high scn

SQL> select vf.member,v.status,v.first_change# from v$logfile vf,v$log v  where vf.group#=v.group#  and v.status='CURRENT';
MEMBER                                                                            STATUS                           FIRST_CHANGE#
-------------------------------- -------------
D:\APP\ADMINISTRATOR\ORADATA\SDXJ\REDO02.LOG      CURRENT                          82877910

--dump 日志文件

SQL> alter system dump logfile 'D:\APP\ADMINISTRATOR\ORADATA\SDXJ\REDO02.LOG';

系统已更改。

--查看dump文件所在位置

SQL> show parameter user_dump
NAME                                                TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
user_dump_dest                          string                 d:\app\administrator\diag\rdbms\sdxj\sdxj\trace

--查看dump文件

Trace file d:\app\administrator\diag\rdbms\sdxj\sdxj\trace\sdxj_ora_22732.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.1 Service Pack 1 
CPU                 : 4 - type 586, 2 Physical Cores
Process Affinity    : 0x0x00000000
Memory (Avail/Total): Ph:8083M/12002M, Ph+PgF:19087M/24003M, VA:2737M/4095M 
Instance name: sdxj
Redo thread mounted by this instance: 1
Oracle process number: 19
Windows thread id: 22732, image: ORACLE.EXE (SHAD)

*** 2015-10-24 17:17:23.082
*** SESSION ID:(191.11) 2015-10-24 17:17:23.082
*** CLIENT ID:() 2015-10-24 17:17:23.082
*** SERVICE NAME:(SYS$USERS) 2015-10-24 17:17:23.082
*** MODULE NAME:(sqlplus.exe) 2015-10-24 17:17:23.082
*** ACTION NAME:() 2015-10-24 17:17:23.082
  
DUMP OF REDO FROM FILE 'D:\APP\ADMINISTRATOR\ORADATA\SDXJ\REDO02.LOG'
 Opcodes *.*
 RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
 SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
 Times: creation thru eternity
 FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=3865267460=0xe6634d04, Db Name='SDXJ'
Activation ID=3866843869=0xe67b5add
Control Seq=44932=0xaf84, File size=102400=0x19000
File Number=2, Blksiz=512, File Type=2 LOG
 descrip:"Thread 0001, Seq# 0000001325, SCN 0x000004f09dd6-0xffffffffffff"
 thread: 1 nab: 0xffffffff seq: 0x0000052d hws: 0x7 eot: 1 dis: 0
 resetlogs count: 0x337af7e4 scn: 0x0000.0020ecd7 (2157783)
 prev resetlogs count: 0x3362a786 scn: 0x0000.000e5bb0 (940976)
 Low  scn: 0x0000.04f09dd6 (82877910) 10/24/2015 12:15:29
 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
 Enabled scn: 0x0000.0020ecd7 (2157783) 11/15/2014 11:47:48
 Thread closed scn: 0x0000.04f0d1e0 (82891232) 10/24/2015 16:15:56
 Disk cksum: 0xab35 Calc cksum: 0xab35
 Terminal recovery stop scn: 0x0000.00000000
 Terminal recovery  01/01/1988 00:00:00
 Most recent redo scn: 0x0000.00000000
 Largest LWN: 0 blocks
 End-of-redo stream : No
 Unprotected mode
 Miscellaneous flags: 0x800000
 Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000

redo log中当前系统的SCN记录，当前最新的数据库scn值可通过如下命令查看

SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
                82892621

如果需要进行实例恢复，则需要恢复的记录为82877910至82892621中redo log中的记录。

3)、日志切换或者checkpoint

当日志切换或发生checkpoint（上述第五个步骤）时，从Low SCN到Next SCN之间的所有redo记录的数据就被DBWn进程写入数据文件中，而CKPT进程则将所有数据文件（无论redo log中的数据是否影响到该数据文件）的文件头上记录的Start SCN(通过视图v$datafile_header的字段checkpoint_change#可以查询)更新为Next SCN，同时将控制文件中的System Checkpoint SCN（通过视图v$database的字段checkpoint_change#可以查询）、每个数据文件对应的Datafile Checkpoint（通过视图v$datafile的字段checkpoint_change#可以查询）也更新为Next SCN。但是，如果该数据文件所在的表空间被设置为read-only时，数据文件的Start SCN和控制文件中Datafile Checkpoint SCN都不会被更新。相关视图查询如下:

--数据文件头信息

SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
          82891235
          82891235
          82891235
          82890043
          82891235
          82891235
已选择6行。

--System Checkpoint SCN

SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
          82891235

--每个数据文件checkpoint scn

SQL> select file#,status,checkpoint_change# from v$datafile;
     FILE# STATUS         CHECKPOINT_CHANGE#
---------- -------------- ------------------
         1 SYSTEM                 82891235
         2 ONLINE                   82891235
         3 ONLINE                   82891235
         4 ONLINE                   82890043  --该文件为只读文件。
         5 ONLINE                   82891235
         6 ONLINE                   82891235
已选择6行。

4)、心跳 
在Oracle中有一个事件叫Heartbeat，这个词在很多地方被提及，并且有着不同的含义(比如RAC中)，我们这里要讨论的是CKPT的Heartbeat机制。Oracle通过CKPT进程每3秒将Heartbeat写入控制文件，以减少故障时的恢复时间。

5)、数据库正常关闭启动

      数据库正常关闭时，系统会执行一个完全检查点动作，并用该检查点时的SCN号更新上述4个SCN号，这时所有数据文件的终止SCN号会设置为数据文件头的那个启动SCN（除了离线和只读的数据文件）。

数据库重新启动时，Oracle将数据文件头中的启动SCN与数据文件检查点SCN比较，如果这 两个值匹配，Oracle接下来再比较数据文件头中的SCN和控制文件中数据文件的终止SCN，如果这个值也匹配，就意味着所有数据块已经提交，因此数据 库不需要进行恢复，此时数据库直接打开。

      当所有的数据文件都打开之后，在线且可读写的数据文件终止SCN再次被设置为NULL，表示数据文件已经打开并能够正常使用了。有些表空间是只读的，这时控制文件中的系统检查点SCN号会不断增长，而数据文件SCN号和文件头中的启动SCN(会停止更新直到表空间又设置为可读写)，显然这时系统检查点SCN号会大于数据文件SCN和文件头启动SCN。

6)、数据库非正常关闭 
数据库非正常关闭 ( 或称为实例崩溃 ) 时，终止 SCN 不会被设置，依然为 NULL ，这可以通过把数据库启动至 mount 状态查询出来。 这样重新启动时，SMON进程 会执行实例恢复工作，即先执行前滚、回滚操作，再把数据库打开。

SQL> shutdown abort;
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 1071333376 bytes
Fixed Size                  1375792 bytes
Variable Size             494928336 bytes
Database Buffers          570425344 bytes
Redo Buffers                4603904 bytes
数据库装载完毕。
SQL> select file#,LAST_CHANGE# from  v$datafile;
     FILE# LAST_CHANGE#
---------- ------------
         1
         2
         3
         4     82890043
         5
         6
已选择6行。

7)、数据文件介质故障

出现介质故障时，数据文件检查点SCN及系统检查点SCN比文件头启动SCN大。系统发生介质故障时，数据文件被以前的备份代替，控制文件中的数据文件检查点SCN肯定比文件头中的启动SCN要大，这样Oracle就知道要对这个文件进行介质恢复。

8)、控制文件介质故障

系统检查点SCN及数据文件SCN比数据文件头启动SCN小：
在数据库恢复时，控制文件可能不是最新的，即把一个较早的控制文件还原为当前的控制文件，然后再执行恢复操作，这时控制文件中的系统检查点SCN和数据文 件SCN可能比文件头的启动SCN小。这时恢复数据库要用下面命令：recover database using Backup Controlfile或其他的恢复语句。

9)、备份时的实例崩溃

当执行begin backup时实例崩溃：控制文件中的数据文件检查点SCN号和数据文件头部检查点SCN号相同，但是每个可读写的在线数据文件之间检查点SCN号不同， 那么要求介质恢复，例如发出begin backup命令后就会出现这种情况，需要通过end backup命令好才可以打开数据库。

以上，是本人通过网文自己总结的，示例部分都是自己亲手操作过的，希望能给大家提供一定的帮助。同时，也系统大家对此提出宝贵意见和建议。