如何管理大型數據庫？
這是我現在的情況：我正在使用 SQL Server 2012，我有 2 個數據庫，一個是 3.5 GB，另一個是 7.6 GB，我合作的公司將伺服器遷移到一個新的（更好）一，我需要將這些數據庫移動到新伺服器，問題是，這些數據庫在生產環境中，如果我開始壓縮它們，系統就會崩潰，這是因為目前伺服器使用的是99 CPU 和 RAM 資源的百分比。
那麼，為了避免這個問題，當我將這些數據庫移動到新伺服器時，應該如何管理它們呢？
我在想，一旦我移動它們，我是否應該使用按年份的資訊將資訊拆分到單獨的數據庫中？即 DatabaseName_Year (AdventureWorks_2016)。
這是避免在需要時移動大量數據庫文件的好方法嗎？
有沒有更好的方法來管理大型數據庫？
首先，永遠記住“大”在旁觀者眼中。我經常使用 100 - 400 GB 的數據庫。所以你的對我來說似乎沒有那麼大。
也就是說：（大多數）數據庫的主要目的是滿足使用者群的需求，通常是通過某種應用程序。如果應用程序性能良好，那麼與您的數據庫一樣大或遠大於您的數據庫絕對沒有問題。
我通常認為最重要的層次結構是：
- 數據可在可接受的時間內以可接受的損失恢復，以防發生緊急情況/災難（請注意，企業主應在此處定義可接受 - 下載 BrentOzar.com 的First Responder Kit以獲取（在許多其他很棒的東西中）一份清單，以找出什麼上述時間框架是可以接受的。當然，大多數人想要的和他們願意支付的往往是兩件不同的事情……
- 用於測試數據庫或應用程序更改/更新的單獨環境
- 大多數（或所有）使用者可接受（或更好）的性能；
- 易於管理。
請注意，企業主希望將該列表中的第三項放在頂部。當然，直到由於前兩項中的一項被跳過而發生了一些事情。如果上級堅持要更改順序，那沒關係 - 但請確保它已記錄在案，並且您已嘗試讓他們了解所涉及的潛在問題。由於伺服器問題而損失了一天（或更多！）的訂單，或嘗試使用在某些方面嚴重損壞的“更新”應用程序（例如，無法接受訂單，或無法列印出來）運送）是一些人學習的唯一途徑。而且，不幸的是，有些人會責怪 DBA，即使你告訴他們這可能會發生，而他們選擇忽略它。
向前看是件好事，考慮將舊數據從數據庫移動到某種存檔是合理的，即使它不需要立即完成。但是，這是需要與使用者社區代表和企業主一起解決的問題（通常不一樣，請注意）。可能仍需要定期使用較舊的數據；如果它不在應用程序看到的數據庫中，則它不可用。如果您設置一個單獨的介面來獲取舊數據，它仍然不方便（而且，有人可能會混淆，並設法將新數據輸入到存檔數據庫中）。根據日期對錶進行分區可能更合理。舊數據可以移動到一個單獨的文件中，該文件仍然是同一數據庫的一部分。
至於壓縮數據，您在評論中提到您嘗試將數據庫壓縮到 RAR 存檔中。只要伺服器啟動並執行，SQL Server 數據（和日誌）文件就處於活動狀態；如果您嘗試壓縮實際的 .mdf 和 .ldf 文件，您最終會得到一個無效的文件。您應該嘗試備份數據庫。SQL Server 中內置的 BACKUP DATABASE 命令允許您壓縮備份 - 我的備份通常是實際數據大小的 1/6 左右（但您的結果可能會有所不同）。您可以在 SQL Server Management Studio 中右鍵點擊數據庫，選擇“任務”，然後選擇“備份…”。我仍然建議在數據庫使用最少的時期執行此操作，這可能仍然是一個問題，但至少值得一試。
如果備份文件仍然太大而無法輕易地從舊伺服器移動到新伺服器，或者這樣做所涉及的停機時間會令人望而卻步，那麼請考慮採用一種更漸進的方法將數據庫轉移到新伺服器。sog shipping（如 Rafael Piccinelli 的回答中所述）絕對是一種選擇，特別是如果在新環境中移動和設置所有東西可能需要幾天時間。如果移動文件的問題不太嚴重，您可能會從實際的日誌傳送到更簡單的方式：在上線前的幾個小時到一天的任何地方對數據庫進行完整備份；然後，在停機時間開始後立即進行差異備份。您可以在新伺服器上恢復（但未恢復）完整備份，等待差異。該文件可能比您的完整備份小得多，因此將其複製到新伺服器應該更快。一旦它在那裡，將它恢復到新伺服器，恢復數據庫，你應該準備好了。
注意：無論您決定使用哪種方法遷移到新伺服器，請在最終確定上線日期之前至少進行一次成功的測試執行。
我會去
Log Shipping。我可以
1.5TB Database在 2 分鐘內將一個伺服器從一個伺服器遷移到另一個伺服器。創建日誌傳送配置需要一些時間。基本上，您將在主伺服器中配置數據庫，以使用日誌傳送到目標伺服器。在此之後，您只需要停止應用程序一段時間（分鐘），並更改一些字元串以將新伺服器指向新數據庫。這些是我在這個過程中提出的一些問題：
解決問題和配置環境到日誌 Shipping 真的很容易。