1、SCN(System Change Number) ：
SCN是什么？ system change number (SCN)是一个非常重要的标记，Oracle使用它来标记数据库在过去时间内的状态和轨迹。
Oracle使用SCN来保 存所有变化的轨迹。SCN是一个逻辑时钟来记录数据库事件。它非常的重要，并不是只是为了恢复。SCN的最大值是0xffff.ffffffff。SCN有点类似于sequence，Oracle 在SGA中增加它。当一个事务修改或者插入数据，Oracle首先写入一个新的SCN到回滚段中。log writer进程立刻把提交的记录写入到重做日志中，这条提交的记录将拥有唯一的SCN。事实上，把SCN写入到日志，就意味着一个事务的完成。SCN帮助Oracle决定在一次突然中断或者SHUTDOWN ABORT后，是否需要一个崩溃恢复。
每当数据库发生checkpoint，Oracle 写一个START SCN命令到数据文件头。控制文件维护着每个数据文件的SCN，称为STOP SCN，通常是无穷大，每当实例正常关闭（SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE），Oracle会复制数据文件头START SCN到控制文件的STOP SCN。如果是正常的重启数据库，是不需要恢复的，因为控制文件和数据文件的SCN是吻合的。反之，突然中断系统就没法同步SCN，SCN不匹 配，Oracle就认为需要做恢复。 另外Oracle还使用数据块的SCN来维护查询的一致性和多版本。
Checkpoint 是一个数据库事件，用来同步所有的datafile，controlfile和redo logfile。当发出ckpt时（回顾什么时候oracle会发出ckpt呢），ckpt会将检查点时刻的scn写入到控制文件和数据文件头部，同时会促使dbwr进程将data buffer中的所有的脏数据写入到数据文件中。而dbwr进程工作时又会促使lgwr写log buffer中的日志数据到redo logfile中。所以当发出检查点时CKPT，DBWR和LGWR同时工作，三种文件的scn完全一致，从而能保持完全同步。
一次checkpoint包含以下步骤: 1. 把redo buffers的内容刷到redo log中。 2. 在redo log file中留下一个checkpoint记录。 3. 把database buffer cache的变更刷新到磁盘。 4. 在checkpoint完成后，更新数据文件头和控制文件。
Checkpoint的具体工作包括： ? 触发DBWn向磁盘写入Dirty data。 ? 把checkpoint信息更新到datafile header上。 ? 把checkpoint信息更新到control file里。
? Checkpoint做的事情之一是触发DBWn把buffer cache中的Dirty cache磁盘。另外就是把最近的系统的SCN更新到datafile header和control file（每一个事务都有一个SCN），做第一件事的目的是为了减少由于系统突然宕机而需要的恢复时间，做第二件事实为了保证数据库的一致性。
checkpoint 的作用就是 ： 1.减少系统崩溃导致的恢复时间 2.保证数据库的一致性
?确保定期向磁盘写入内存中发生修改的数据块，以便在系统或数据库失败时不会丢失数据 ?缩短例程恢复所需的时间。只需处理最后一个检查点后面的重做日志条目以启动恢复操作 ?确保提交 的所有数据在关闭期间均已写入数据文件
由 CKPT 写入的检查点信息包括检查点位置、系统更改号、重做日志中恢复操作的起始位置以及有关日志的信息等等。
我们来看一下获得当前SCN的几种方式:
1.在Oracle9i中，可以使用dbms_flashback.get_system_change_number来获得
例如:获得系统检查点scn
SQL> select dbms_flashback.get_system_change_number from dual; GET_SYSTEM_CHANGE_NUMBER ------------------------ 2982184
SCN的管理方式
Oracle对SCN的管理，分为单节点和RAC两种方式。
在单节点的实例中，SCN值存在SGA区，由system commit number latch保护。任何进程要得到当前的SCN值，都要先得到这个latch。
RAC/OPS环境中，Oracle通过排队机制(Enqueue)实现SCN在各并行节点之间的顺序增长。具体有两种方法：
Lamport算法：又称面包房算法，先来先服务算法。跟很多银行采用的排队机制一样。客户到了银行，先领取一个服务号。一旦某个窗口出现空闲，拥有最小服务号的客户就可以去空闲窗口办理业务。
Commit广播算法：一有commit完成，最新的SCN就广播到所有节点中。
上述两种算法可以通过调整初始化参数max_commit_propagation_delay来切换。在多数系统(除了Compaq
Tur64 Unix)中，该参数的默认值都是700厘秒(centisecond)，采用Lamport算法。如果该值小于100厘秒，Oracle就采用广播算法，并且记录在alert.log文件中。
2、另外几种重要的SCN：
Commit SCN
当用户提交commit命令后，系统将当前scn赋给该transaction。这些信息都反映在redo buffer中，并马上更新到redo log文件里。
表空间Offline SCN
除了System tablespace以外的任何表空间，当我们执行SQL>alter tablespace…offline normal命令时，就会触发一个checkpoint，将内存中的dirty buffer写入磁盘文件中。Checkpoint完成后，数据文件头会更新checkpoint
scn和offline normal scn值。其中数据库文件头的checkpoint scn值可通过查询列x$kccfe.fecps得到。
如果执行SQL>alter tablespace…offline命令时采用temporary或immediate选项，而不用normal选项时，offline
normal scn会被设成0。这样当数据库重启后通过resetlog方式打开时，该表空间就无法再改回在线状态。
Checkpoint SCN（系统检查点SCN）
当数据库内存的脏数据块(dirty blocks)写到各数据文件中时，就发生一次checkpoint。数据库的当前checkpoint scn值存在x$kccdi.discn中。Checkpoint
scn在数据库恢复中起着至关重要的作用。无论你用何种办法恢复数据库，只有当各个数据库文件的checkpoint scn都相同时，数据库才能打开。
虽然参数“_allow_resetlogs_corruption”可以在checkpoint
scn不一致时强制打开数据库，但是这样的数据库在open后必须马上作全库的export，然后重建数据库并import数据。
Resetlog SCN
数据库不完全恢复时，在指定时间点后的scn都无法再应用到数据库中。Resetlog时的scn就被设成当前数据库scn，redo log也会被重新设置。
Stop SCN
Stop scn记录在数据文件头上。当数据库处在打开状态时，stop scn被设成最大值0xffff.ffffffff。在数据库正常关闭过程中，stop scn被设置成当前系统的最大scn值。在数据库打开过程中，Oracle会比较各文件的stop scn和checkpoint scn，如果值不一致，表明数据库先前没有正常关闭，需要做恢复。
High and Low SCN
Oracle的Redo log会顺序纪录数据库的各个变化。一组redo log文件写满后，会自动切换到下一组redo log文件。则上一组redo log的high scn就是下一组redo log的low scn。则上一组redo
log的high scn就是下一组redo log的low scn。
在视图v$log_history中，sequence#代表redo log的序列号，first_change#表示当前redo
log的low scn，列next_change#表示当前redo log的high scn。
SQL> col recid format 9999
SQL> col requence# format 9999
SQL> col first_change# format 9,999,999,999,999
SQL> col next_change# format 9,999,999,999,999
SQL> select recid,sequence#,first_change#,next_change# from v$log_history where rownum<6;
RECID SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
----- ---------- ------------------ ------------------
484 484 1,928,645,840,091 1,928,645,840,436
485 485 1,928,645,840,436 1,928,645,840,636
486 486 1,928,645,840,636 1,928,778,045,209
487 487 1,928,778,045,209 1,929,255,480,725
488 488 1,929,255,480,725 1,930,752,214,033
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用于检查数据库启动过程是否需要做Media Recovery.
我们可以通过以下SQL语句查询：
select name,checkpoint_change# from v$datafile_header;
4.End SCN (Stop SCN)号
ORACLE将End SCN号存放在控制文件中。
这个SCN号用于检查数据库启动过程是否需要做Instance Recovery.
我们可以通过以下SQL语句查询：
select name,last_change# from v$datafile;
在数据库正常运行的情况下，对可读写的，online的数据文件，该SCN号为NULL.
我们作个小的试验，内容如下：
在执行检查点进程之前SCN号如下：
--select checkpoint_change# from v$database;
System Checkpoint SCN 4609061
--select name,checkpoint_change#
from v$datafile;
Datafile Checkpoint SCN 4609061
--select name,checkpoint_change# from v$datafile_header
Start SCN 4609061
--select name,last_change# from v$datafile;
End SCN空
执行alter system checkpoint。后的SCN号如下：
--select checkpoint_change# from v$database;
System Checkpoint SCN 4609630
--select name,checkpoint_change# from v$datafile;
Datafile Checkpoint SCN 4609630
--select name,checkpoint_change# from v$datafile_header;
Start SCN 4609630
--select name,last_change# from v$datafile;
End SCN null
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和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。
在数据库重新启动的时候，Oracle将文件头中的那个启动scn与数据库文件检查点scn进行比较，如果这两个值相互匹配，oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn。如果这两个值也一致，就意味着所有数据块多已经提交，所有对数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作，此时数据库就可以打开了。当所有的数据库都打开之后，存储在控制文件中的数据文件终止scn的值再次被更改为null，这表示数据文件已经打开并能够正常使用了。
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）
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日志进行完全恢复