本篇文章给大家分享的是有关如何解析Oracle SCN，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。

创新新互联，凭借十余年的做网站、成都网站设计经验，本着真心·诚心服务的企业理念服务于成都中小企业设计网站有上千家案例。做网站建设，选成都创新互联公司。

Oracle中的SCN（system change number）和我们的北京时间的意义是相同的，SCN是Oracle中的时间号。

 为什么Oracle不用时间来界定呢？

我在北京时间8：00的时候执行一条DML语句，然后修改机器上的时间为7：00，再执行一条DML语句。如果用机器上的时间区分的话，那Oracle根本区分不出来这两条DML语句的执行顺序——而这一点对于Oracle是很重要的。所以它采用自己产生的SCN来区分所有操作的先后顺序。

SCN设计的值很大，所以不用担心达到最大值后怎么办。

可以查看系统当前的SCN号：

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

               464640326
 

也可以查看系统当前保存的SCN号：

SQL> select checkpoint_change# from v$database

CHECKPOINT_CHANGE#

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

         464639929
 

如果此时数据库损坏，当重启时候需要修复的，就是这两个SCN之间的数据。这些数据保存在在线重做日志文件中：

SQL> select GROUP#, STATUS, FIRST_CHANGE# from v$log;

    GROUP# STATUS                         FIRST_CHANGE#

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

         1 INACTIVE                           464633029

         2 INACTIVE                           464637664

         3 CURRENT                            464638303
 

group1中保存的数据产生的SCN号为 464633029 至 464637664；group2中的SCN号为 464637664 至 464638303；group3中的SCN号为 464638303 至 464640326（当前SCN号）。

所以，若此时执行shutdown abort并重启，执行crash recovery时，使用的在线重做日志文件为group3中的member。而通过v$log.status字段也能看到：group3的状态为current。

Part I.  透析SCN号

SCN是当Oracle数据库更新后，由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;

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

CHECKPOINT和SCN的关联
Checkpoint发生的目的就是要把存储在buffer内的已提交交易写回disk，否则一旦发生crash，需要进行recovery时，就必须花很多时间从redo log file内最后的SCN交易开始进行recovery，这样在商业应用上是很浪费时间和没有效率的。

当commit一笔交易时，只会立刻将redo buffer写入redo log file内，但是并不会马上将该update后的block（dirty block）同步写回disk datafile中，这是为了减少过多disk IO，所以采取batch方式写入。

When a checkpoint occurs. Oracle must update the headers of all datafiles to record the details of the checkpoint.  This is done by the CKPT process.  The CKPT process does not write blocks to disk; DBWn always performs that work.

在shutdown normal or shutdown immediate下，也就是所谓的clean shutdown, checkpoint也会自动触发。当发生checkpoint时，会把SCN写到四个地方去。三个地方在control file 内，一个在datafile header。

