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或更大時，這種方案的可行性交差；實施的過程可能會有壹些停機時間，來進行數據的同步和配置的激活；復制環境建立起來以後，對數據庫結構上的壹些修改需要按照規定的操作流程進行，有壹定的維護成本。