一, 數據庫復制
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認證的硬件上才支持故障恢復。 另一個問題是它要求使用共享存儲