重建控制檔案後，各檔案（datafile、control file、redo log）中scn的關係
很久之前看了一個論壇上的帖子，談論到到本文的主題，但是我覺得帖子上說的不足以讓人信服。今天想起來了，就自己動手做做實驗。
實驗方法：
0:backup control file to trace
1:update一張表2000條記錄，commit
2:shutdown abort
3:startup nomount
4:重建控制檔案
5:dump 控制檔案頭，資料檔案頭，redo檔案
6:recover database
7:dump 控制檔案頭，資料檔案頭，redo檔案
8:open 資料庫
下面列出部分實驗過程中的資料：
第5步dump檔案結果（片段）：
controlfile :
Controlfile Creation Timestamp 07/20/2016 02:06:03
Database checkpoint: Thread=1 scn: 0x0000.00fbb8cc --與current的redo日誌的低scn一致
Controlfile Checkpointed at scn: 0x0000.00000000
控制檔案記錄的checkpoint process部分:
THREAD #1 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 917640505 mount id: 898487178
控制檔案記錄的資料檔案部分:
Checkpoint cnt:615 scn: 0x0000.00fbb8cd 07/20/2016 02:01:49
Stop scn: 0xffff.ffffffff 07/20/2016 02:06:03
datafile：
status:0x4 root dba:0x00000000 chkpt cnt: 615 ctl cnt:614
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.00fbb8cd 07/20/2016 02:01:49
redofile：
LOG FILE #3:
name #1: /home/oracle/app/oracle/oradata/orcl2/redo03.log
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x19000 seq: 0x00000138 hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0xa dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00fb6971
Low scn: 0x0000.00fbb8cc 07/20/2016 02:01:49
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
第7步dump檔案結果（片段）：
控制檔案沒有變化
datafile:
Checkpoint cnt:614 scn: 0x0000.00fc0810 07/20/2016 02:04:14
Stop scn: 0x0000.00fc0810 07/20/2016 02:04:14
這裡可以看到資料檔案scn已經恢復到一致，這裡貼一段alert日誌，可以看到recover database使用了redo03檔案。
Wed Jul 20 02:56:20 2016
ALTER DATABASE RECOVER database
Media Recovery Start
started logmerger process
Parallel Media Recovery started with 4 slaves
Wed Jul 20 02:56:20 2016
Recovery of Online Redo Log: Thread 1 Group 3 Seq 312 Reading mem 0
Mem# 0: /home/oracle/app/oracle/oradata/orcl2/redo03.log
Media Recovery Complete (orcl2)
Completed: ALTER DATABASE RECOVER database
最後一步open後的dump資訊：
database open
controlfile :
Database checkpoint: Thread=1 scn: 0x0000.00fc0813
Controlfile Checkpointed at scn: 0x0000.00fc084c 07/20/2016 03:33:09
datafile：
Checkpoint cnt:617 scn: 0x0000.00fc0813 07/20/2016 03:33:08
Stop scn: 0xffff.ffffffff 07/20/2016 02:04:14
可以看到控制檔案的資料庫檢查點與資料檔案檢查點一致。控制檔案檢查點略大，原因是因為增量檢查點只更新控制檔案檢查點。
那麼可以認為：重建控制檔案後，控制檔案的檢查點來自於redo檔案。因為recover過程中使用redo檔案恢復資料檔案使其一致。這是noresetlogs的情況。resetlogs的情況後續再實驗。