SCN(SYSTEM CHANGE NUMBER) 是当数据库更新后，由DBMS自动维护去累积递增的一个数字。当一笔交易COMMIT时，LGWR会将LOG BUFFER写入REDO LOG FILE，同时也会将该笔交易的SCN同步写入到REDO LOG FILE内（WAIT-UNTIL-COMPLETED），因此当你COMMIT TRANSACTION时，在交易成功的讯息返回之前， LGWR必须先完整的完成上述行为之后，否则你是看不到提交成功的回应讯息。

查询数据库当前最新SCN：
SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
730278

SCN分布位置：
（1）CONTROL FILE内（SYSTEM CHECKPOINT SCN）：
SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
730648
（2）CONTROLFILE内（DATAFILE CHECKPOINT SCN）：
SQL> select name, checkpoint_change# from v$datafile;

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
/home/oracle/oradata/db1/system01.dbf
730648

/home/oracle/oradata/db1/sysaux01.dbf
730648

/home/oracle/oradata/db1/undotbs01.dbf
730648

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
/home/oracle/oradata/db1/users01.dbf
730648
（3）CONTROLFILE内（STOP SCN）
SQL> select name, last_change# from v$datafile;

NAME
--------------------------------------------------------------------------------
LAST_CHANGE#
------------
/home/oracle/oradata/db1/system01.dbf

/home/oracle/oradata/db1/sysaux01.dbf

/home/oracle/oradata/db1/undotbs01.dbf

NAME
--------------------------------------------------------------------------------
LAST_CHANGE#
------------
/home/oracle/oradata/db1/users01.dbf
正常datafile在read-write mode下 last_change#一定是NULL。
（4）DATAFILE HEADER内（START SCN）
SQL> select name, checkpoint_change# from v$datafile_header;

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
/home/oracle/oradata/db1/system01.dbf
730648

/home/oracle/oradata/db1/sysaux01.dbf
730648

/home/oracle/oradata/db1/undotbs01.dbf
730648

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
/home/oracle/oradata/db1/users01.dbf
730648

为何在CONTROLFILE中要分两个SCN（SYSTEM CHECKPOINT SCN, DATAFILE CHECKPOINT SCN）.
当把一个TBS设置为READ-ONLY时，他的SCN会冻结停止，此时DATAFILE CHECKPOINT SCN是不会再递增改变的，但是整体的SYSTEM CHECKPOINT SCN却仍然会不断递增前进。

正常关机SCN的变化：
SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
731187

SQL> select name,checkpoint_change#,last_change# from v$datafile where name like '%user%';

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE# LAST_CHANGE#
------------------ ------------
/home/oracle/oradata/db1/users01.dbf
731187 731187
可以看到存储在CTROLFILE中的三个SCN都是相同的，注意此时的STOP SCN不会是NULL, 而是等于START SCN。
查询DATAFILE HEADER的SCN
SQL> select name,checkpoint_change# from v$datafile_header where name like '%users01%';

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
/home/oracle/oradata/db1/users01.dbf
731187
当CLEAN SHUTDOWN时， CHECKPOINT会执行，此时DATAFILE的STOP SCN和START SCN是一样的，等开启数据库时，ORACLE 检查DATAFILE HEADER中的START SCN和存于CONTROLFILE中的DATAFILE的SCN是否相同，如果相同，接着检查START SCN和STOP SCN是否相同，如果仍然相同，数据库就会正常打开，否则就需要RECOVERY，等数据库打开后，存在CONTROLFILE中的STOP SCN就会恢复为NULL值，此时表示DATAFILE是OPEN在正常模式下了。

如果不正常关闭数据库，则MOUNT数据库后，你会发现STOP SCN并不是等于其它位置的SCN，而是等于NULL，这表示ORACLE 在SHUTDOWN时没有进行CHECKPOINT,下次开机必须进行CRASH RECOERY。
SQL> create table ttt(id number(9));

Table created.

SQL> insert into ttt(id) values(888);

1 row created.

SQL> commit;

Commit complete.

SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup mount;
ORA-00443: background process "DIA0" did not start
SQL> startup mount;
ORACLE instance started.

Total System Global Area 631914496 bytes
Fixed Size                  1338364 bytes
Variable Size             373294084 bytes
Database Buffers          251658240 bytes
Redo Buffers                5623808 bytes
Database mounted.
SQL> select name,checkpoint_change#,last_change# from v$datafile;

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE# LAST_CHANGE#
------------------ ------------
/home/oracle/oradata/db1/system01.dbf
731190

/home/oracle/oradata/db1/sysaux01.dbf
731190

