Ⅰ 資料庫的容災方案有哪幾種，分別有什麼優點和缺點！
簡單的說幾句吧。其實這個解決方案呢，主要是要先考慮成本問題，其他的，技術問題其實都很容易解決，但是企業應用上，最大的限制就是成本。下面以ORACLE資料庫為例，簡單說說。希望對你有所幫助。(資料庫類型並不重要，解決方案都是大同小異。)
1、基於存儲層的容災復制方案
這種技術的復制機制是通過基於SAN的存儲區域網進行復制，復制針對每個IO進行，復制的數據量比較大；系統可以實現數據的同步或非同步兩種方式的復制。對大數據量的系統來說有很大的優勢(每天日誌量在60G以上),但是對主機、操作系統、資料庫版本等要求一致，且對絡環境的要求比較高。
2、基於邏輯卷的容災復制方案
這種技術的機制是通過基於TCP/IP的網路環境進行復制，由操作系統進程捕捉邏輯卷的變化進行復制。其特點與基於存儲設備的復制方案比較類似，也可以選擇同步或非同步兩種方式，對主機的軟、硬體環境的一致性要求也比較高，對大數據量的應用比較有優勢。其目標系統如果要實現可讀，需要創建第三方鏡像。個人認為這種技術和上面提到的基於存儲的復制技術比較適合於超大數據量的系統，或者是應用系統的容災復制。
3、基於oracle redo log的邏輯復制方式
使用這種方式的主要有一些第三方的軟體，以及oracle自己的DATAGUARD 中的logical Standby。目前，國外已經有了很多比較成熟的產品及成功案例，國內也有類似的產品， 但在產品的成熟程度和成功案例上跟國外還有一定的差距。
使用oracle以外的獨立進程，捕捉redo log file 的信息，將其翻譯成sql語句，再通過網路傳輸到目標端資料庫，在目標端資料庫執行同樣的sql。如果其進程趕不上oracle日誌切換，也可以捕捉歸檔日誌中的內容。也有的產品在源端以事務為單位，當一個事務完成後，再把它傳輸到目標端。所有的產品一般都是以表為單位進行復制，同時也支持大部分DDL的復制(主要在oracle9i環境中)。
資料庫的吞吐量太大時，其實據會有較大的延遲，當資料庫每天的日量達到60G或更大時，這種方案的可行性交差；實施的過程可能會有一些停機時間，來進行數據的同步和配置的激活；復制環境建立起來以後，對資料庫結構上的一些修改需要按照規定的操作流程進行，有一定的維護成本。