數據庫備份突然變小了
我們的主數據庫的大小已經減少了大約 8 GB。這反映在備份以及當我們查看可用空間與可用空間時。
一切似乎都在工作，我們找不到任何數據失去的跡象，但我們以前從未見過這種情況。我們有點擔心可能會發生一些不愉快的事情。
誰能告訴我們 8 GB 的數據是如何消失的？如果這是正常的事情，我們想了解它是如何發生的，因為能夠將數據庫備份的大小減半實際上有些用處。
我們在 Windows Server 2019 上執行 SQL Server Enterprise 版本 14.0.3391.2
我們的主數據庫每天午夜後都會備份。備份目標是本地磁碟。每次執行備份時，都會為每個數據庫創建一個新文件。我們的恢復模式很簡單。備份未壓縮。至少在過去幾年中，每個備份大約為 15 GB。自 6 月 11 日以來，文件大小已縮減至剛剛超過 7 GB。
在進行一些研究時，DBA StackExchange 上的一個執行緒與某個意外在單個文件中創建多個備份的人有關。我
RESTORE HEADERONLY FROM DISK從 6 月 10 日 (15 GB) 和 6 月 11 日 (7 GB) 開始備份。兩者似乎都包含一個備份。我也沒有看到任何其他值得注意的差異。還原數據庫後，我觀察到目前數據庫和還原數據庫的總大小約為 30 GB。目前數據庫上的可用空間約為 19 GB，而在恢復的數據庫上約為 11 GB。8 GB 的差異，如備份。我們的備份未壓縮。
我們沒有註意到我們非常依賴的應用程序中缺少任何數據。我使用 SSDT 來比較目前數據庫和恢復的數據庫中的模式和數據。
使用此數據庫的應用程序正在不斷開發中，因此在目前數據庫中添加了一些列和表以支持新功能，但沒有刪除。
同樣，在目前數據庫中編輯或刪除了一些行，但相關表在恢復的數據庫中佔不到 100 MB，因此即使它們被完全刪除，也不會導致大約 8 GB 的數據消失。
我們有一個人開發應用程序。數據庫管理由那個人和我共享。我們都不相信我們做了任何會導致這種變化的事情。
我們使用數據庫的方式沒有任何重大變化，如果有的話，備份應該會變得更大。
我們是一家小公司，不太可能有人進行數據清理。這也應該在 SSDT 的數據比較中顯示出來。
我在日誌文件中沒有發現任何暗示未經授權的訪問或備份失敗的內容。
我目前正在從 6 月 11 日 (7 GB) 開始恢復備份，看看這是否能告訴我任何事情，儘管我並不期待從中獲得太多洞察力。
我們不會自動刪除備份，而是手動執行，這就是我們發現大小差異的時候。
我不相信任何索引已被刪除-有人對最佳檢查方法有建議嗎？碎片整理似乎是一個完全可能的原因 - 有什麼方法可以檢查嗎？
檢查數據庫
據我所知，還沒有執行。今天早上跑了。沒有看到任何錯誤，並完成此消息：CHECKDB 在數據庫“MyDatabase”中發現 0 個分配錯誤和 0 個一致性錯誤。
表大小報告
結果非常相似，最顯著的區別是我認為是新表。在較小的實時數據庫中，該表為 900 MB。在更大的還原數據庫中，該表只有 6 MB。我想知道我們是否已經超過了某個觸發某種維護操作的 x% 數據庫使用門檻值。
目前數據庫上的可用空間約為 19 GB，而在恢復的數據庫上約為 11 GB。8 GB 的差異，如備份。我們的備份未壓縮。
您可能會通過檢查表格大小的標準報告之一來發現差異：
右鍵點擊數據庫*> Reports > Standard Reports > Disk Usage by Table*。
您可以按大小排序此報告，並比較原始數據庫和恢復備份的報告。
一些可能會改變事情的線索：
- 刪除了一些非聚集索引 (NCI)。
- 在某些表上添加了聚集列儲存索引。
- 行數的減少會減少索引的大小，尤其是當您有很多 NCI 時；這樣，如果您刪除 100MB 的數據，您甚至可以從索引中釋放 1Gb。
- 對一些嚴重碎片化的索引進行碎片整理。Razvan Socol提供的展示腳本。
- 重建一個因刪除而留下空頁的堆。