SCN与数据恢复关联

一、各种SCN简介：如图，控制文件中有系统SCN号，针对每个数据文件还有文件SCN号、结束SCN号（如四个数据文件就有4个对应的文件SCN号、结束SCN号）数据文件头部

一、各种SCN简介：

如图，控制文件中有系统SCN号，针对每个数据文件还有文件SCN号、结束SCN号（如四个数据文件就有4个对应的文件SCN号、结束SCN号）

数据文件头部有开始SCN号。都是为了保证数据文件的一致性

正常情况下：系统SCN、文件SCN、文件头部的开始SCN应该一样，结束SCN为null

系统SCN：

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

617242

文件SCN：

SQL> select name,checkpoint_change# from v$datafile;

NAME CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/jiagulun/system01.dbf 617242

/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 617242

/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 617242

/u01/app/oracle/oradata/jiagulun/users01.dbf 617242

/u01/app/oracle/oradata/jiagulun/example01.dbf 617242

/u01/app/oracle/oradata/jiagulun/data1_01_dbf 617242

结束SCN：

SQL> select name,last_change# from v$datafile;

NAME LAST_CHANGE#

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

/u01/app/oracle/oradata/jiagulun/system01.dbf

/u01/app/oracle/oradata/jiagulun/undotbs01.dbf

/u01/app/oracle/oradata/jiagulun/sysaux01.dbf

/u01/app/oracle/oradata/jiagulun/users01.dbf

/u01/app/oracle/oradata/jiagulun/example01.dbf

/u01/app/oracle/oradata/jiagulun/data1_01_dbf

数据文件头部开始SCN：

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

NAME CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/jiagulun/system01.dbf 617242

/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 617242

/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 617242

/u01/app/oracle/oradata/jiagulun/users01.dbf 617242

/u01/app/oracle/oradata/jiagulun/example01.dbf 617242

/u01/app/oracle/oradata/jiagulun/data1_01_dbf 617242

每一条日志都有SCN，每个日志组文件的头部有两个SCN first SCN和next SCN

first SCN：即这个文件组中第一条日志的SCN，等于上一组的next SCN。

next SCN：即这个文件组中最后一条日志的SCN，等于下一组的first SCN。

二、SCN如何保证数据库文件一致性（如何确认需要恢复）？

正常关闭：将所有buffer cache脏块写到磁盘，同时更新系统SCN、文件SCN，，数据头部开始SCN，同时结束SCN写上与系统SCN、文件SCN、数据头部开始SCN都一样的时间点（关闭时间）

非正常关闭：结束SCN为null，未正常写上。开启数据库时检测到结束SCN为null，则需要实例恢复。

数据文件丢失：例如当1号DBF文件丢失了，从备份中拷贝一个备份的1号DBF文件过来，此时文件头部的SCN比较旧，与控制文件系统SCN号对比，oracle则发现需要做恢复。则用跑日志将其SCN跑到与控制文件中文件SCN一样。

控制文件丢失：控制文件和数据文件都换成旧的，此时光对比控制文件中的SCN号和数据文件头部的SCN号还不能确认需不需要恢复，oracle还要对比on disk rba scn，如果on disk rba scn比控制文件中的SCN号和数据文件头部的SCN号都新，则要实例恢复。

用SCN号确认使用哪些日志组来恢复实例：

目前系统SCN号为617242：

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

617242

此时日志组1first SCN为617242，则需要日志组1恢复即可；

试着经过两次日志组切换：

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

此时系统当前最新的文件SCN仍然是617242

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

617242

那么这时候数据库实例崩溃使用哪些日志组恢复呢？

此时617242在日志组1，按照序列号8-10，日志组3是最新日志，此时需要日志组1、2、3恢复。

日志中active代表组中存在日志对应的脏块还没有写到磁盘中。

执行

SQL> alter system flush buffer_cache;

System altered.

后，日志组active变为inactive：

而此时控制文件中的SCN也更新为：

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

628825

此时如果数据库实例非正常关闭，则需要日志组3来恢复。

三、总结：

控制文件中系统SCN,文件SCN等于最旧的active日志文件组的first SCN，实例恢复需要active和current日志组。

控制文件中的系统SCN,文件SCN用于确认数据恢复的所需要的重做日志文件组。

确认文件组后根据控制文件中的LRBA地址去跑日志跑到on disk rba地址。

CKPT进程只是将LRBA地址写到控制文件中，而控制文件中的系统SCN，文件SCN和数据头部SCN的更新是当一个日志组由active变为inactive时更新的，结束SCN则是关闭数据库时候更新的。