方案一：DataGuard

DataGuard是性價(jià)比最高的備份和容災(zāi)方案，但是當(dāng)歸檔超過一定規(guī)模之后，DG的恢復(fù)就成為了瓶頸，每天產(chǎn)生的歸檔無法及時(shí)恢復(fù)完，我們也嘗 試過很多調(diào)優(yōu)的方法，包括并行恢復(fù)，都無法解決，恢復(fù)的瓶頸不在存儲的吞吐量，而在于standby的恢復(fù)方式，因?yàn)榛謴?fù)的過程就是應(yīng)用歸檔文件，RAC 各個(gè)節(jié)點(diǎn)產(chǎn)生的歸檔必須在一個(gè)節(jié)點(diǎn)恢復(fù)，這個(gè)過程必須是遵循一定順序的，大大限制了恢復(fù)的并發(fā)速度。

方案二：傳統(tǒng)RMAN備份

采用傳統(tǒng)RMAN備份，采用大吞吐量的虛擬帶庫設(shè)備，一周全備一次，每天備歸檔日志。很多時(shí)候，我們在做備份方案時(shí)，只考慮了備份，卻沒有考慮恢 復(fù)。這個(gè)方案最大的問題就在于：恢復(fù)的代價(jià)非常高，一旦數(shù)據(jù)庫出現(xiàn)問題，恢復(fù)可能需要數(shù)天之久，這是無法接受的。另外，還要額外購買備份設(shè)備。

方案三：存儲鏡像

數(shù)據(jù)庫采用noarchivelog模式，采用ASM鏡像兩套存儲。這個(gè)方案并不是備份方案，只是為了解決存儲的單點(diǎn)問題而提出的，相當(dāng)于對不同的 存儲做RAID 1。這個(gè)方案最大的問題是無法解決數(shù)據(jù)庫邏輯錯(cuò)誤，比如誤刪除數(shù)據(jù)。因?yàn)橹鲙旌蛡鋷焱ㄟ^存儲鏡像來實(shí)現(xiàn)，無法實(shí)現(xiàn)異地備份和容災(zāi)。

方案四：存儲級別復(fù)制

采用存儲級別的復(fù)制，各存儲廠家都有解決方案，比如EMC SRDF等。Veritas也有類似的解決方案，比如卷復(fù)制(VERITAS Volume Replicator)。這種方案的基本原理都是通過捕獲底層存儲的IO，并通過網(wǎng)絡(luò)同步到備份系統(tǒng)上。如果采用存儲廠商的方案，那么主備庫就必須使用同 一家公司的產(chǎn)品，而且，能否承受每天4.5T的數(shù)據(jù)變化量，我們并沒有驗(yàn)證過。另外，軟件license費(fèi)用不菲。

有人說：能用錢解決的問題不是問題。可是，問題是沒錢！Alibaba雖然不缺錢，但是我們的目標(biāo)就是花小錢辦大事。我個(gè)人也不推薦使用存儲廠商的解決方案，這不僅僅是錢的問題，而是這種方案基本上就是個(gè)黑盒，我們還是喜歡更簡單開放的解決方案。

既然ORACLE DG是性價(jià)比最高的備份和容災(zāi)方案，我們還是想通過DG來解決這個(gè)問題。DG的好處在于可以隨時(shí)打開備份，驗(yàn)證有效，standby延遲恢復(fù)還可以解決邏 輯錯(cuò)誤，防范ORACLE軟件bug可能帶來的損失。解決方案的核心就是要解決DG恢復(fù)速度慢的問題。

方案五：ORACLE DG+塊級別增量備份/恢復(fù)+歸檔

從10g開始，ORACLE提供了一個(gè)功能：塊改變跟蹤（block change tracking），通過bitmap記錄block的變化，通過這個(gè)塊改變跟蹤文件，就知道哪個(gè)block發(fā)生了變化，大大提高了增量備份的效率。具體 方案為：首先為數(shù)據(jù)庫建立一個(gè)0級備份（standby），然后將1級備份應(yīng)用到0級備份上，相當(dāng)于恢復(fù)的過程，這個(gè)恢復(fù)比應(yīng)用歸檔日志要快很多，為什 么？因?yàn)閭浞荻际亲兓腷lock，只要將舊的block覆蓋就可以了，所以不存在日志恢復(fù)過程中的順序問題，所以恢復(fù)的并行度可以很大，可以充分發(fā)揮出 設(shè)備的吞吐能力。另外，當(dāng)一個(gè)block被重復(fù)變更多次時(shí)，增量備份只需要備份最新的block，恢復(fù)也只要覆蓋舊的block即可，定期增量備份實(shí)際可 以減少備份需要的空間使用量。而redo文件中記錄了block變化的記錄，所以應(yīng)用redo恢復(fù)時(shí)需要多次變更該塊，必須保留所有的歸檔文件才可以恢復(fù) 成功。當(dāng)然，應(yīng)用1級備份之后，standby并不能打開，因?yàn)閎lock并不是一致狀態(tài)的（因?yàn)樵隽總浞輹掷m(xù)很長的時(shí)間，在這個(gè)過程中，備份的 block的時(shí)間點(diǎn)是不一致的），所以要利用歸檔文件將standby推到一致的狀態(tài)才可以打開。

我們目前的方案：建立standby數(shù)據(jù)庫，每周做一次增量備份，首先應(yīng)用增量備份，然后應(yīng)用歸檔日志文件將數(shù)據(jù)庫推到一致狀態(tài)，可以打開數(shù)據(jù)庫， 驗(yàn)證備份有效，歸檔日志文件循環(huán)備份到磁帶庫，整個(gè)過程通過腳本實(shí)現(xiàn)自動(dòng)化。這個(gè)方案采用增量備份+archivelog恢復(fù)standby，可以打開 standby驗(yàn)證備份有效，出現(xiàn)故障時(shí)可以直接standby switchover，大大節(jié)省了恢復(fù)的時(shí)間。而且，這個(gè)方案都是基于現(xiàn)有硬件基礎(chǔ)，基本上沒有采購額外的硬件設(shè)備和軟件license，花小錢辦大事。

我的技術(shù)理念：做解決方案就是搭積木，用簡單的技術(shù)去解決問題，并不一定要發(fā)明新的東西，最佳實(shí)踐也是很有價(jià)值的。

–EOF–

后記：這個(gè)問題，我曾經(jīng)在OOW上問過ORACLE的技術(shù)專家，他們也沒有很好的解決方案，建議我們買兩套Exadata來解決（我并沒有搞清楚為 什么Exadata恢復(fù)歸檔的速度會變快，是設(shè)備本身的能力提高了，還是ORACLE恢復(fù)的方式發(fā)生了變化），或者放棄數(shù)據(jù)庫級別的備份，由應(yīng)用程序?qū)懚?份數(shù)據(jù)來解決。所以說，ORACLE也沒有考慮到如此大數(shù)據(jù)量環(huán)境的備份問題，ORACLE可以考慮推廣我們的解決方案。

看到此文后，認(rèn)為不錯(cuò)，特轉(zhuǎn)到此，以此紀(jì)錄。謝謝張瑞（Jacky）