隨著表的逐漸增長，您可能會預料到性能會降低，特別是在涉及到表掃描操作時。當行數達到數百萬或數十億時，傳統的解決方案會使用已分區視圖，這種視圖由若干具有相同結構、使用 union ALL 掛接在一起的表組成。此外，還會在適當位置放置 CHECK 約束來區分這些成員表，而這會阻止跨已分區視圖復制數據。如果在 CHECK 約束中使用的列也是主鍵的一部分，則該視圖是可更新的。
如果成員表在其自己的文件組中，則如果這些文件組中的文件分別位于不同的物理驅動器上，那么您會獲得更佳的磁盤性能。這些表甚至也可以位于不同的數據庫中。但是，在SQL Server 2005 中，只要所有數據均在同一個數據庫中，您就可以使用表分區，而表分區實現起來就容易得多了。
但是，假設您已經盡可能地利用了表分區或(本地)已分區視圖，但性能仍然很低。如果您擁有SQL Server 2000 或SQL Server 2005，就可以利用分布式已分區視圖了。主要差別在于，成員表可以位于不同的 SQL Server 實例上，而且這些實例可以安裝在 N+1 群集上。為什么鼓勵您這樣做?如果已分區視圖中的任何一個成員表轉入離線狀態，則整個視圖也將轉入離線狀態。使這些成員成為群集的一部分可以為您提供支持性能和實現負載平衡所需的可靠性。
您真的需要群集嗎?
或許您有一些備用服務器無事可做，但這些服務器不在 Windows 目錄的群集部分中。如果您在這些服務器可用的情況下，只是為了支持群集就必須出去購置新服務器，那么這是一種浪費可恥的行為。
數據庫鏡像可能是最適合替代群集的一種方法。鏡像涉及到三個元素：存儲鏡像數據庫的實例稱為主體;備份服務器稱為鏡像;如果要實現自動故障轉移，還需要第三臺服務器，稱為見證方。簡而言之，主體上的數據庫中的事務會在鏡像中再次運行。當主體出現故障時，如果有見證方，數據庫會自動故障轉移到鏡像。您必須為每個應用程序數據庫設置鏡像，但不能鏡像系統數據庫。
鏡像是單獨的SQL Server 實例，與群集不同的是，鏡像可以位于幾千英里以外。其高速緩存中填充的是由于從主體中復制事務而發生的更新活動。當然，還可以假設，除了從主體接收鏡像事務之外，鏡像上沒有其他活動。既然 SQL Server 已經在鏡像中運行，所以，故障轉移的速度通常要比在群集中快。由于至少有部分高速緩存已準備好，所以，初始性能并不像在群集方案中那樣低。另請注意，當鏡像數據庫發生故障轉移時，主體和鏡像會互換角色。
數據庫鏡像的不足之處是，需要的總磁盤容量是群集的兩倍。如果您想在同步模式下運行且不想丟失任何數據，那么您還會需要更多的 CPU 處理能力。正如我所說的，要想實現高可用性，需要花費很高的成本。
組合方法
由于鏡像與主體之間的距離可以相當遙遠，所以對于災難恢復 (DR) 計劃來說，選擇鏡像是非常明智的。群集是您的第一道防線。但是，如果您要同時利用群集和鏡像，那會出現什么情況呢?在群集故障轉移中，如果您的鏡像配置中有見證方，則當群集 SQL Server 轉入在線狀態時，鏡像會成為主體。但是，請注意，從新主體回到(群集的)新鏡像的故障轉移不是自動進行的。因此，當與群集結合使用時，最好不要對您的鏡像數據庫啟用自動故障轉移。
災難恢復并不是您使用鏡像的唯一原因;當您必須向主體應用服務包或修補程序時，鏡像也是非常有用的。在這種情況下，您可以手動故障轉移到鏡像。在應用服務包或修補程序時，舊的主體服務器暫時處于離線狀態，在新主體上發生的已提交事務會排隊等候，等待被發送回新鏡像(舊主體)。在完成服務包或修補程序的安裝之后將會進行同步。最終，這兩臺服務器將完全處于同步狀態�，F在您便可以在主體和鏡像之間轉換角色了。故障轉移與恢復只需要幾秒鐘的停機時間。您可以使用這種方法將 SQL Server 遷移到另一臺計算機。只是不能實現故障恢復。
虛擬服務器添加靈活性
虛擬化允許您在一臺物理服務器上并行運行一個或多個操作系統。虛擬化軟件為群集概念添加了另外一層功能，因為您可以將軟件加入群集。因此，如果主機正在其上運行的服務器出現故障，則主機及其來賓 OS 會故障轉移到備份節點。這可能是遷移來賓服務器的最簡便方法。補充一點，來賓 OS 不必具有群集功能。因此，您可以在運行于某群集中的 Microsoft Virtual Server 2005 之上的來賓 Windows Server 2003 內部運行 SQL Server Workgroup Edition。實質上，您會間接擁有群集 Workgroup Edition
在控制之下
如果您在負責 SQL Server 實現，您需要確信您的服務器始終處于可用狀態。服務器群集會幫助確保您的服務器始終可用。本文提供了一些來之不易的技巧，以幫助您入門。您可以在“群集資源”邊欄中找到更多有用信息。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
