數據庫大小不明

我目前有一個20GB大小的數據庫。我已經運行了幾個腳本顯示每個表的大小（和其他非常有用的信息，如索引的東西），最大的表是110萬條記錄，佔用150MB的數據。我們有不到50個表，其中大部分佔用不到1MB的數據。數據庫大小不明

在查看每個表的大小後，我不明白爲什麼數據庫在縮小後不應該是1GB大小。 SqlServer（2005）報告的可用空間量爲0％。日誌模式設置爲簡單。在這一點上，我主要關心的是，我覺得我有19GB的未使用空間。還有什麼我應該看看？

通常情況下，我不會在意並且會讓這個項目成爲被動的研究項目，除非這種特殊的情況要求我們每週做一次備份和恢復，以便將一份副本放在衛星上（它沒有互聯網，所以它必須手動完成）。我寧願每週複製1GB（或者即使下降到5GB！）也不如每週20GB的數據。

註釋sp_spaceused報告如下：

Navigator-Production 19184.56 MB 3.02 MB

而且它的第二部分：

19640872 KB 19512112 KB 108184 KB 20576 KB

，而我已經發現了一些其他腳本（如從兩個服務器數據庫中的一個在這裏大小的問題，他們都報告上面或下面發現的相同信息）。我使用的腳本來自SqlTeam。下面是頭信息：

* BigTables.sql 
* Bill Graziano (SQLTeam.com) 
* [email protected]<email removed> 
* v1.11

頂部幾個表顯示此（表，列，保留空間，數據，索引，未使用的，等等）：

Activity 1143639  131 MB 89 MB 41768 KB 1648 KB 46% 1% 
EventAttendance 883261  90 MB 58 MB 32264 KB 328 KB 54% 0% 
Person 113437  31 MB 15 MB 15752 KB 912 KB 103% 3% 
HouseholdMember 113443  12 MB 6 MB 5224 KB 432 KB 82% 4% 
PostalAddress 48870  8 MB 6 MB 2200 KB 280 KB 36% 3%

表的其餘部分是任一大小相同或更小。不超過50張桌子。

更新1： - 所有表都使用唯一標識符。通常一個int每行增加1。

我也重新索引了所有內容。
我運行了dbcc shrink命令，並更新了之前和之後的使用情況。一遍又一遍。我發現一個有趣的事情是，當我重新啓動服務器並確認沒有人使用（並且沒有維護過程正在運行，這是一個非常新的應用程序 - 不到一週），當我去運行縮小，每隔一段時間它會說一些關於數據改變的信息。谷歌搜索產生了太少有用的答案，顯然不適用（這是凌晨1點，我斷開了每個人，所以這似乎是不可能的，真的是這樣）。數據通過C＃代碼進行遷移，該代碼基本上查看了另一臺服務器並引發了一些問題。在這個時候，刪除的數量可能在50k以下。即使這些行是最大的行，我想也不會超過100M。
當我通過圖形用戶界面收縮時，它會報告0％可用於縮小，表明我已經將它縮小到可以使用的程度。

更新2：

註釋sp_spaceused '活動' 產量的（這似乎是正確的金錢）：

活動1143639 134488 KB 91072 KB 41768 KB 1648 KB
●填充因子爲90
所有主鍵是整數。
這裏是我用來 'UPDATEUSAGE' 命令：

DBCC UPDATEUSAGE（0）;

更新3：

每Edosoft的請求：圖片111975 2407773 19262184 看來好像圖像表認爲它是19GB部。我不明白這是什麼意思。是否真的 19GB還是被歪曲？

更新4：

談話與一位同事和我發現，這是因爲該網頁，因爲別人在這裏還正式指出的潛力。映像表上唯一的索引是聚簇PK。這是我可以解決的問題嗎？或者我只需要處理它？常規腳本顯示圖像表大小爲6MB。

更新5：

我想我只是將不得不經過進一步的研究來對付它。這些圖像的大小已調整爲大約2-5KB，而在普通文件系統上佔用的空間不多，但在SqlServer上消耗的空間似乎更多。從長遠來看，真正的答案可能會將該表分離到另一個分區或類似的東西。

來源

2008-12-11 Kenny Mann

嘗試此查詢：

SELECT object_name(object_id) AS name, rows, total_pages, 
    total_pages * 8192/1024 as [Size(Kb)] 
FROM sys.partitions p 
INNER JOIN sys.allocation_units a 
    ON p.partition_id = a.container_id

來源

2008-12-11 14:33:22 edosoft

你嘗試DBCC命令縮小目錄？如果您將所有數據傳輸到空目錄，是否也是20GB？

數據庫使用基於頁面的文件系統，所以由於刪除繁重的行，您可能會遇到很多鬆弛（頁面之間的空白空間）：如果dbms期望在該位置插入行，則可能會最好讓這些景點開放。你使用基於unique_identifier的PK有聚集索引嗎？

來源

2008-12-11 08:33:50

您可能還需要更新的SYSTABLES使用您運行查詢，以確保它們是準確了。

DECLARE @DbName NVARCHAR(128) 
SET @DbName = DB_NAME(DB_ID()) 
DBCC UPDATEUSAGE(@DbName)

來源

2008-12-11 08:48:21

你可以嘗試做一個數據庫真空，如果你以前從來沒有做過，那麼這樣做通常會產生很大的空間改進。

希望這有助於。

來源

2008-12-11 08:58:27 adam

你如何做數據庫真空？ – 2008-12-11 12:01:13

我認爲這是一個特定的pgsql，但我可能是錯的。 – Kev 2008-12-11 14:04:54

您是否在「收縮數據庫」對話框中檢查了統計信息？在SQL Server Management Studio（2005/2008）中，右鍵單擊數據庫，單擊任務 - >收縮 - >數據庫。這會告訴你有多少空間分配給數據庫，以及多少分配的空間目前未被使用。

來源

2008-12-11 09:03:02

什麼是您在重新索引中使用的填充因子？它必須很高。從90-100％取決於PK數據類型。如果你的填充因子很低，那麼你將有很多半空的頁面不能縮小。

來源

2008-12-11 14:05:31

你有保證的空間沒有被事務日誌消耗？如果您處於完全恢復模式，則在執行事務日誌備份之前，t日誌不會收縮。

來源

2008-12-12 00:33:35

數據庫大小不明

回答

相關問題