執行個體恢複和介質恢複

來源:互聯網
上載者:User

Crash/Instance Recovery與Media Recovery的本質區別在於:

Crash/Instance Recovery針對需要恢複的執行個體從增量檢查點(incremental checkpoint)開始apply redo應用重做日誌。由於日誌覆蓋的先提條件是完成相關日誌的logfile switch checkpoint,且從定義上說歸檔日誌總是落後於執行個體的檢查點,所以對於crash/instance recovery崩潰或執行個體恢複總是只需要訪問讀取線上的重做日誌(online redo logfile)。

 

介質恢複Media Recovery從舊資料檔案的檢查點開始apply redo引用重做日誌,這些舊的資料檔案可能來源於備份。 介質恢複情況下需要用到歸檔重做日誌,因此RMAN或DBA(使用者管理的備份)也需要將備份相關的歸檔日誌還原出來。

 

Crash/Instance Recovery總是保證僅當所有的持久重做資料被應用之後才算恢複完成。 在Oracle保證所有已提交的事務都已經被包含恢複的情況下,才認為崩潰執行個體完成了恢複工作。

 

相反,介質恢複有不完全恢複(incomplete recovery)和部分恢複(partial recovery)的提法,以實現恢複資料庫(db)到某個時間點的一致性。

 

 

Crash/Instance Recovery與Media Recovery的相同點在於:

 

Crash/Instance Recovery與Media Recovery都是傳統的前滾恢複方式(rolling forward),原理上都是對持久redo log資料的重演。 不管是Crash/Instance Recovery還是Media Recovery的前滾,都需要繼之以交易回復以便復原未提交的事務,雖然前滾完成後資料庫即可以開啟而不用等復原完成,但是僅在復原完成的時候我們認為資料庫是真正一致的。


個人的理解:

從字面理解,執行個體恢複就是instance recovery 原因是instance failure,介質恢複media原因是media failure

執行個體恢複就是說資料庫發生故障(instance crash),或者shutdown abort,startup force的情況下,buffer chache的資料沒能寫到資料檔案,也就是說

資料檔案的頭部scn號和當前執行個體的scn號不一致,需要從當前redo裡面前滾,保證buffer cache的資料寫入到資料檔案,而資料庫在實力崩潰前的一直狀態,執行個體恢複一般是資料庫重新啟動的時候自動應用redo,一般是由smon完成,不需要使用者幹預

而介質恢複就是說儲存介質發生損壞,必須顯示的從備份或者歸檔日誌裡面恢複資料庫,比如recover database,recover tablespace ,recover datafile

是可以進行不完全恢複或者說部分恢複,不一定是恢複到資料庫最新的scn號


相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.