Freeze file header,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被凍結。