深入了解Oracle SCN(2)

SCN 号与 oracle 数据库 恢复的关系

SCN 号与 oracle 数据库恢复过程有着密切的关系，只有很好地理解了这层关系，才能深刻地理解恢复的原理，从而才能很好地解决这方面的问题。

SCN 与 CHECKPOINT

CKPT 进程在 checkpoint 发生时，将当时的 SCN 号写入数据文件头和控制文件，同时通知 DBWR 进程将数据块写到数据文件。

CKPT 进程也会在控制文件中记录 RBA(redo byte address), 以标志 Recovery 需要从日志中哪个地方开始。与 checkpoint 相关的 SCN 号有四个，其中三个存在控制文件中，一个存放在数据文件头中。

这四个分别是：

1.System Checkpoint SCN

当 checkpoint 完成后， ORACLE 将 System Checkpoint SCN 号存放在控制文件 中。我们可以通过下面 SQL 语句查询：

select checkpoint_change# from v$database;

2.Datafile Checkpoint SCN

当 checkpoint 完成后， ORACLE 将 Datafile Checkpoint SCN 号存放在控制文件 中。我们可以通过下面 SQL 语句查询所有数据文件的 Datafile Checkpoinnt SCN 号。

select name,checkpoint_change# from v$datafile;

3.Start SCN 号

ORACLE 将 Start SCN 号存放在数据文件头 中。

这个 SCN 用于检查数据库启动过程是否需要做 M edia Recovery .

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

select name,checkpoint_change# from v$datafile_header;

4.End SCN (Stop SCN) 号

ORACLE 将 End SCN 号存放在控制文件 中。

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

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

select name,last_change# from v$datafile;

在数据库正常运行的情况下，对可读写的， online 的数据文件，该 SCN 号为 NULL.

我们作个小的试验，内容如下：

在执行检查点进程之前 SCN 号如下：

System Checkpoint SCN 4609061

--select checkpoint_change# from v$database;

Datafile Checkpoint SCN 4609061

--select name,checkpoint_change# from v$datafile;

Start SCN 4609061

--select name,checkpoint_change# from v$datafile_header;

End SCN 空

--select name,last_change# from v$datafile;

执行 alter system checkpoint 。后的 SCN 号如下：

System Checkpoint SCN 4609630

--select checkpoint_change# from v$database;

Datafile Checkpoint SCN 4609630

--select name,checkpoint_change# from v$datafile;

Start SCN 4609630

--select name,checkpoint_change# from v$datafile_header;

End SCN null

--select name,last_change# from v$datafile;

SCN不连续原因可能如下：

1. 当发生日志组切换的时候

2. 当符合 LOG_CHECKPOINT_TIMEOUT ， LOG_CHECKPOINT_INTERVAL ， fast_start_io_target,fast_start_mttr_target 参数设置的时候

3. 当运行 ALTER SYSTEM SWITCH LOGFILE 的时候

4. 当运行 ALTER SYSTEM CHECKPOINT 的时候

5. 当运行 alter tablespace XXX begin backup ， end backup 的时候

6. 当运行 alter tablespace ,datafile offline 的时候;

SCN 号与数据库启动

在数据库启动过程中，当 System Checkpoint SCN 、 Datafile Checkpoint SCN 和 Start SCN 号都相同时，数据库可以正常启动，不需要做 media recovery. 三者当中有一个不同时，则需要做 media recovery 。如果在启动的过程中， End SCN 号为 NULL ，则需要做 instance recovery 。 ORACLE 在启动过程中首先检查是否需要 media recovery ，然后再检查是否需要 instance recovery 。

SCN 号与数据库关闭

如果数据库的正常关闭的话，将会触发一个 checkpoint ，同时将数据文件的 END SCN 号设置为相应数据文件的 Start SCN 号。

当数据库启动时，发现它们是一致的，则不需要做 instance recovery 。在数据库正常启动后， ORACLE 会将 END SCN 号设置为 NULL 。如果数据库异常关闭的话，则 END SCN 号将为 NULL.

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

为什么 ORACLE 会在控制文件中记录 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 的原因之一。

这里需要一提的是，当重建控制文件的时候， System Checkpoint SCN 为 0 ， Datafile Checkpoint SCN 的数据来自于 Start SCN 。根据上述的描述，此时需要采用 using backup controlfile 做 recovery 。

重建控制文件，重建方式分两种（ resetlogs 和 noresetlogs） （此段内容来自：http://space.51CTO提醒您，请勿滥发广告!/12361284/viewspace-346 ）

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 子句了。

关于 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 才可以这样！ )。

备份的控制文件不能自动进行完全恢复

可以手工apply 日志进行完全恢复

 

重新创建的可以自动进行完全恢复（By biti ）