在SQL Server 2008數據庫中，本身就帶有不少的高可用性解決方案。如可以采用故障轉移群集、數據庫鏡像、日志傳送或者復制等手段來提高數據庫的高可用性。由於解決方案多了，數據庫管理員不得不掌握各個解決方案的優點與缺陷，然後根據企業的實際應用來選擇合適的解決方案。其實，這不僅僅是在考驗解決方案的優劣性，也是在考驗數據庫管理員的能力。
一、數據庫鏡像的優劣分析。
數據庫鏡像是一個軟件解決方案，可以提供幾乎是瞬時的故障轉移，以提高數據庫的可用性。簡單的說，數據庫鏡像解決方案就是設置多個數據庫，在多個數據庫之間進行數據多同步。不同在同一個時間內，只有一個生產數據庫(或者叫做主體數據庫)，而其他數據庫都是備用數據庫(又叫做鏡像數據庫)。當主體數據庫出現故障時，系統會自動切換到鏡像數據庫上。此時這個鏡像數據庫就變為了主體數據庫。由於主體數據庫與鏡像數據庫之間數據進行了實時的同步，所以對於用戶訪問來說，基本不受影響。
鏡像服務器解決方案最大的優點就是可以提供幾乎是瞬時的故障轉移。不過所采用的數據庫鏡像的方案不同，對於這個“瞬時”的影響也是不同的。數據庫鏡像可以具體分為高安全模式與高性能模式。在高安全模式下，主要體現“安全”兩個字，已提交的事務會交給伙伴雙方提交，此時雖然比較安全，大那時會延長事務滯後的時間。而在高性能模式下，事務部需要等待鏡像服務器將日志寫入到硬盤中便可以提交，為此可以最大程度的提高數據庫數據不同的性能。
不過這個解決方案也有一定的缺陷，最主要是其限制條件比較多。如只能夠使用標准服務器;只能夠使用數據庫快照對鏡像服務器進行有限的報告;只能夠使用數據庫單一、重復的副本。如果需要其他的副本的話，在可以在使用數據庫鏡像的同時，采用數據庫的日志傳送功能。可見幾個不同的解決方案可以一起結合使用，吸長補短，以提高數據庫的性能與高可用性。
二、日志傳送的優劣分析。
跟數據庫鏡像一樣，日志傳送也是數據庫級別的操作。通常情況下，可以使用日志傳送來維護相應生產數據庫的一個或者多個備用數據庫。在日志傳送中，這個生產服務器叫做主數據庫服務器，備份服務器叫做輔助數據庫。而在數據庫鏡像解決方案中，這個生產服務器也叫做主數據庫服務器，不過這個輔助數據庫則叫做鏡像數據庫。雖然他們的名字相同，但是實際上代表著同一種含義。日志傳送配置包括一個主服務器(包含主數據庫)，一個或多個輔助服務器(每個服務器包含一個輔助數據庫)和一個監視服務器。每個輔助服務器從主數據庫的日志備份按設置的時間間隔更新其輔助數據庫。日志傳送涉及到主服務器創建主數據庫日志備份和輔助服務器還原日志備份之間用戶可修改的延遲。發生故障轉移之前，必須通過手動應用全部未還原的日志備份來完全更新輔助數據庫。
日志傳送的優勢也很明顯，如最大的優勢可以根據需要來定義數據同步的時間，如可以將延遲的時間定義為從主服務器備份主數據庫日志到輔助服務器必須還原日志備份之間的時間。在某些特定的應用環境中，這個特性會非常的有用。而且，針對單個主數據庫可以在多個服務器實例上支持多個輔助數據庫等等。
不過在有些情況下，這個日志傳送解決方案往往不單獨使用。例如將日志傳送解決方案與數據庫鏡像結合使用。如此的話，這兩個解決方案就能夠各自發揮彼此的優勢，以實現互補的目的。如日志傳送具有支持多個備用數據庫的靈活性。如果需要多個備用數據庫，可以單獨使用日志傳送或將其作為數據庫鏡像的補充。當這些解決方案一起使用時，當前數據庫鏡像配置的主體數據庫同時也是當前日志傳送配置的主數據庫。
三、故障轉移群集的優劣分析。
故障轉移群集由具有兩個或多個共享硬盤的一個或多個節點或服務器組成。各應用程序將安裝到一個稱為資源組的群集服務群集組中。在任何時候，每個資源組都僅屬於群集中的一個節點。該應用程序服務具有一個與節點名稱無關的虛擬名稱，稱為故障轉移群集實例名稱。應用程序可以通過引用故障轉移群集實例名稱與故障轉移群集實例連接。應用程序不必知道哪一節點承載該故障轉移群集實例。跟上面兩個解決方案相比，這個故障轉移群集解決方案可以說是一個基於硬件的解決方案。
故障轉移群集解決方案也有不少的限制條件。有些限制條件跟數據庫鏡像的解決方案是相同的。如兩個方案都只能夠利用數據庫的單個副本;需要在服務器實例范圍內進行方案的實施(在鏡像解決方案中比較確切的說法是需要在服務器作用范圍內進行實施)。另外對於股指群集解決方案中，還有另外的一些限制。如是因為基於硬件的解決方案，為此對於硬件有比較特殊的要求，如要求硬件必須是簽名的硬件等等;另外也不能夠防止磁盤故障等等。其次就是在報告功能上的限制。由於故障轉移群集不致此後備用部分的報告功能，這或多或少讓一些數據庫管理員感到遺憾。
不過與其他解決方案相比，這個故障轉移群集也有很大的優勢。如具有自動監測和故障轉移的特性。如在當前節點不可用時，這個解決方案可以自動監測到這種故障，並可以自動在節點之間進行故障轉移。假設在發生操作系統故障、非磁盤硬件故障或者對操作系統或者數據庫系統進行升級時，可以在故障轉移群集的一個節點上配置 SQL Server 實例，使其故障轉移到磁盤組中的任意其他節點。不僅可以自動監測和故障轉移，有時候出於特定的目的，還可以進行手動故障轉移。如對數據庫服務器進行升級時，可以手動的啟動另外一個節點等等。另外最重要的一點就是可以透明客戶端重定向。
復制解決方案的優劣分析。
在SQLServer數據庫中，復制也是提高可用性的一個常用的解決方案。復制使用發布-訂閱模式。這樣，主服務器(稱為發布服務器)便可向一個或多個輔助服務器(即訂閱服務器)分發數據。復制可在這些服務器間提供實時的可用性和可伸縮性。它支持篩選，以便為訂閱服務器提供數據子集，同時還支持分區更新。訂閱服務器處於聯機狀態，並且可用於報告或其他功能，而無需進行查詢恢復。SQL Server 提供三種復制類型：快照復制、事務復制以及合並復制。這裡需要注意一點，在寫項目文檔的時候，需要注意不同解決方案中對於主服務器與備份服務器的稱呼都是不同的。如果數據庫管理員在制作文檔時發生張冠李戴的情況，雖然他們只是叫法不同，其代表的含義基本上相同。
筆者認為，采用復制這個解決方案，相比其他方案來說，主要的優勢有兩個。一個是可以實現數據刷選，即可以決定在訂閱服務器中保存發布服務器中的哪些數據。訂閱服務器可以使發布服務器的子集，包含其部分數據，而不是全部數據。數據同步的效率就會比較高，因為可能不需要對全部數據進行同步。另外一個優勢就是復制這個解決方案，數據滯後的時間最短，即數據同步最及時。
