获取当前scn号scn1_Oracle SCN机制解析

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

。