One danger in making online backups is the possibility of inconsistent data within a
block. For example, assume that you are backing up block 100 in datafile users.dbf.
Also, assume that the copy utility reads the entire block while DBWR is in the middle
of updating the block. In this case, the copy utility may read the old data in the top
half of the block and the new data in the bottom top half of the block. The result is
called a fractured block, meaning that the data contained in this block is not
consistent. at a given SCN.
When performing backups of an open tablespace without using RMAN, you must put
tablespaces in backup mode to prevent the creation of fractured blocks in your
backup. When not in backup mode, the database records only changed bytes in the
redo stream. When a tablespace is in backup mode, each time a block is changed the
datbase writes the before-image ofthe entire block to the redo stream before modifying
the block. Then, the database also records the changes to the block in the redo log.
During user-managed recovery using SQL*Plus, the database applies both the
captured block images and the recorded block changes from the redo logs. Applying
the block images repairs any possible fractured blocks in the backup being restored
and recovered.
RMAN does not require that you put datafiles into backup mode. During an RMAN
backup, a database server session reads each block of the datafile and checks whether
each block is fractured by comparing the block header and footer. If a block is
fractured, the session re-reads the block. If the same fracture is found, then the block is
considered permanently corrupt. If MAXCORRUPT is exceeded, the backup stops.
----------------------------------------------------------------------------------From Rman Advanced user guaid.
http://hi.baidu.com/dba_james/blog/item/432e8f8e34c86ee8f11f36f1.html
試驗
我的理解：
1 備份開始時，就是begin backup是的scn就是整個備份過程從開始scn。這個是鎖定的
2 在這個scn後，數據文件發生了讀寫，那麼這個數據文件和開始備份時肯定是不一致了的。
這個不一致的文件cp出來就是“錯誤的”，不一致的。
3 解決這個問題就是要把讀寫的操作記錄到redolog中。
當恢復的時候，是對cp出來的不一致的數據文件做了恢復的（通過記錄的redolog）。也就是說在恢復的最最開始的是，很可能要做的是恢復cp出來的數據文件本身。
這個時候的redo是很重要，但是備份時候又沒有備份online redo log，所以要
alter system switch logfile；觸發日誌歸檔，這個時候產生的archived_redo_log很有可能在恢復cp出來的數據塊本身時有用到！
4 所以在做hotcp的時候最好是不要有大量的DML，否則redolog會比較大。
5 Anyway 最好有RMAN
正常情況下，dml發生的時候只寫 數據變化 部分進redo
熱備期間，在block第一次發生變化的時候寫 數據變化部分 + 變化前的整個block進redo
分離的數據塊 就從日誌中把完好的拷貝回來 再恢復啊
歸檔日誌不存在了就不能恢復，若是熱備期間的歸檔日誌不存在了 數據文件中數據根本就不一致，又怎麼能啓動數據庫？
oracle打開數據庫之前要幹什麼？要檢查什麼？熱備的數據文件符合數據庫打開的條件嗎？
在數據庫備份與恢復上有一段恢復原則:
ORACLE要進行兩次檢查:
第一次是看數據文件頭中的檢查點計數器是否與控制文件中的檢查點計數器是否一致,如果相等則進行第二次檢查.若不相等則進行介質恢復.
第二次檢查是對文件頭中的開始SCN(檢查點SCN)與對應控制文件中的結束SCN進行比較,若相等則不需恢復,若不相等進行故障恢復和事務回滾.
所以除了這些數據問家和控制文件一致外，還需要保證所有數據文件文件頭的 檢查點scn一致，並且 所有數據文件頭的 stop scn 一致且和檢查點scn 一樣大，纔是沒有問題 不用恢復可正常打開
數據庫正常運行的時候 stop scn 是無窮大，正常關閉的時候跟檢查點 scn一樣大
異常關閉則依然是無窮大表示數據文件需要恢復
大家在做hotbackup的時候, 一般是
alter tablespace XXXX begin backup;
!cp ....
alter tablespace XXXX end backup;
我們都知道在hotbackup 的同時是允許對正在備份的文件寫入的, 那麼隨着cp的進行, 複製下來的文件從時間的角度看是在不同的時間段有cp 讀出來的, 裏面的數據一定是不一致的. 那麼hot backup如何保證恢復時的一致性呢? 這要從begin backup說起.
begin backup 做了什麼呢? 基本上, 當我們begin backup時, oracle 會把這個ts中的所有數據文件都標記爲hot-backup-in-progress, 同時這個命令會checkpoint這個ts的所有文件. 也就是說, 所有的dirty block 都會被寫回到所屬的數據文件. 這時候, 文件頭中的checkpoint scn 記錄這時的scn. 儘管在整個backup 過程中, oracle 可能會發生多次checkpoint, begin backup 的數據文件的checkpoint scn不會隨之改變, 而其它文件的scn會被更新, 也就是說, begin backup的文件的scn被鎖定於開始備份的scn. 雖然checkpoint 不會改變備份文件的頭, checkpoint還是會把數據寫入到這些文件中去, 也就是說, cp複製的文件無論如何都是不一致的. 那麼怎樣保證我們恢復的時候, 能夠恢復到開始備份時的scn呢? 原來當備份中的文件中的某個塊發生第一次修改的時候, oracle會把這個塊(與開始備份時的數據一致)複製到redo log中. 當我們在恢復的時候, oracle 會把redolog 應用到這些數據文件, 相當於把這些修改過的塊的數據再複製會數據文件. 從而, 把文件恢復到開始備份是的一致狀態. (類似恢復的過程？)有個內部init parameter _LOG_BLOCKS_DURING_BACKUP控制是否將block寫到redo log.這個參數默認是true.
相關的幾個視圖
v$backup
v$datafile_header
v$log
來自：http://www.dev-club.com/club/bbs/essence,27479.htm
在Oracle備份中,我們可以使用alter tablespace ... begin backup將表空間置於聯機備份模式,然後用操作系統命令進行數據文件的物理拷貝,達到備份的目的,這個過程中數據文件還是照樣聯機,並進行正常的數據 插入,但會導致比平常更多的REDO記錄的產生產生較多的REDO記錄是由熱備引起的,因爲在熱備過程中,我們採用copy/ocopy 命令,這個是屬於操作系統的命令,他和Oracle是不相關的,不能和Oracle的內部進程如dbwr進行交互,這樣就可能導致熱碑塊的出現,因爲操作系統讀取數據文件時,他的IO尺寸並不是block size的大小,一般會更小,這樣會導致一個數據塊被讀取多次,而每次獲取的部分都不一致(數據不斷更新),爲了恢復這種斷裂的熱碑塊,Oracle進行 了數據塊前映象這個操作,對於backup模式的數據文件塊,在第一次受到DML影響時,先將數據塊整個COPY到REDO中,後續的DML在進行 UNDO,正常REDO信息的記錄,當恢復數據文件時,會先應用最先的數據塊前映像,然後纔是後續的REDO記錄信息,更多的日誌記錄就是這個前映像產生 的,這個不能和UNDO弄混淆,他是整個數據塊,而不是簡單的行記錄,由於Oracle本身不知道在拷貝時那些塊可能出現熱碑,所以只要是BACKUP期 間有DML的塊,就按照上面的情況處理,所以如果在backup期間運行大量的批處理程序,日誌信息會急劇增多（使用RMAN可以減少redolog的產生）
還有就是爲什麼alter tablespace ... begin backup要凍結文件頭的SCN?
這 個主要是以後數據文件做恢復的起始SCN,在BEGIN BACKUP下達後,系統要對錶空間執行檢查點,並將該檢查點前的所有事務應用都固化到數據文件,然後凍結這個SCN,直到使用END BACKUP,使備份過程結束,再更新爲新的SCN,凍結的原因是因爲使用操作系統命令拷貝數據文件時,他不能保證第一個讀取的塊就是數據文件頭,如果不 凍結,則可能從備份開始,已經多次更新了文件頭,而此時文件頭還沒有被拷貝,這樣等文件頭被拷貝後,他的SCN已經遠遠大於了數據文件中其他數據塊的 SCN,這樣從文件頭的SCN來定位恢復起點就不現實了
從上面可以看出,熱備與RMAN的聯機備份是存在本質區別的,RMAN是連接目標 數據庫,產生Oracle用戶進程,調用他自身的過程包,與dbwr進行交互,使用Oracle的SGA或PGA進行備份,這樣他首先會保證每個塊都是一 致的,不會出現熱碑現象,這樣就減少了REDO記錄的產生,他也不需要凍結文件頭SCN,因爲RMAN總是能先讀取數據文件頭的塊,做爲DBA,RMAN 工具都不會使用的話是很可笑的!!!
講解很詳細的一篇文章
http://www.itpub.net/viewthread.php?tid=188490&extra=&page=1
鏈接：http://hi.baidu.com/dba_james/blog/item/1be8ac2ac515dafce7cd406e.html