Oracle在歸檔模式下，可以使用使用者管理的熱備份。

執行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操作覆蓋。

原文地址：
http://blog.chinaunix.net/uid-182041-id-84238.html

個人理解
首先，需要開啟歸檔模式。
    髒塊寫入資料檔案的時候，同時寫入redo log
    作業系統複製資料檔案的同時，Oracle還在不斷寫入髒塊，所以資料檔案本身是不一致的
    begin backup凍結資料檔案頭的SCN，恢復應該從此SCN開始,應用redo log，遇到損壞的塊，則從redo log中查詢
end backup結束備份之後，則解凍資料檔案頭的SCN資訊。

Oracle使用者管理熱備份原理

相關文章