熱備份中的DML

在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期間運作大量的批處理程式,日志資訊會集聚增多

還有就是為什麼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工具都不能使用的話是很可笑的!!!