Freezefileheader
SQL> select * from v$version where rownum=1;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
我們可以使用alter tablespace ... begin backup將表空間置於聯機備份模式,然後用操作系統命令進行數據文件的物理拷貝,達到備份的目的,這個過程中數據文件還是照樣聯機,並進行正常的數據插入,但會導致比平常更多的REDO記錄的產生。產生較多的REDO記錄是由熱備引起的,因為在熱備過程中,我們采用copy/ocopy命令,這個是屬於操作系統的命令,他和Oracle是不相關的,不能和Oracle的內部進程如dbwr進行交互,因為操作系統讀取數據文件時,他的IO尺寸並不是block
size的大小,一般會更小,這樣會導致一個數據塊被讀取多次,而每次獲取的部分都不一致(數據不斷更新，產生split block ),為了恢復這種斷裂的熱備塊,Oracle進行了數據塊前映象這個操作,對於backup模式的數據文件塊,在第一次受到DML影響時,先將數據塊整個COPY到REDO中,後續的DML在進行UNDO,正常REDO信息的記錄,當恢復數據文件時,會先應用最先的數據塊前映像,然後才是後續的REDO記錄信息,更多的日志記錄就是這個前映像產生的,這個不能和UNDO弄混淆,他是整個數據塊,而不是簡單的行記錄,由於Oracle本身不知道在拷貝時那些塊可能出現熱備,所以只要是BACKUP期間有DML的塊,就按照上面的情況處理,所以如果在backup期間運行大量的批處理程序,日志信息會集聚增多，這個主要是以後數據文件做恢復的起始SCN,在BEGIN
BACKUP下達後,系統要對表空間執行檢查點,並將該檢查點前的所有事務應用都固化到數據文件,然後凍結這個SCN,直到使用END BACKUP,使備份過程結束,再更新為新的SCN,凍結的原因是因為使用操作系統命令拷貝數據文件時,他不能保證第一個讀取的塊就是數據文件頭,如果不凍結,則可能從備份開始,已經多次更新了文件頭,而此時文件頭還沒有被拷貝,這樣等文件頭被拷貝後,他的SCN已經遠遠大於了數據文件中其他數據塊的SCN,這樣從文件頭的SCN來定位恢復起點就不現實了。（http://blog.itpub.net/7728585/viewspace-545610）
下面我們模擬這個過程（以system表空間為例）：
SQL> alter session set events 'immediate trace name file_hdrs level 10';
會話已更改。
SQL> select value from v$diag_info where name='Default Trace File';
VALUE
--------------------------------------------------------------------------------
/u01/app/oracle/diag/rdbms/orcl3939/orcl3939/trace/orcl3939_ora_4862.trc
DATA FILE #1:
name #7: /u01/app/oracle/oradata/orcl3939/system01.dbf
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:1223 scn: 0x0000.0080ab79 05/22/2015 23:01:37
Stop scn: 0xffff.ffffffff 05/21/2015 12:23:57
Creation Checkpointed at scn: 0x0000.00000007 08/13/2009 23:00:53
thread:0 rba:(0x0.0.0)
...
...
Offline scn: 0x0000.000b8337 prev_range: 0
Online Checkpointed at scn: 0x0000.000b8338 09/28/2014 17:41:34
thread:1 rba:(0x1.2.0)
...
...
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
V10 STYLE FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=3848072073=0xe55ceb89, Db Name='ORCL3939'
Activation ID=0=0x0
Control Seq=17079=0x42b7, File size=103680=0x19500
File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM rel_fn:1
Creation at scn: 0x0000.00000007 08/13/2009 23:00:53
Backup taken at scn: 0x0000.00773f1c 05/05/2015 19:12:20 thread:1
reset logs count:0x333ab14e scn: 0x0000.000b8338
prev reset logs count:0x296a3120 scn: 0x0000.00000001
recovered at 05/20/2015 14:09:45
status:0x2004 root dba:0x00400208 chkpt cnt: 1223 ctl cnt:1222
begin-hot-backup file size: 103680
Checkpointed at scn: 0x0000.0080ab79 05/22/2015 23:01:37
thread:1 rba:(0x1ee.2.10)
....
....
======================================================================
SQL> alter tablespace system begin backup;
表空間已更改。
SQL> select * from v$backup where status='ACTIVE';
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- --------------
1 ACTIVE 8440239 22-5月 -15
DATA FILE #1:
name #7: /u01/app/oracle/oradata/orcl3939/system01.dbf
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:1224 scn: 0x0000.0080c9af 05/22/2015 23:58:23
Stop scn: 0xffff.ffffffff 05/21/2015 12:23:57
Creation Checkpointed at scn: 0x0000.00000007 08/13/2009 23:00:53
thread:0 rba:(0x0.0.0)
....
....
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
V10 STYLE FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=3848072073=0xe55ceb89, Db Name='ORCL3939'
Activation ID=0=0x0
Control Seq=17091=0x42c3, File size=103680=0x19500
File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM rel_fn:1
Creation at scn: 0x0000.00000007 08/13/2009 23:00:53
Backup taken at scn: 0x0000.0080c9af 05/22/2015 23:58:23 thread:1
reset logs count:0x333ab14e scn: 0x0000.000b8338
prev reset logs count:0x296a3120 scn: 0x0000.00000001
recovered at 05/20/2015 14:09:45
status:0x2001 root dba:0x00400208 chkpt cnt: 1224 ctl cnt:1223
begin-hot-backup file size: 103680
Checkpointed at scn: V10 STYLE FILE HEADER: 05/22/2015 23:58:23
thread:1 rba:(0x1ee.fe0c.10)
.....
.....
============================================================
SQL> alter tablespace system end backup;
表空間已更改。
SQL> select * from v$backup where status='ACTIVE';
未選定行
DATA FILE #1:
name #7: /u01/app/oracle/oradata/orcl3939/system01.dbf
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:1225 scn: 0x0000.0080c9af 05/22/2015 23:58:23
Stop scn: 0xffff.ffffffff 05/21/2015 12:23:57
Creation Checkpointed at scn: 0x0000.00000007 08/13/2009 23:00:53
thread:0 rba:(0x0.0.0)
.....
.....
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
V10 STYLE FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=3848072073=0xe55ceb89, Db Name='ORCL3939'
Activation ID=0=0x0
Control Seq=17097=0x42c9, File size=103680=0x19500
File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM rel_fn:1
Creation at scn: 0x0000.00000007 08/13/2009 23:00:53
Backup taken at scn: 0x0000.0080c9af 05/22/2015 23:58:23 thread:1
reset logs count:0x333ab14e scn: 0x0000.000b8338
prev reset logs count:0x296a3120 scn: 0x0000.00000001
recovered at 05/20/2015 14:09:45
status:0x2004 root dba:0x00400208 chkpt cnt: 1225 ctl cnt:1224
begin-hot-backup file size: 103680
Checkpointed at scn: 0x0000.0080c9af 05/22/2015 23:58:23
thread:1 rba:(0x1ee.fe0c.10)
.....
.....
Backup Checkpointed at scn: 0x0000.0080c9af 05/22/2015 23:58:23
thread:1 rba:(0x1ee.fe0c.10)
....
....
=========================================
DATA FILE #1:
這裡的內容是來自控制文件
V10 STYLE FILE HEADER:
這裡的內容是來自數據文件頭
數據庫一致性檢驗也是通過比較數據文件頭和控制文件裡的信息，
首先是比較數據文件頭裡記錄的ckpt cnt是否和控制文件記錄的ckpt cnt相等，如果相等，則進行下一步的檢驗，
比較數據文件頭的開始checkpoint scn是否和控制文件的結束checkpoint scn一致，一致則打開數據庫，否則進行恢復。
上面通過轉儲的三部分可以看出，熱備後checkpoint scn到結束熱備都沒有發生改變，但是ckpt cnt沒有被凍結，
在此過程中scn被凍結。
