如何處理 SQL Server 2005 中大量數據庫的報告？
我正在尋找一些關於如何處理我們環境的報告的建議。我們目前有 16 台伺服器和 20 個 SQL Server 2005 實例。我們有超過 6,600 個數據庫，並且在這些實例中不斷增長（每個客戶 1 個數據庫）。我們的大多數數據庫的大小從 200mb 到 7gb 不等，其中大約 60 個數據庫的大小從 11gb 到 110gb 不等。
我們正在使用 SAN 進行儲存，並且在執行影響 IO 的報告時遇到了問題。
我們的一個想法是提取 60 個更大的數據庫，然後使用事務複製來複製這些數據庫並在副本上執行報告。
這將使所有較小的數據庫在沒有較大數據庫壓力的情況下執行。在未來，我們相信不會再有基於我們公司目標的大型數據庫。
有什麼想法嗎？
在我以前工作的商店中，我們有一組輔助伺服器，用於測試我們的恢復。對於我們最繁忙的客戶，我們將恢復今晚的備份，將其標記為只讀，他們明天的報告將連接到該數據庫的副本，以獲取昨天的所有報告。這減輕了大約 90% 的報告工作量，並兼作備份/恢復驗證方法。因此，如果大多數報告不需要今天的數據，您可以考慮使用一些更便宜的硬體來減輕一些生產工作負載 - 如果您不使用 Enterprise 功能，您甚至可以對所有小於 10GB 的數據庫使用 Express。（好吧，我看到它是 2005 年，它的 DB 大小限制較低，但您始終可以將副本向前恢復到 2008/R2。
在 2005 年，我可以想到三種解除安裝報告的策略： 1. 使用日誌傳送（日誌傳送到備用伺服器會在每次恢復時將使用者踢出，所以實際上恢復只能在他們不希望打開時發生，例如晚上。）優勢 - 增量更新。2. 使用完全恢復的舊數據。缺點：完全還原。3. 複製。這提供了最佳的使用者體驗，但更難/需要更多的人力來設置和維護。
撇開 - 只是增加大客戶可用的硬體，調整和隔離它們有什麼好處呢？足夠的磁碟和記憶體？閃光？索引優化？真的，按照今天的標準，它們聽起來並不那麼大（誠然，我還沒有看到你的系統）