我不是DBA，所以這可能是一個愚蠢的問題，但我會問它。我們將我們的SQL Server從2000年升級到2005年，我們可能會使用數據庫複製或數據庫鏡像。我們的DBA想要「多用途」備用服務器，這意味着他希望通過在備用服務器上運行其他數據庫應用程序來增加我們的功能和容量，因爲「無論如何它都會坐在那裏」（他的話，不是我的） 。這是一個好主意嗎？目前，我們的主應用程序服務器只使用一個包含50多個數據庫的實例。據我瞭解，我們現在正在做什麼以及我們的DBA提出的故障切換服務器是一個壞主意，因爲所有這些數據庫都共享內存，CPU和工作區域。如果一個應用程序開始表現不好，其他數據庫可能會受到影響。多用途故障轉移服務器？
有什麼想法？
這真的是一個業務問題，需要回答？是一個緩慢的應用程序，如果你無法負擔額外的硬件費用，那麼應用程序就沒有應用程序？
備用和鏡像數據庫可用於報告。如果你有足夠的空間（即兩個數據庫都能舒服地在服務器上運行），使用它作爲故障轉移分區可以工作。
你會依賴這些額外的應用程序嗎？他們在故障轉移情況下運行在哪裏？
你真的需要了解你的失敗模式。
如果將其視爲基礎資源數學，那麼除非您在故障場景中運行的資源能夠處理整個預期負載，否則這通常並不合理。有時候是這樣，但並非總是如此。在這種情況下，爲了處理實際的負載，你可能需要另外一臺服務器（比如RAID--也許你的負載至少需要5臺服務器，但你有一個6臺服務器，那麼你需要一臺備用服務器，在1以上失敗）。有時候一個農場可能會退化，但有時他們只是嘔吐而死。
而且在正常操作不正常的情況下，您經常會在事故級聯導致級聯問題時發生意外級聯 - 例如，您的備份磁帶正在忙於從備份恢復服務器（甚至是測試環境 - 沒有真正的「失敗」），現在您的sql server或exhcange服務器（或兩者）不會備份並且日誌已滿。
數據庫鏡像不是我認爲的方式，因爲它僅在數據庫級提供冗餘。因此，您需要根據您提供的信息爲最多50個數據庫配置數據庫鏡像。有可能是因爲如果一個DB在哪裏可以全部失敗，50可能會跟隨，因爲失敗通常發生在硬件層面而不是特定的數據庫。
這聽起來像你應該使用SQL Server Clustering技術。您可以創建一個主動/主動羣集來支持您的需求。
什麼是主動/主動羣集？
主動/主動SQL Server羣集意味着SQL Server正在雙向羣集的兩個節點上運行。每個SQL Server副本獨立運行，用戶可以看到兩個不同的SQL Server。如果羣集中的某個SQL Server應該失敗，那麼SQL Server的失敗實例將故障轉移到其餘的服務器。這意味着那麼SQL Server的兩個實例都將在一臺物理服務器上運行，而不是兩臺。
將此應用於您的方案
然後，您可以拆分SQL服務器，每個節點上的一個活動實例的兩個實例之間的數據庫。如果一個節點發生故障，另一個節點將收到鬆弛，反之亦然。
進一步閱讀
An introduction to SQL Server Clustering
I suspect that you will find the following MSDN thread useful reading also
「這只是不管怎樣都是坐在那裏」
將坐在那裏申請交易...
記下John Sansom的建議。請記住，主動/主動羣集需要兩個sql server許可證，故障轉移羣集/鏡像只需要一個。
爲大量數據庫設置鏡像可能會變成一大痛苦。您還需要任何作業/維護，以便通過WMI故障切換事件發出警報來實現。可能還有更多的想法會讓事情變得複雜。
serverfault.com可能是這個問題的一個更好的地方 – 2009-06-02 16:24:59
當你說DB應用程序，你的意思是IIS或報告服務/ SSIS？ – Sam 2009-06-02 19:50:21