oracle scn详解

前面写过一个scn的基础性的文章，但是不能反映scn的变化和存在情况，这里要说的是scn很多情况都可能改变，而不是提交或

者是回滚的时候，当然scn存在在多个地方。如：日志文件，数据文件，控制文件等。

http://blog.csdn.net/yujin2010good/article/details/7727188

系统检查点scn(v$database(checkpoint_change#))

数据文件检查点（v$datafile(checkpoint_change#)）

数据文件终stop scn(v$datafile(last_change#))

数据文件中存放的检查点

start scn (v$datafile_header(checkpoint_change#)

1、系统检查点scn

当一个检查点动作完成之后，Oracle就把系统检查点的SCN存储到控制文件中。

select checkpoint_change# from v$database

2、数据文件检查点scn

当一个检查点动作完成后，Oracle就把每个数据文件的scn单独存放在控制文件中。

select name,checkpoint_change# from v$datafile

3、start scn

Oracle把这个检查点的scn存储在每个数据文件的文件头中，这个值称为启动scn，

因为它用于在数据库实例启动时，检查是否需要执行数据库恢复。

select name,checkpoint_change# from v$datafile_header

4、stop scn

每个数据文件的终止scn都存储在控制文件中。

select name,last_change# from v$datafile

在正常的数据库操作过程中，所有正处于联机读写模式下的数据文件的终止scn都为null.

5、在数据库运行期间的scn值

在数据库打开并运行之后，控制文件中的系统检查点、控制文件中的数据文件检查点scn和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.

在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn

都会设置成数据文件头中的那个启动scn的值。在数据库重新启动的时候，

Oracle将文件头中的那个启动scn与数据库文件检查点scn进行比较，

如果这两个值相互匹配，oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn。如果这两个值也一致，就意味着所有数据块多已经提交，所有数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作，此时数据库就可以打开了。当所有的数据库都打开之后，存储在控制文件中的数据文件终止scn的值再次被更改为null，这表示数据文件已经打开并能够正常使用了。

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

澄清几个概念

1)系统当前SCN并不是在任何的数据库操作发生时都会改变,SCN是在事务提交或回滚时改变,

2)在控制文件,数据文件头,数据块,日志文件头,日志文件change vector中都有SCN,但其作用各不相同 （这两种说法有问题的，各位看清楚）

数据文件头中包含了该数据文件的checkpoint SCN,表示给数据文件最近一次执行检查点操作时的SCN.日志文件头中包含了low scn,next scn,表示给日志文件包含有从low scn到next scn的redo record.控制文件中包含了每个数据文件的checkpoint SCN,stop SCN,每个日志文件的low scn,next scn.控制文件中checkpoint scn同数据文件头中checkpoint scn相同,除非数据文件被手工替换掉.

控制文件中的low scn,next scn同日志文件中low scn和next scn相同。在数据库正常运行时,控制文件中对应数据文件的stop SCN都是最大值.在正常关闭数据库的情况下,在关闭前会执行一次检查点工作当oracle会将数据缓冲区上的内容全部写回到磁盘中,然后更新控制文件中对应数据文件的stop SCN,使其等于checkpoint SCN

但在异常当机的情况下,由于最后一次检查点未进行或进行中间被中止,因而在控制文件,就存在部分的数据文件stop SCN为最大值,在数据库重新启动后,会检查控制文件中对应每个数据文件的stop SCN,如果stop SCN不等于控制文件中对应每个数据文件的checkpoint SCN,就会使用日志文件redo从checkpoint SCN开头到stop SCN为止的全部数据库操作.在定位到底是使用哪一个redo log文件时,就用到了日志文件头中的low scn,next scn,也就是说要使用的redo log 的low scn ,next scn必须包含数据文件重做所须的change vector.

在确定了哪个数据文件须redo后,oracle会比较change vector中的SCN和数据文件数据块中的SCN,如果change vector的SCN小于数据块的scn,则跳过此change vector,否则redo。

数据块中ITL中还有SCN,但它的作用是用于产生一致性读快照

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

1: SCN并不仅仅在提交或者回滚的时候才改变，DML发生的时候会改变，提交的时候也会变，还有很多的变化都会改变，证明方法也很容易。

什么时候scn+1？

①SCN(System Change Number)只要数据库被修改，就会+1，而不是一定要进行checkpoint，例如DML的发生即使没有提交也会使SCN+1

注：SCN增加并不代表会在数据文件头中表现出来，而是需要等到checkpoint执行后才写入(当然可能已经增加了很多)

②如果一个DML导致产生事务，则会产生一个SCN。这个意思是说如果一个事务包含多个dml，则只有第一个初始产生事务的dml产生scn，提交的时候 又是 一个scn，如果一个事务只有一个dml，拿看起来就是dml产生一个scn，提交或者回滚产生一个scn。

③Oracle 10g内部的SCN会默认不管有没有动作，每隔3s自动增加一次。其他需要增加的情况则再加。

④只有ckpt进程才会修改文件头中的checkpoint计数器和SCN，DBWR只会修改数据块，即ckpt通知dbwr写数据文件，写完之后ckpt更新控制文件和数据文件头。此时若DBWR发现数据块的log block还没有被写入日志文件，则在dbwr写块之前通知llgwr把log buffer中的日志写入log文件。

2: 在定位到底使用哪个日志文件的时候，并不是用数据文件中的 low scn去框，在日志文件的low scn and next scn之间就利用该日志文件。而是在数据文件头中有 RBA的记录，RBA包含了日志序号、block number、slot number。这样可以直接定位到日志文件（归档日志文件）和具体的位置

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

1、SCN存在redo log文件，control文件、数据文件;

2、oracle正常运行时，control文件的SCN是个很大的数，与redo log文件、数据文件的SCN不同，正常关闭时，做完checkpoint后，三者的SCN值相同;

3、当一个事务commit成功时，redo log文件中的SCN+1,当该事务所做的修改写入数据文件后，数据文件的SCN+1；所以，当数据库发现SCN不一致，应该是:

redo log文件中的SCN>=数据文件中的SCN

拿两个例子来说明一下问题（说明scn增加）

当热备份时候，数据

1、热备情况下锁定数据文件头，这是如果恢复就要从这个scn开始的日志（到当前日志）

alter 。。begin backup 命令有两个效果，首先会触发表空间上的检查点操作，强迫datafile在备份开始的时候处于一致性状态，然后datafile_header scn被锁定，在发出alter 。。end backup之前scn不会变化。
表空间的备份并不会影响后续数据文件内容的修改，就是说dbwr还是在写，而对于cp不会知道这些变化，最后开始备份时数据就处于不一致状态，所以最后数据文件也是不一致的状态，所以备份也是不一致的。oracle通过锁定这个scn知道对应的scn的时钟点，恢复数据时就从这个scn开始。

当然如果在则个过程中数据库异常终止的话，就变成datafile_header scn<control file scn ,数据库就打不开，然后oracle会认为你的datafile是恢复过来的，出现这种情况，就是对被锁定的数据文件解锁。

文件头被锁定，

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence 3

Next log sequence to archive 5

Current log sequence 5

SQL> alter tablespace users begin backup;

Tablespace altered.

SQL> select d.file_name filename,d.tablespace_name ts_name,b.status

2 from dba_data_files d,v$backup b

3 where d.file_id=b.file# ;

FILENAME

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

TS_NAME STATUS

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

/oracle/products/oradata/wolf/users01.dbf

USERSACTIVE

/oracle/products/oradata/wolf/undotbs01.dbf

UNDOTBS1 NOT ACTIVE

/oracle/products/oradata/wolf/sysaux01.dbf

SYSAUX NOT ACTIVE

FILENAME

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

TS_NAME STATUS

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

/oracle/products/oradata/wolf/system01.dbf

SYSTEM NOT ACTIVE

*

SQL> select d.file_name filename,d.tablespace_name ts_name,b.status from dba_data_files d,v$backup b where d.file_id=b.file# ;

FILENAME

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

TS_NAME STATUS

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

/oracle/products/oradata/wolf/users01.dbf

USERS NOT ACTIVE

/oracle/products/oradata/wolf/undotbs01.dbf

UNDOTBS1 NOT ACTIVE

/oracle/products/oradata/wolf/sysaux01.dbf

SYSAUX NOT ACTIVE

FILENAME

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

TS_NAME STATUS

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

/oracle/products/oradata/wolf/system01.dbf

SYSTEM NOT ACTIVE

SQL> select NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_CHANGE# from v$datafile_header;

NAME

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

TABLESPACE_NAME STATUS CHECKPOINT_CHANGE#

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

/oracle/products/oradata/wolf/system01.dbf

SYSTEM ONLINE 1045734

/oracle/products/oradata/wolf/sysaux01.dbf

SYSAUX ONLINE 1045734

/oracle/products/oradata/wolf/undotbs01.dbf

UNDOTBS1 ONLINE 1045734

NAME

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

TABLESPACE_NAME STATUS CHECKPOINT_CHANGE#

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

/oracle/products/oradata/wolf/users01.dbf

USERSONLINE 1051991

显然，在将users表空间置于backup状态的时候，相应的datafile的文件头的scn就不会再发生改变，发生检查点也不会改变。

SQL> alter system checkpoint;

System altered.

SQL> select NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_CHANGE# from v$datafile_header;

NAME

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

TABLESPACE_NAME STATUS CHECKPOINT_CHANGE#

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

/oracle/products/oradata/wolf/system01.dbf

SYSTEM ONLINE 1045734

/oracle/products/oradata/wolf/sysaux01.dbf

SYSAUX ONLINE 1045734

/oracle/products/oradata/wolf/undotbs01.dbf

UNDOTBS1 ONLINE 1045734

NAME

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

TABLESPACE_NAME STATUS CHECKPOINT_CHANGE#

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

/oracle/products/oradata/wolf/users01.dbf

USERSONLINE 1051991

SQL> alter tablespace users end backup;

Tablespace altered.

SQL> select NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_CHANGE# from v$datafile_header;

NAME

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

TABLESPACE_NAME STATUS CHECKPOINT_CHANGE#

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

/oracle/products/oradata/wolf/system01.dbf

SYSTEM ONLINE 1052588

/oracle/products/oradata/wolf/sysaux01.dbf

SYSAUX ONLINE 1052588

/oracle/products/oradata/wolf/undotbs01.dbf

UNDOTBS1 ONLINE 1052588

NAME

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

TABLESPACE_NAME STATUS CHECKPOINT_CHANGE#

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

/oracle/products/oradata/wolf/users01.dbf

USERSONLINE 1052588

下面是一个rman备份的例子

Rman备份并不需要将数据库或者表空间置于backup状态，但是它会把scn记录在catalog中对应你的backupset 准备在恢复的时候来使用

对users表空间做一个完全备份

RMAN> run {

2> allocate channel dl type disk;

3> backup

4> format='/oracle/%d_%N_%s.bk' tablespace users;

5> release channel dl;

6> }

allocated channel: dl

channel dl: SID=135 device type=DISK

Starting backup at 07-JUL-12

channel dl: starting full datafile backup set

channel dl: specifying datafile(s) in backup set

input datafile file number=00004 name=/oracle/products/oradata/wolf/users01.dbf

channel dl: starting piece 1 at 07-JUL-12

channel dl: finished piece 1 at 07-JUL-12

piece handle=/oracle/WOLF_USERS_4.bk tag=TAG20120707T212025 comment=NONE

channel dl: backup set complete, elapsed time: 00:00:01

Finished backup at 07-JUL-12

Starting Control File and SPFILE Autobackup at 07-JUL-12

piece handle=/oracle/products/flash_recovery_area/WOLF/autobackup/2012_07_07/o1_mf_s_788044826_7zkvmc88_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 07-JUL-12

released channel: dl

RMAN> list backup of tablespace users;

List of Backup Sets

===================

BS Key Type LV Size Device Type Elapsed Time Completion Time

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

1 Full 936.70M DISK 00:01:29 07-JUL-12

BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20120707T155817

Piece Name: /oracle/products/flash_recovery_area/WOLF/backupset/2012_07_07/o1_mf_nnndf_TAG20120707T155817_7zk8qdw4_.bkp

List of Datafiles in backup set 1

File LV Type Ckp SCN Ckp Time Name

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

4 Full 1035123 07-JUL-12 /oracle/products/oradata/wolf/users01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

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

3 Full 1.30M DISK 00:00:00 07-JUL-12

BP Key: 3 Status: AVAILABLE Compressed: NO Tag: TAG20120707T212025

Piece Name: /oracle/WOLF_USERS_4.bk

List of Datafiles in backup set 3

File LV Type Ckp SCN Ckp Time Name

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

4 Full 1053093 07-JUL-12 /oracle/products/oradata/wolf/users01.dbf

恢复的时候应用1053093开始到现在的归档日志和重做日志.

说这么多其实都没用，都是对scn进行一个了解和认识，回到scn的作用上，scn主要是维护数据库的一致性。

主要就是说我们在发生崩溃或者灾难时需要恢复数据，使用到scn，无论是实例恢复还是介质恢复。

下面我们来一个事例

误删除表的恢复，当然我们这里的scn是这样查出来的，如果是是生产环境就需要去分析了。

创建表

create table kk(id number);

插入数据

SQL> begin
2 for i in 1..100000 loop
3 insert into kk values(1);
4 commit;
5 end loop;
6 end;
7 /

PL/SQL procedure successfully completed.

SQL> select count(*) from kk;

COUNT(*)
----------
100048

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
1298494

SQL> delete from kk;

100048 rows deleted.

SQL> commit;

Commit complete.
SQL> select count(*) from kk;

COUNT(*)
----------
0

SQL> select count(*) from kk as of scn 1298494;

COUNT(*)
----------
100048

SQL> insert into kk select * from kk as of scn 1298494;

100048 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from kk;

COUNT(*)
----------
100048

欢迎加入：
119224876(db china联盟),233065499(db china联盟),229845401(虚拟化-云计算-物联网)