Sql-Server
MSSQL 減少備份/事務日誌大小保留時間點恢復
目前與備份大小有關的主要問題 - 我遇到了很多問題，但我發現了相互衝突的場景。我有多個具有相同問題的數據庫，但以一個為例，以下是備份文件 (26.2GB) 的組件：
- 數據 5GB
- 索引 1.2GB
- 事務日誌 20GB
我每 6 小時備份一次事務日誌，這是 1 個大約 6 個數據庫，可驅動相當大容量的 Web 應用程序。每個星期天我們都會重建索引，似乎每次發生這種情況，事務日誌都會再增加 5%。此外，事務日誌的備份根本沒有減少它的大小。
系統需要在備份之間進行時間點恢復的能力，而且重建索引似乎使事務日誌的大小增加了，我並沒有真正看到備份或保留索引的主要好處考慮到它們可以建立在還原上的事務日誌。這可以規避嗎？
最終，我正在尋找一個非常小的事務日誌備份大小以供操作使用，它可以簡單地促進備份間的時間點恢復。我不認為我想在我的事務日誌中有索引，而且我並不擔心它們在我的備份文件中——這太天真了嗎？另外我想知道如何更好地管理該事務日誌的大小 - 我應該更頻繁地備份它，是否有原因它不會減小大小？
我可能錯過了這裡的重點或尋找烏托邦，但我現在迫切需要這個策略的幫助！
編輯：不確定是否有任何區別，但數據庫鏡像處於活動狀態，所有備份等都在主體上執行。
您對事務日誌中的內容沒有那種精細的控制。您可能會在 FULL 和 BULKINSERT 模式之間來回切換。但是，有風險，這是你需要管理的額外事情，我不會這樣做。
備份事務日誌不會縮小事務日誌的大小。您可以手動收縮事務日誌。重複的增長/收縮週期往往會使文件碎片化，由於負面的性能影響，不建議這樣做。
如果您想控制日誌備份的大小，我建議您：
- 比每六小時一次更頻繁地執行日誌備份。這將為您提供更多文件，但平均而言它們應該更小。我在完整模式下執行的大多數係統每隔幾分鐘就會進行一次日誌備份。如果您有自動處理 tlog 備份的方法，那麼文件數量的增加應該不是什麼大問題。請注意，您可以為 SQL 代理作業設置多個計劃。例如，您可以指定在執行緩慢時每 6 小時備份一次 tlog，而在繁忙時每 10 分鐘備份一次。
- 研究壓縮備份文件。一些最新版本的 SQL Server 內置了備份文件壓縮功能，您始終可以使用 SQL Lightspeed 等第三方產品。