天萃荷净

分享一篇关于Oracle SCN的详解，介绍SCN与Oracle数据库恢复的关系和SCN在数据库中的作用

一、为什么需要System checkpoint SCN号与Datafile Checkpoint SCN号

1.对只读表空间，其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。这三个SCN在表空间处于只读期间都将被冻结。

2.如果控制文件不是当前的控制文件，则System checkpoint会小于Start SCN或END SCN号。记录这些SCN号，可以区分控制文件是否是当前的控制文件。

Recovery database using backup controlfile

当有一个Start SCN号超过了System Checkpoit SCN号时，则说明控制文件不是当前的控制文件，因此在做recovery时需要采用using backup controlfile。这是为什么需要记录SystemCheckpoint SCN的原因之一。

二、重建控制文件，重建方式分两种(resetlogs和noresetlogs)

1.使用resetlogs选项时，System Checkpoint SCN为被归为0，而其中记录的各个数据文件的Datafile Checkpoint SCN则来自于Start SCN(也就是说可能会从冷备份的数据文件的数据文件头中获取)。根据上述的描述，此时需要采用using backup controlfile做recovery.因此情况是System Checkpoint SCN=0 < Start SCN = Datafile Checkpoint SCN。

2.使用noresetlogs选项时，有一个前提就是：一定要有online redo log的存在。否则就要使用resetlogs选项。这个时候控制文件重建好时，其system checkpoint SCN=Datafile Checkpoint SCN=Lastest Checkpoint SCN in online redo log,我们可以看到Datafile Checkpoint SCN并没有从Start SCN中读取。而是读取了最新的日志文件中的SCN作为自己的数据。此时重建的控制文件在恢复中的作用跟最新的控制文件类似，System Checkpoint SCN(已经读取最新的redo log的checkpoint SCN信息)可能会>Start SCN(因为数据文件可能会从冷备份中恢复)，恢复时就不需要加using backup controlfile子句了。

3.关于backup controlfile的补充：backup controlfile只有备份时刻的archive log信息，并没有DB crash时刻的archive log信息，所以并不会自动应用online redo log,而是提示找不到序号为Lastest Archive log sequence + 1的archive log,尽管你可以手动指定online redo log来实现完全恢复，但因为一旦使用了using backup controlfile子句，Oracle就视为不完全恢复，必须open resetlogs!实际上，假如你有旧的控制文件又不想resetlogs，那很简单，使用旧的控制文件mount然后backup to trace，然后手工创建控制文件，使用reuse database … noresetlogs .这样就可以recover database自动恢复并open database而不用resetlogs了(记住：必须有所有的online redo logs才可以这样！)。

三、Low SCN与Next SCN

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

2.当日志切换或发生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与Oracle数据库恢复的关系

1.SCN类型

1).System Checkpoint SCN

当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中。

我们可以通过下面SQL语句查询：

select checkpoint_change# from v$database;

2).Datafile Checkpoint SCN

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

我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt SCN号。

select name,checkpoint_change# from v$datafile;

3).Start SCN (启动SCN)

checkpoint完成后，将产生的checkpoint SCN 写入数据文件头(称之为start scn).这个SCN用于检查数据库启动过程是否需要做media recovery.

我们可以通过以下SQL语句查询：

select name,checkpoint_change# from v$datafile_header;

注意：数据文件头中的检查点SCN(start SCN) 与控制文件中记录的数据文件检查点SCN号含义是一样的。 也就是说，一旦发生全局范围以及文件级别的检查点时，不仅会将这时的检查点SCN号记录到控制文件，还会记录在检查点作用的数据文件头部。

4).End SCN号(stop scn, 终止SCN)

这个SCN号用于检查数据库启动过程是否需要做instance recovery.

我们可以通过以下SQL语句查询：

select name,last_change# from v$datafile;

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

五、各SCN之间关系

1)数据库运行期间的scn值

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

2)数据库正常关闭的scn值

在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。

3)数据库重启过程中scn作用

在数据库重新启动的时候, Oracle将文件头中的那个启动scn与数据库文件检查点scn(控制文件中)进行比较，如果这两个值相互匹配，那么不需要Media Recovery， oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn, 如果这两个值也一致，就意味着所有对数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作(即不需要实例恢复)，此时数据库就可以打开了。当所有的数据库都打开之后，存储在控制文件中的数据文件终止scn的值再次被更改为null，这表示数据文件已经打开并能够正常使用了。

还需要注意的是:

在数据库重新启动的时候, Oracle首先比较(每个)文件头中的那个启动scn (start SCN) 与控制文件中记录的 (每个) 数据库文件检查点scn， 如果他们都相互匹配，那么不需要Media Recovery. 但是如果只是控制文件中记录的数据文件检查点(多个数据文件，对应多个SCN), 与 (对应的) 数据文件头中的启动SCN (start scn) 相同 , 而在每个在线的可读可写的数据文件“之间”，他们的检查点SCN不相同， 那么也要求Media Recovery .

--------------------------------------ORACLE-DBA----------------------------------------

最权威、专业的Oracle案例资源汇总之学习笔记:Oracle SCN详解 SCN与Oracle数据库恢复的关系