縮小 sql 數據庫 - 壞主意？
我有一個數據庫，由於一些愚蠢的程式碼問題已經大大增加。它現在是 24GB，其中大部分是非常不必要的日誌資訊（系統生成的調試資訊）。
我的伺服器位於雲託管伺服器上。由於文件大小，我現在有兩個問題：
- 我支付儲存費用。我很樂意為我的核心業務付費，但為愚蠢的數據付費似乎……愚蠢
- 我的備份現在也很大。我每晚進行完整備份，然後將它們發送到 FTP 伺服器。這個過程需要的時間越來越長。
考慮到我的問題，縮小有那麼糟糕嗎？我將重建我的所有索引。我進行了一次試執行，並將我的數據庫降至 6GB。
這個人（我一直相信他是我的 SQL 大師）說這很糟糕……mkay “SQL SERVER – 縮小數據庫很糟糕 – 增加碎片 – 降低性能”
看起來您已經意識到與收縮相關的風險，所以我不再贅述。
由於錯誤或某種形式的大增長而只發生一次，因此一次性收縮就可以了。
做收縮，重建/重組索引，應該就是這樣。
你的數據庫是在
SIMPLE還是在FULL恢復？如果已滿，請確保您經常備份事務日誌以減小日誌文件的大小。
考慮到我的問題，縮小有那麼糟糕嗎？我將重建我的所有索引。我進行了試執行，並將我的數據庫降低到 6gb
網際網路上給出的大多數建議都是複制和傳播的，而不是仔細閱讀整個主題。毫無疑問，縮小數據文件是不好的，但如果你問任何 SQL 大師，他總是會說，“是的，我已經縮小了數據文件”。他還會告訴你“迫使”他這樣做的情景。就像你有一個巨大的數據庫並且你正在歸檔舊記錄。因此，您將數據移出並從數據庫中刪除了舊數據。現在有很多可用空間，您立即需要它；在這種情況下，你別無選擇，只能縮小。
在您的情況下，您最終會為由於愚蠢的程式碼問題而增長的文件支付大量費用。在您的情況下，您可以縮小它。您知道收縮會導致碎片並且您需要重建碎片索引也很好。
整個座右銘是不要讓縮小成為一種習慣，它應該永遠是你回收空間的最後手段
我建議你閱讀Paul Randal關於為什麼收縮不好的文章。他在他的文章中指出了收縮的其他方式，如果您以後遇到類似問題，您可以遵循。