ORACLE 熱備begin backup / end backup

標籤：

執行begin backup之後，oracle會把將要備份的資料檔案都標記為hot-backup-in-progress，鎖定所要備份的datafile header的scn，例如此時scn=100，同時redolog中會記住這個scn，其他資料檔案正常使用，scn會繼續增長。之後在備份所要備份的資料檔案過程中，資料檔案是允許寫入和checkpoint，而且可能不止一次checkpoint，而這個過程中的所有操作和checkpoint也會正常記錄到redolog與archivelog中。oracle系統資料檔案最小儲存單元是資料區塊，比如8192bytes，而作業系統的最小儲存單元os快為固定的512bytes，這樣問題就產生了。在oracle執行begin backup之後進行copy操作，這個copy操作底層屬於作業系統的命令，每次只能copy一個os block，假如oracle資料庫的block單位為8192bytes，那麼這個oracle block就由16個os block組成，這裡為了方便理解，我們把他們標記為1--16個os block。copy命令對於資料區塊的拷貝時沒有順序的，也就是說第一次可能copy 1號block，而第二次可能就會copy 16號block。而在這個copy過程中，對於oracle熱備份機制來說對oracle整個的block是允許讀寫，這樣就會產生如下的問題，例如：執行begin backup，oracle鎖定datafile header的scn，假設此時oracle block中儲存的資料室10，敲copy進行複製，系統就會將這個oracle block中的16個os block一個一個地拷貝到備份目錄，假如拷貝到第五個os block時候，如果有資料寫入，例如需要將這個資料區塊中的資料update為20，oracle就會調用dbwr進程對這個資料區塊進行資料修改，同樣dbwr進程也是不順序地將資料寫入這16個os block，所以他就有可能從已經拷貝完的那五個os塊中開始寫資料，也有可能從剩下的11個os block中開始寫資料。如果從剩下的11個os block中開始寫入的話，就會帶來一個嚴重的後果，熱備份copy進行中，而剩下的11個block其中的幾個有可能資料已經改變，這樣copy出來的備份檔案肯定會不一致，copy出來的備份檔案對於這個oracle block來說前5個block是原來儲存資料10的資訊，而後來copy的11個block就有可能儲存的是update之後的資料20的資訊，這樣是絕對不允許的。因此，oracle做了這樣的一個機制，在copy過程中如果需要有資料update，dbwr進程告訴oracle我要update，這時候oracle就會通知備份系統，先把所要寫入的那個oracle block完全鏡像到redo中，redo記錄的是整個資料區塊的鏡像，而不是一條資訊。之後dbwr在開始向這個oracle block中的16個os block隨機寫入資料。這樣，在資料恢複的時候，oracle檢查是從被鎖定的那個scn時刻起開始恢複，如果檢查到那個時間點上的某個oracle block出現上述所說的那種“損壞的block”，他就會將redo中的鏡像在完全copy到這個oracle block，這樣，這個資料區塊就是begin backup的那個時間點時候的完整的資料區塊了，之後redo就可以從這個scn進行向後的恢複工作。這個過程也就解釋了為什麼在熱備過程中有時候redo會急劇增加的現象。結束熱備份end backup之後，oracle解鎖備份的datafile header的scn，自動同系統當前的scn同步，例如此時的scn已經變為1000，那麼備份檔案的scn會與系統自動同步到1000。
因為在備份過程中資料檔案及redo是允許寫入的，因此備份的資料檔案不僅包含scn=100以前的資料，而且還包含scn在100和1000之間的所有操作資料。這就是我上述所說的“損壞的block”。
在資料恢複的時候，將備份的資料檔案複製到oracle系統之後，因為備份檔案的scn是在執行alter database begin backup時候的時間點，也就是scn=100，oracle會在redolog中尋找這個scn，如果這個scn時間點有“損壞的block”，redo先把以前鏡像好的block完全複製回去，然後自動執行scn大於100之後的所有操作及資料，寫入當前資料檔案。而從備份檔案恢複到當前的資料檔案中scn在100和1000之間的資料將會被redo操作覆蓋。《FROM:http://blog.chinaunix.net/uid-182041-id-84238.html》============在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總是能先讀取資料檔案頭的塊。《FROM: http://www.cnblogs.com/froster/archive/2005/11/16/277633.html》 

ORACLE 熱備begin backup / end backup