Control file三个地方为：
1、        System checkpoint SCN
SQL> select to_char(checkpoint_change#, 'XXXXXXXXXXXX') from v$database;

TO_CHAR(CHECKPOINT_CHANGE#,'XX
-----------------------------------------------------------------
  7161D7365DC

2、        Datafile checkpoint SCN
SQL> select name, to_char(checkpoint_change#,'XXXXXXXXXXXX') from v$datafile where name like '%gisdts01%';

NAME
-------------------------------------------------------------------
TO_CHAR(CHECKPOINT_CHANGE#,'XX
-------------------------------------------------------------------
/gisdata/datafile/gisdts01.dbf
  7161D7365DC

3、        Stop SCN
SQL> select name,last_change# from v$datafile where name like '%gisdts01%';
NAME                           
--------------------------------
/gisdata/datafile/gisdts01.dbf
正常datafile在read-write mode运作下，last_change#一定是null

还有一个SCN在datafile header内
4、        Start SCN
SQL>select name,to_char(checkpoint_change#,'XXXXXXXXXXXX')  from v$datafile_header where name like '%gisdts01%';
NAME
---------------------------------------------------------------
TO_CHAR(CHECKPOINT_CHANGE#,'XX
---------------------------------------------------------------
/gisdata/datafile/gisdts01.dbf
  7161D7365DC
为什么储存在control file中要分为两个地方（system checkpoint scn, datafile checkpoint scn?）。当把一个tbs设为read-only时，他的scn会冻结停止，此时datafile checkpoint scn是不会再递增改变的，但是整体的system checkpoint scn却仍然会不断递增前进。所以这是为什么需要分别在两个地方储存SCN。

正常shutdown database后，SCN会发生什么变化？
可以把数据库开在mount mode
SQL> select to_char(checkpoint_change#,'XXXXXXXXXXXX') from v$database;
TO_CHAR(CHECKPOINT_CHANGE#,'XX
-------------------------------------------------------------
  7161D7455B9
SQL>select name,to_char(checkpoint_change#,’XXXXXXXXXXXX’),to_char(last_change#
,’XXXXXXXXXXXX’) from v$datafile where name like '%gisdts01%';
NAME
-------------------------------------------------------------
TO_CHAR(CHECKPOINT_CHANGE#,'XX
-------------------------------------------------------------
TO_CHAR(LAST_CHANGE#,'XXXXXXXX
-------------------------------------------------------------
/gisdata/datafile/gisdts01.dbf
  7161D7455B9
  7161D7455B9
可以看到储存在control file中的三个SCN的数值都是相同的，注意此时的stop scn不会是null，而是等于start scn。
再来查询datafile header中的SCN：
SQL> select name, to_char(checkpoint_change#,'XXXXXXXXXXXX') from v$datafile_hea
der where name like '%gisdts01%';
NAME
-------------------------------------------------------------------
TO_CHAR(CHECKPOINT_CHANGE#,'XX
-------------------------------------------------------------------
/gisdata/datafile/gisdts01.dbf
  7161D7455B9

当clean shutdown时，checkpoint会进行，并且此时datafile的stop scn和start scn会相同。等我们打开数据库时，oracle会检查datafile header中的start scn和存于control file中的datafile的scn是否相同，如果相同，接着检查start scn和stop scn是否相同，如果仍然相同，数据库会正常启动，否则就需要recovery….等到数据库open后，储存在control file中的stop scn就会恢复为null值，此时表示datafile是open在正常模式下。
如果不正常shutdown(shutdown abort)，则mount数据库后，会发现stop scn并不等于其它位置的scn，而是等于null。这表示oracle在shutdown时没有进行checkpoint，下次启动必须进行crash recovery。

Part II. Oracle SCN机制解析

SCN（System Chang Number）作为oracle中的一个重要机制，在数据恢复、Data Guard、Streams复制、RAC节点间的同步等各个功能中起着重要作用。理解SCN的运作机制，可以帮助你更加深入地了解上述功能。

在理解SCN之前，我们先看下oracle事务中的数据变化是如何写入数据文件的：

1、 事务开始；

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

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

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

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

经过上述5个步骤，事务中的数据变化最终被写入到数据文件中。但是，一旦在上述中间环节时，数据库意外宕机了，在重新启动时如何知道哪些数据已经写入数据文件、哪些没有写呢（同样，在DG、streams中也存在类似疑问：redo log中哪些是上一次同步已经复制过的数据、哪些没有）？SCN机制就能比较完善的解决上述问题。

SCN是一个数字，确切的说是一个只会增加、不会减少的数字。正是它这种只会增加的特性确保了Oracle知道哪些应该被恢复、哪些应该被复制。

总共有4中SCN：系统检查点（System Checkpoint）SCN、数据文件检查点（Datafile Checkpoint）SCN、结束SCN（Stop SCN）、开始SCN（Start SCN）。其中其面3中SCN存在于控制文件中，最后一种则存在于数据文件的文件头中。

在控制文件中，System Checkpoint SCN是针对整个数据库全局的，因而之存在一个，而Datafile Checkpoint SCN和Stop SCN是针对每个数据文件的，因而一个数据文件就对应在控制文件中存在一份Datafile Checkpoint SCN和Stop SCN。在数据库正常运行期间，Stop SCN(通过视图v$datafile的字段last_change#可以查询)是一个无穷大的数字或者说是NULL。

在一个事务提交后（上述第四个步骤），会在redo log中存在一条redo记录，同时，系统为其提供一个最新的SCN（通过函数dbms_flashback.get_system_change_number可以知道当前的最新SCN），记录在该条记录中。如果该条记录是在redo log被清空（日志满做切换时或发生checkpoint时，所有变化日志已经被写入数据文件中），则其SCN被记录为redo log的low SCN。以后在日志再次被清空前写入的redo记录中SCN则成为Next SCN。

当日志切换或发生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都不会被更新。

那系统是如何产生一个最新的SCN的？实际上，这个数字是由当时的timestamp转换过来的。每当需要产生一个最新的SCN到redo记录时，系统获取当时的timestamp，将其转换为数字作为SCN。我们可以通过函数SCN_TO_TIMESTAMP（10g以后）将其转换回timestamp：

SQL> select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback
.get_system_change_number) from dual;

GET_SYSTEM_CHANGE_NUMBER

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

SCN_TO_TIMESTAMP(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER)

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

              2877076756

17-AUG-07 02.15.26.000000000 PM

也可以用函数timestamp_to_scn将一个timestamp转换为SCN：

SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;

       SCN

----------

2877078439

最后，SCN除了作为反映事务数据变化并保持同步外，它还起到系统的“心跳”作用——每隔3秒左右系统会刷新一次系统SCN。

下面，在简单介绍一下SCN如何在数据库恢复中起作用。

数据库在正常关闭（shutdown immediate/normal）时，会先做一次checkpoint，将log file中的数据写入数据文件中，将控制文件、数据文件中的SCN（包括控制文件中的Stop SCN）都更新为最新的SCN。

数据库异常/意外关闭不会或者只更新部分Stop SCN。

当数据库启动时，Oracle先检查控制文件中的每个Datafile Checkpoint SCN和数据文件中的Start SCN是否相同，再检查每个Datafile Checkpoint SCN和Stop SCN是否相同。如果发现有不同，就从Redo Log中找到丢失的SCN，重新写入数据文件中进行恢复。具体的数据恢复过程这里就不再赘述。

SCN作为Oracle中的一个重要机制，在多个重要功能中起着“控制器”的作用。了解SCN的产生和实现方式，帮助DBA理解和处理恢复、DG、Streams复制的问题。

最后提一句，利用SCN机制，在Oracle10g、11g中又增加了一些很实用的功能——数据库闪回、数据库负载重现等。

Part III. scn(系统改变号)信息与恢复

control中有三种SCN分别为，system SCN、datafile SCN、last SCN，数据文件头中有一种SCN start SCN
system scn从视图v$database中获得，对应checkpoint_change#字段，datafile scn、last scn分别对应视图v$datafile中的checkpoint_change#，last_change#，而 start scn则从v$datafile_header中checkpoint_change#得到。
数据库在正常启动后下，system scn,datafile scn,start scn会相等，而last scn会被置于无穷大，这里为null。
正常关闭后（immediate,noraml,translate），上面四个scn会应执行full checkpoint 而相等。
当系统在非正常关闭后，如shutdown abort，这个时候last scn依然为无穷大，那么当重新启动实例时，系统首先会比较start scn与system scn，如果一致，那么再比较start scn 与last scan是否一样大，因为是非正常关闭，这里会不一样大，那么就需要例程恢复。
如果打开数据库时发现system scn>datafile scn，那么以为着使用旧的备份数据文件，也就是需要介质恢复
如果是system scn

1、正常启动时
SQL> select checkpoint_change# from v$database; --控制文件中的scn

CHECKPOINT_CHANGE#
------------------
5534071
SQL> select file#,checkpoint_change# from v$datafile_header; --start scn

FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 5534071
2 5534071
3 5534071
4 5534071
5 5534071
SQL> select file#,checkpoint_change#,last_change# from v$datafile; --datafile scn & last scn

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 5534071
2 5534071
3 5534071
4 5534071
5 5534071
2、正常关闭后，然后在startup mount;
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。

Total System Global Area 319888364 bytes
Fixed Size 453612 bytes
Variable Size 192937984 bytes
Database Buffers 125829120 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 5534485
2 5534485
3 5534485
4 5534485
5 5534485

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
5534485

SQL> select file#,checkpoint_change#,last_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 5534485 5534485
2 5534485 5534485
3 5534485 5534485
4 5534485 5534485
5 5534485 5534485
--发现start scn=last scn,证明系统是正常关闭

SQL> alter database open;

数据库已更改。

3、在正常打开状态下进行事务操作
SQL> create table t(a number);

表已创建。

SQL> insert into t values (1);

已创建 1 行。

SQL> commit;

提交完成。

SQL> insert into t values(2);

已创建 1 行。

4、非正常关闭
SQL> shutdown abort;
ORACLE 例程已经关闭。
SQL>

5、打开到mount状态下，观看scn
SQL> startup mount;
ORACLE 例程已经启动。

Total System Global Area 319888364 bytes
Fixed Size 453612 bytes
Variable Size 192937984 bytes
Database Buffers 125829120 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
SQL> select file#,checkpoint_change#,last_change# from v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 5534486
2 5534486
3 5534486
4 5534486
5 5534486

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
5534486

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

FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 5534486
2 5534486
3 5534486
4 5534486
5 5534486
--这时发现start scn 与last scn不等，last scn为无穷大，需要例程恢复

6、改变数据库状态为open，并查看该阶段运行日志
SQL> select * from wen.t;
select * from wen.t
*
ERROR 位于第 1 行:
ORA-01219: 数据库未打开: 仅允许在固定表/视图中查询

SQL> alter database open;

数据库已更改。
SQL> select * from wen.t;

A
----------
1
--发现没有提交的事务丢失。
查看日志如下：
Completed: ALTER DATABASE MOUNT
Wed May 17 21:35:46 2006
alter database open
Wed May 17 21:35:46 2006
Beginning crash recovery of 1 threads --会自动判断是否需要恢复，这里开始例程恢复
Wed May 17 21:35:46 2006
Started first pass scan
Wed May 17 21:35:47 2006
Completed first pass scan
206 redo blocks read, 90 data blocks need recovery
Wed May 17 21:35:47 2006
Started recovery at
Thread 1: logseq 167, block 271, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 2 Seq 167 Reading mem 0 --恢复用的在线重做日志
Mem# 0 errs 0: D:ORACLEORADATADB1REDO02.LOG
Wed May 17 21:35:47 2006
Ended recovery at
Thread 1: logseq 167, block 477, scn 0.5554724
90 data blocks read, 90 data blocks written, 206 redo blocks read
Crash recovery completed successfully --恢复完成
Wed May 17 21:35:47 2006
LGWR: Primary database is in CLUSTER CONSISTENT mode
Thread 1 advanced to log sequence 168
Thread 1 opened at log sequence 168
Current log# 3 seq# 168 mem# 0: D:ORACLEORADATADB1REDO03.LOG
Successful open of redo thread 1.
Wed May 17 21:35:48 2006
SMON: enabling cache recovery
Wed May 17 21:35:48 2006
ARC0: Evaluating archive log 2 thread 1 sequence 167
ARC0: Beginning to archive log 2 thread 1 sequence 167
Creating archive destination LOG_ARCHIVE_DEST_1: 'D:DBBKARC00167.001'
ARC0: Completed archiving log 2 thread 1 sequence 167
Wed May 17 21:35:48 2006
Undo Segment 1 Onlined
Undo Segment 2 Onlined
Undo Segment 3 Onlined
Undo Segment 4 Onlined
Undo Segment 5 Onlined
Undo Segment 6 Onlined

Part IV. 关于SCN的理解

1.oracle正常运行时，control文件的SCN是个很大的数，与redo log文件、数据文件的SCN不同，正常关闭时，做完checkpoint后，三者的SCN值相同;
Biti:日志文件中scn有起始和结束2个（高低），在current log中高scn同样为无穷大。
2.当一个事务commit成功时，redo log文件中的SCN+1,当该事务所做的修改写入数据文件后，数据文件的SCN+1；
Biti:commit的时候加1，其他很多时候也会加1，只要数据库发生了变化都会增加。数据写入数据文件时scn不是加1而是由ckpt更新，检查点发生的时候才修改数据文件头的检查点计数并更新scn。
3.疑问：
是不是如果一个事务比较大，在事务提交前就发生redo log entries、data buffer的写入，此时断电，则数据文件、redo log文件的SCN没有+1，且相同，但控制文件SCN不同，数据库startup时发生回滚。
Biti:数据文件是由ckpt进程更新文件头的，scn不是加1，而是更新为检查点发生那时的scn，回滚是根据回滚段头的事务表状态来进行的。

4.数据写入数据文件scn不是加1而是ckpt 更新，检查点发生的时候才修改数据文件头的 检查点计数和更新scn
是不是应该这么说?:
当ckpt 更新时发生数据写入，同时修改数据文件头的 检查点计数和更新scn 。当出现其他情况下的数据写入时（如无空闲缓冲等），不发生ckpt ，但SCN会增加。
Biti:这个时候修改的是数据块但不是数据文件头，只有检查点发生的时候才更新数据文件头，也就是说只有ckpt进程更新数据文件头（oracle8以前如果没有ckpt进程就是lgwr更新），dbwr只写数据块。

BTW:看样DBWR只是些数据块，只有CKPT进程才能更新数据文件头；
5.commit的时候加一，其他很多时候也会加1，只要数据库发生了变化都会增加。
很多时候，能否举一些例子
Biti: dml一发生即使没有提交也会增加scn, job进程一样产生scn,只要对数据库中文件发生任何的改变都有可能产生scn,SCN: system change number, not system commit number .也就是系统发生变化时所产生的一个时间点

标志。不是提交的标志，只是因为提交也是系统的变化之一而已。

6.Biti:检查点的发生，跟写日志文件是没有必然联系的
检查点通知 DBWR 写数据文件，写完后ckpt更新控制文件头和数据文件头。
当DBWR写数据块的时候若发现数据块的相关 RDBA (位于日志文件的位置) 的 log block 还没有被写入日志文件，则在dbwr写块之前必须通知lgwr把log buffer 中日志写入日志文件。

7.data block 里面的SCN是当 block 被更改的时候的SCN
而数据文件有那么多 block，自然不同的 block有不同的SCN
block中存在 block SCN 和 ITL 中的commit SCN

block SCN 又在块头和块尾都有，若不一致意味着block损坏（热备可能出现这个情况，需要从redo log中拷贝回来，若是正在修改的过程中由于进程死掉则 pmon负责清理。若 由于一些以外发生这样的不一致的情况，则查询的时候出现 1578 错误，当然该错误号也可能是物理磁盘损坏，这里表示逻辑的损坏！）这个头和尾的SCN的检查时机跟这两个参数有关：
db_block_checking boolean FALSE
db_block_checksum boolean FALSE

该2参数信息请查阅 http://tahiti.oracle.com

而ITL 中的 commit SCN 则跟 consistent gets and delay block cleanout 有关

数据文件头的 SCN 是检查点发生时更新的
代表着 当 恢复的时候从这个 SCN 点 开始在 log file 中寻找 redo 开始做恢复

8.According to Rama Velpuri's book, CKPT updates controlfiles, not their headers. It makes sense because if you look at a controlfile dump, the header doesn't even have an SCN. But the file body has sections for each datafile, and therefore each of them has an SCN to be updated.

It's odd that most books and also documentation don't even say CKPT updates controlfiles.

Follow-up to bellsz's original message. In controlfiles, the stop SCN is not a very big number; it's in fact set to infinity when the database is open. Also, SCNs are incremented for many reasons, mostly due to recursive transactions. Read Steve Adams and Hemant Chitale's answers at
http://groups.google.com/groups?sel...t_nospam.com.sg
9.

系统检查点scn(v$database(checkpoint_change#))
数据文件检查点（v$datafile(checkpoint_change#)）
数据文件终止scn(v$datafile(last_change#))

数据文件中存放的检查点
启动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>启动scn
Oracle把这个检查点的scn存储在每个数据文件的文件头中，这个值称为启动scn，
因为它用于在数据库实例启动时，检查是否需要执行数据库恢复。
select name,checkpoint_change# from v$datafile_header
4>终止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，
这表示数据文件已经打开并能够正常使用了。

10.

找了一些网页,发现SCN确实不只在事务提交时增加,以下是网页上的摘要:
1)
SCN means "System Change Number" not "System Commit Number".
However, because the SCN is always incremented at commits and seldom otherwise, it is OK to use the two terms interchangeably.
2)
The SCN is incremented whenever a transaction commits. However, this is not the only source of increments. In a seemingly idle database, the SCN gets incremented also through AQ, SMON, job queues...

1中说了 oracle seldom操作也会引起SCN的增加,2中更明确说了AQ, SMON, job queues... 会导致SCN的增加,因此应该得出结论,在ORACLE中除了COMMIT会导致SCN增加外还有其它的ORACLE后台进程会导致SCN增加.

但是,是否是普通的DML导致了SCN的增加,还是由于DML操作过程中后台进程导致了SCN增加的假象?请大家踊跃讨论!
还有ORACLE后台进程在何时,何种情况下导致了SCN增加,也请大家踊跃讨论!

Biti:这句话我应该更准确第表达一下
如果一个dml导致产生事务，则会产生一个scn。这个意思是说
如果一个事务包含多个dml，则只有第一个初始产生事务的dml产生scn，提交的时候又是一个scn
如果一个事务只有一个dml，拿看起来就是dml产生一个scn，提交或者回滚产生一个scn
这是经过实验测试过的，如果你又兴趣，不紧紧是要找资料看，还可以动手证明。

你可以理解为 begin transaction and commit tansaction

至于没有dml的commit ,那不叫一个 transaction

你不做任何dml 而发出rollback命令 将会发现 v$sysstat 中 user rollbacks 将会增加 而 transactions 不会增加

所以你可以把结论定义为 事务的开始 和事务的结束都会导致 SCN 的增加，其他如 AQ/JOB 等也会产生SCN ……
同一个block上在一个事务中连续发生255个DML后scn也会增加
……

11.sys@DBAP01> select max(ktuxescnw*power(2,32)+ktuxescnb) from x$ktuxe;

MAX(KTUXESCNW*POWER(2,32)+KTUX
------------------------------
                      52211024
已用时间:  00: 00: 00.00

sys@DBAP01> alter system checkpoint;
系统已更改。
已用时间:  00: 00: 00.06

sys@DBAP01> select CHECKPOINT_CHANGE# from v$database;
CHECKPOINT_CHANGE#
------------------
          52211055
已用时间:  00: 00: 00.00

sys@DBAP01> select max(ktuxescnw*power(2,32)+ktuxescnb) from x$ktuxe;
MAX(KTUXESCNW*POWER(2,32)+KTUX
------------------------------
                      52211053
x$ktuxe 计算出来的是已经结束的最新的事务的commit scn ，所以可小于当前系统scn。 检查点scn 自然也小于当前系统scn。 但是 检查点scn 和 x$ktuxe 计算出来的大小却倚赖于 系统状况了。

current scn 是 系统当前所产生的最大 scn ，可能是当前未结束事务所产生的scn。 在9i 的dbms_flashback.get_system_change_number可以得到这个值，这个值应该是大于等于 x$ktuxe SCN (这个view 记录的是 当前数据库结束事务的最大scn)

以上就是如何解析Oracle SCN，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。

网站标题：如何解析OracleSCN
文章来源：http://scpingwu.com/article/ipjjdj.html