不能釋放在SQL Server 2005

未分配空間，我有一個非常大的數據庫（40演出），並運行程序不能釋放在SQL Server 2005

sp_space_used

，發現存在的未分配空間10演出。顯然這是很多的，而.mdf文件佔用了大部分的磁盤空間。我已經研究過運行

DBCC SHRINKDATABASE (db, TRUNCATEONLY);

我是否還需要縮小事務日誌或將shrinkdatabase處理此問題？運行此過程的負面影響是什麼？我可以在數據庫使用時運行它嗎？我試過運行shrinkdatabase命令，但仍然有很多未分配的空間。

database_size unallocated space 
49575.06 MB 8393.49 MB 

reserved  data  index_size unused 
42170328 KB 22704672 KB 19099160 KB 366496 KB

注意：數據庫有一個簡單的恢復模型，所以我猜我根本不需要備份日誌。

是什麼

DBCC SHRINKDATABSE (db, TRUNCATEONLY)?

2010-01-11 jhowe

我結束了使用DBCC SHRINKDATABASE (db, %);指定目標百分比似乎解決了我的問題。

2010-01-26 14:43:23 jhowe

首先讓你的數據庫的任何結構變化採取完整數據庫備份之前運行

DBCC SHRINKFILE (datafile, TRUNCATEONLY)

之間的差異。

如您所說，如果大部分未分配空間駐留在SQL Server數據文件（.mdf）中，則應該使用DBCC SHRINKFILE而不是DBCC SHRINKDATABASE。

因此，例如：

USE UserDB; 
GO 
DBCC SHRINKFILE (LogicalDataFileName, target_sizeInMB); 
GO

另外考慮使用TRUNCATEONLY選項釋放僅從數據文件末尾的可用空間。這是資源密集度較低的選項，但可能無法釋放盡可能多的空間。請記住，如果使用TRUNCATEONLY指定，target_size將被忽略。

您可以運行在生產服務器上此維護但是你可能會遇到增加阻塞，因此應該安排期間低活性的維護停機不是一個選項，給你。用戶仍然可以查詢數據庫。

在你編輯的光：

DBCC SHRINKDATABASE將努力收縮你的數據庫中的所有文件，也就是數據和日誌文件。

DBCC SHIRNKFILE，另一方面提供更好的控制水平，它適用於一個特定的文件。

2010-01-11 13:07:47

我編輯過orignal後，dbcc shrinkfile似乎沒有做任何事情，SQL是否需要磁盤空間才能正確地運行命令？我認爲有幾個100MB，但是這是... – jhowe

然後，也許在文件的末尾沒有可用空間，在這種情況下，您將需要運行沒有TRUNCATEONLY選項的語句。 –

好的，嗯，我仍然無法釋放這個8.5 gig ...我認爲這可能是因爲reindex作業失敗，並且它已經爲autogrowth分配了空間......但不確定。 – jhowe

的註釋sp_spaceused命令包括日誌文件的可用空間爲好。即使您的數據庫日誌模型很簡單，SQL也會使用您的日誌文件來跟蹤事務，並且日誌文件會不斷增長，並且在您運行備份之前它不會縮小。我知道你提到mdf文件佔用了大部分磁盤，但你是否檢查了你的ldf文件大小？你是否也檢查過你的聚簇索引碎片？

如果您發現該日誌文件是大過，嘗試下面的腳本，看看你的數據庫收縮。它用簡單的模型日誌爲我工作。

use [db_name] 
backup log [db_name] with truncate_only 
dbcc shrinkfile ([db_log_filename], 1)

這種說法不會運行的實際備份，它只會截斷日誌，並允許SHRINKFILE刪除日誌文件使用的可用空間。如果您打算在生產環境中運行它，我建議您在非高峯時間使用它。即使它不需要很長時間。這隻會影響日誌文件的大小。

希望這可以幫助，這很清楚爲什麼我會建議你檢查日誌文件。

2010-01-11 16:34:08

我已經運行過這些命令，日誌文件只有7mb ... – jhowe

您提到reindex作業失敗。你知道工作失敗的原因嗎？它有沒有空間用完？ –

清除事務日誌空間（儘管完全備份後）的最快方法是設置爲簡單模式，等待一兩分鐘，然後收縮事務日誌。這會縮小到1MB。然後將其重新開啓爲FULL模式而不是SIMPLE。

2015-09-11 02:33:16

回答