一, 數據庫複製
SQL Server 2008數據庫複製是通過發佈/訂閱的機制進行多臺服務器之間的數據同步，我們把它用於數據庫的同步備份。這裏的同步備份指的是備份服務器與主服務器進行 實時數據同步，正常情況下只使用主數據庫服務器，備份服務器只在主服務器出現故障時投入使用。它是一種優於文件備份的數據庫備份解決方案。
SQL Server的複製分爲種：
1. 快照發布:
發佈服務器按預定的時間間隔向訂閱服務器發送已發佈數據的快照。每隔一段時間將訂閱數據庫中的相應表中的數據全部刪除，然後將自己相應表中的全部插到訂閱數據庫中
使用快照複製本身是最合適的：
1）很少更改數據。
2）在一段時間內允許具有相對發佈服務器已過時的數據副本。
3）複製少量數據。
4）在短期內出現大量更改。
在數據更改量很大，但很少發生更改時，快照複製是最合適的。 例如，如果某銷售組織維護一個產品價格列表且這些價格每年要在固定時間進行一兩次完全更新，那麼建議在數據更改後複製完整的數據快照。 對於給定的某些類型的數據，更頻繁的快照可能也比較適合。 例如，如果一天中在發佈服務器上更新相對小的表，但可以接受一定的滯後時間，則可以在夜間以快照形式傳遞更改。
發佈服務器上快照複製的連續開銷低於事務複製的開銷，因爲不用跟蹤增量更改。 但是，如果要複製的數據集非常大，那麼若要生成和應用快照，將需要使用大量資源。 評估是否使用快照複製時，需要考慮整個數據集的大小以及數據的更改頻率。
2. 事務發佈:
在訂閱服務器收到已發佈數據的初始快照後，發佈服務器將事務流式傳輸到訂閱服務器。
事務複製通常從發佈數據庫對象和數據的快照開始。 創建了初始快照後，接着在發佈服務器上所做的數據更改和架構修改通常在修改發生時（幾乎實時）便傳遞給訂閱服務器。 數據更改將按照其在發佈服務器上發生的順序和事務邊界應用於訂閱服務器，因此，在發佈內部可以保證事務的一致性。
以下各種情況下適合採用事務複製：
1). 希望發生增量更改時將其傳播到訂閱服務器。
2). 從發佈服務器上發生更改，至更改到達訂閱服務器，應用程序需要這兩者之間的滯後時間較短。
3). 應用程序需要訪問中間數據狀態。 例如，如果某一行更改了五次，事務複製將允許應用程序響應每次更改（例如，激發觸發器），而不只是響應該行最終的數據更改。
4).發佈服務器有大量的插入、更新和刪除活動。
5).發佈服務器或訂閱服務器不是 SQL Server 數據庫（例如，Oracle）。
默認情況下，事務發佈的訂閱服務器應視爲只讀，因爲更改將不會傳播回發佈服務器。 但是，事務複製確實提供了允許在訂閱服務器上進行更新的選項
3. 具有可更新訂閱的事務發佈:
在 SQL Server 訂閱服務器收到已發佈數據的初始快照後，發佈服務器將事務流式傳輸到訂閱服務器。來自訂閱服務器的事務被應用於發佈服務器。
4. 合併發佈:
在訂閱服務器收到已發佈數據的初始快照後，發佈服務器和訂閱服務器可以獨立更新已發佈數據。更改會定期合併。Microsoft SQL Server Compact Edition 只能訂閱合併發佈。
與事務複製相同，合併複製通常也是從發佈數據庫對象和數據的快照開始， 並且用觸發器跟蹤在發佈服務器和訂閱服務器上所做的後續數據更改和架構修改。 訂閱服務器在連接到網絡時將與發佈服務器進行同步，並交換自上次同步以來發布服務器和訂閱服務器之間發生更改的所有行。
合併複製通常用於服務器到客戶端的環境中。 合併複製適用於下列各種情況：
1). 多個訂閱服務器可能會在不同時間更新同一數據，並將其更改傳播到發佈服務器和其他訂閱服務器。
2). 訂閱服務器需要接收數據，脫機更改數據，並在以後與發佈服務器和其他訂閱服務器同步更改。
3). 每個訂閱服務器都需要不同的數據分區。
4). 可能會發生衝突，並且在衝突發生時，您需要具有檢測和解決衝突的能力。
5). 應用程序需要最終的數據更改結果，而不是訪問中間數據狀態。 例如，如果在訂閱服務器與發佈服務器進行同步之前，訂閱服務器上的行更改了五次，則該行在發佈服務器上僅更改一次來反映最終數據更改（也就是第五次更改的值）。
合併複製允許不同站點自主工作，並在以後將更新合併成一個統一的結果。 由於更新是在多個節點上進行的，同一數據可能由發佈服務器和多個訂閱服務器進行了更新。 因此，在合併更新時可能會產生衝突，合併複製提供了多種處理衝突的方法
複製的缺點： 表有主鍵，而且表結構日後不能更改，如果架構穩定也是不錯的，如果有很多張表那就比較麻煩了
複製方法及過程：
http://www.cnblogs.com/dudu/archive/2010/08/26/1808540.html
http://www.cnblogs.com/killkill/archive/2009/07/17/1525733.html
http://dufei.blog.51cto.com/382644/84645
http://www.cnblogs.com/wangdong/archive/2008/10/24/1318740.html
二，數據庫鏡像：
數據庫鏡像：
優點是系統能自動發現主服務器故障，並且自動切換至鏡像服務器。
缺點是配置複雜，鏡像數據庫中的數據不可見（在SQL Server Management Studio中，只能看到鏡像數據庫處於鏡像狀態，無法進行任何數據庫操作，最簡單的查詢也不行。想眼見爲實，看看鏡像數據庫中的數據是否正確都不行。只 有將鏡像數據庫切換主數據庫纔可見）
相對於日誌傳送，數據庫鏡像顯然更高一級。在最簡單的形式下，它其實與日誌傳送的工作原理相似，但是生產服務器發送事務到鏡像服務器的頻率要高得多，這意味着更新速度也要快很多。
對於數據庫鏡像來說，故障轉移功能也是需要手動完成。但是你可以添加第三個SQL Server，稱爲witness。Witness可以作爲一個普通的SQL Server，但是一直留意着其它兩個鏡像服務器。當主鏡像發生故障，witness可以讓第二個鏡像接管操作，類似一種自動的故障轉移。
在故障轉移時，任何進行中的客戶端事務都將重新啓動，而由於在這一過程中仍然存在着延遲，鏡像服務器也不能保證百分之百不丟失數據。
三，數據庫日誌傳輸：
作爲高可用性的最低級形式，日誌傳送(log shipping)本質上是SQL Server複製功能的一種延伸
允許解決方案提供商創建多個數據庫副本。日誌傳輸能夠將次數據庫日誌副本同步發送到SQL Server實例上。然後這些日誌會在次服務器上重放，從而保持數據庫副本是最新的。
有一些解決方案提供商使用日誌傳輸作爲克服數據庫鏡像缺點的方法。數據庫鏡像是很好的技術，但是它只允許我們實現一個數據庫副本。鏡像可以接近實時的方式進行，所以數據庫修改可以快速地寫到次數據庫上。如果客戶數據庫損壞或數據庫記錄意外刪除，那麼這可能會造成問題。
日誌傳輸有兩個主要的優點。首先，解決方案提供商能夠實現一種延遲，這樣日誌就不會即時重放。這是很重要的，因爲如果主(或鏡像)數據庫出現問題，日誌可以在重放之前攔截，因此可以防止問題擴散。
日誌傳輸第二個主要的優點是它支持實現多個數據庫副本。有一些單位使用日誌傳輸作爲在備份數據中心維護數據庫副本的方法，這能夠防止主數據中心出現問題時發生數據丟失。
雖然日誌傳輸通過是作爲數據庫鏡像的補充措施，但是它是一種獨立的技術，它可以不依賴於鏡像技術而獨立使用。
http://www.searchdatabase.com.cn/showcontent_11708.htm
四，故障轉移集羣
集羣技術是微軟可用性的最高級形式，它需要你設置一個Windows集羣。
在集羣中並不會涉及傳輸以及鏡像，取而代之，兩臺或更多的電腦將會彼此連接在一個共享的外部存儲器中，通常是存儲區域網絡(SAN)。數據庫文件就存放在這個共享存儲器上，同樣設置的SQL Server實例都運行在集羣節點上。
集羣中的所有節點中，實際上只有一個節點是一直處在活動狀態的，如果這個節點發生故障，其它的節點將啓動相應的SQL Server實例，並連接共享存儲器的數據文件。而整個故障轉移過程往往只有幾秒鐘時間，對於任何給定的SQL Server實例，Windows集羣技術都可以確保客戶端始終注視活動的節點。
集羣技術非常複雜，但它是實現高可用的最高效技術。與前面介紹的兩個功能相比，集羣依賴於一個單一的數據庫文件集。如果這些文件損壞了，故障轉移也不能起作用了，因爲故障轉移的實例同損壞的文件是一樣的。而使用鏡像與日誌傳送，你可以對文件進行實時拷貝，因此不必擔心文件損壞的問題。SQL Server中，文件遭到損壞的情況很少發生，因此我認爲集羣應該還是一個不錯的選擇。
缺點的。其中一個重要的問題是故障恢復的實現是非常昂貴的。Microsoft只在那些通過Windows Server認證的硬件上才支持故障恢復。 另一個問題是它要求使用共享存儲