/home/oracle/oradata/db1/undotbs01.dbf
731190

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE# LAST_CHANGE#
------------------ ------------
/home/oracle/oradata/db1/users01.dbf
731190

在这里可以发现LAST_CHANGE#为NULL值，则代表数据库需要RECOVERY。
执行打开数据库。
SQL> alter database open;

Database altered.
查看ALERT日志：
alter database open
Beginning crash recovery of 1 threads
parallel recovery started with 3 processes
Started redo scan
Completed redo scan
read 57 KB redo, 67 data blocks need recovery
Started redo application at
Thread 1: logseq 16, block 231
Recovery of Online Redo Log: Thread 1 Group 1 Seq 16 Reading mem 0
Mem# 0: /home/oracle/oradata/db1/redo01a.log
Mem# 1: /home/oracle/oradata/db1/redo01b.log
Completed redo application of 0.04MB
Completed crash recovery at
Thread 1: logseq 16, block 346, scn 751374
67 data blocks read, 67 data blocks written, 57 redo k-bytes read
Mon Oct 08 10:37:46 2012
Thread 1 advanced to log sequence 17 (thread open)
Thread 1 opened at log sequence 17
Current log# 2 seq# 17 mem# 0: /home/oracle/oradata/db1/redo02a.log
Current log# 2 seq# 17 mem# 1: /home/oracle/oradata/db1/redo02b.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Oct 08 10:37:47 2012
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed

CRASH RECOVERY和MEDIA RECOVERY的比较。
启动数据库时，如果发现STOP SCN=NULL，表示需要进行CRASH RECOVERY；启数据库时，如果发现有DATAFILE HEADER的START SCN不等于存于CONTROLFILE 的DATAFILE SCN，表示需要进行MEDIA RECOVERY。
STOP SCN equal NULL ==> NEED CRASH RECOVERY
DATAFILE HEADER START SCN not equal CONTROLFILE SCN ==> NEED MEDIA RECOVERY

RECOVERY DATABASE 两种常见问题：
（1） DATAFILE HEADER SCN小于CONTROLFILE的DATAFILE SCN：如果进行了RESTORE DATAFILE，则该RESTORE 的DATAFILE HEADER SCN一定小于目前的CONTROLFILE的DATAFILE SCN，此时会无法开启数据库，必须进行MEDIA RECOVERY. 重做ARCHIVE LOG直到该DATAFILE HEADER的SCN到等于CONTROLFILE DATAFILE SCN。
RESTORE DATAFILE后MOUNT，查看SCN：
SQL> select 'controlfile' "SCN location",name,checkpoint_change#
from v$datafile where name like '%users01%'
union
select 'file header',name,checkpoint_change#
from v$datafile_header where name like '%users01%'; 2 3 4 5

SCN locatio
-----------
NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
controlfile
/home/oracle/oradata/db1/users01.dbf
753844

file header
/home/oracle/oradata/db1/users01.dbf
753749

（2） DATAFILE HEADER SCN一定会大于CONTROLFILE的DATAFILE SCN
如果只是某TABLE被DROP掉，没有破坏数据库整体数据结构，还可以用NCOMPLETE RECOVERY解决如果是某个TABLESPACE OR DATAFILE被DROP掉，因为档案结构已经破坏，目前的CONTROL FILE内已经没有该DATAFILE的信息，就算你只RESTORE DATAFILE然后进行INCOMPLETE RECOVERY也无法救回被DROP的DATA FILE。

CHECKPOINT 和SCN的关连：
CHECKPOINT发生的目的就是要把存在BUFFER内的已提交的事务写回DISK，否则一旦发生CRASH, 需要进行RECOVERY时，你就必须花很多的时间从REDO LOGFILE 内最后的SCN交易开始进行RECOVERY。
重点在于当COMMIT一个事务时，只会立刻将REDO BUFFER写入REDO LOG FILE内，但是并不会马上将该UPDATE后的BLOCK同步写回DISK DATAFILE中，这是了减少过多DISK IO的考虑，所以采取BATCH的方式写入。在SHUTDOWN NORMAL OR SHUTDOWN IMMEDIATE下，也就是CLEAN SHUTDOWN， CHECKPOINT也会自动触发，并且把SCN记录写回。当发生CHECKPOINT时，会把SCN写到上文中所提到的四个地方去。
CHEKPOINT触发条件：
（1）正常关机选项。（IMMEDIATE, NOMAL）
（2）设置初始化参数：LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT, FAST_START_IO_TARGET强制时。
（3）手动请求：ALTER SYSTEM CHECKPOINT; ALTER TABLESPACE ...OFFLINE;
(4) 切换日志时：ALTER SYSTEM SWITCH LOGFILE;

ITPub博客

SCN详解

最新文章