共用方式為


壓縮資料庫

資料庫中的每個檔案都可以縮小,以移除未使用的分頁。雖然「Database Engine」會有效率地重複使用空間,但有時候檔案並不需要原來那麼大,可能就需要壓縮檔案。資料和交易記錄檔都可以縮小或壓縮。您可以用群組或個別的方式來手動壓縮資料庫檔案,或是設定依指定的時間間隔來自動壓縮資料庫。

檔案必定從結尾處進行壓縮。例如,若您有一個 5 GB 的檔案,並且在 DBCC SHRINKFILE 陳述式中指定 4 GB 做為 target_size,Database Engine 就會從檔案的最後 1 GB 中盡量釋出空間。若釋出的檔案部分中有用過的頁面,Database Engine 會先將這些頁面重新配置給保留的檔案部分。您只能將資料庫壓縮至完全沒有可用空間剩下為止。例如,若 5 GB 的資料庫擁有 4 GB 的資料,而您指定 3 GB 做為 DBCC SHRINKFILE 陳述式的 target_size,那麼就只會釋出 1 GB。

自動壓縮資料庫

AUTO_SHRINK 資料庫選項已經設為 ON 時,Database Engine 會自動壓縮含有可用空間的資料庫。您可以用 ALTER DATABASE 陳述式來設定此選項。依預設,此選項設定為 OFF。「Database Engine」將會定期檢查每個資料庫中的空間使用狀況。如果資料庫的 AUTO_SHRINK 選項設定為 ON,「Database Engine」就會縮減資料庫中的檔案大小。此活動會在背景執行,不會影響資料庫中任何的使用者活動。

若要將資料庫設定為自動縮小

ALTER DATABASE (Transact-SQL)

手動壓縮資料庫

您可以使用 DBCC SHRINKDATABASE 陳述式或 DBCC SHRINKFILE 陳述式來手動壓縮資料庫或資料庫中的檔案。若 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 陳述式無法回收記錄檔中所有的指定空間,陳述式將發出一個參考用訊息,指出您必須執行什麼動作,才能釋出更多的可用空間。如需有關壓縮記錄檔的詳細資訊,請參閱<壓縮交易記錄檔>。

在這個程序中,隨時可以停止 DBCC SHRINKDATABASE 和 DBCC SHRINKFILE 作業,任何已完成的工作都會保留下來。

使用 DBCC SHRINKDATABASE 陳述式時,無法將整個資料庫壓縮成比其原始大小還要小。因此,如果資料庫建立時為 10 MB,而後擴充到 100 MB,則該資料庫最多只能縮小到 10 MB (即使該資料庫中的所有資料都已刪除)。

但是,您可以使用 DBCC SHRINKFILE 陳述式,將個別的資料庫檔案壓縮成比剛建立時小。您必須個別壓縮每個檔案,不要嘗試縮小整個資料庫。

[!附註]

當資料庫或交易記錄正在進行備份時,您不能壓縮資料庫或交易記錄。相對地,當您嘗試壓縮資料庫或交易記錄時,也不能建立資料庫或交易記錄備份。

若要壓縮資料庫

若要壓縮資料檔或記錄檔

壓縮交易記錄

交易記錄檔的壓縮限制是固定的。記錄中的虛擬記錄檔大小決定了可縮減的大小。因此,記錄檔絕不能壓縮成比虛擬記錄檔還小。此外,記錄檔縮減的累加單位即等於虛擬記錄檔的大小。例如,1 GB 的交易記錄檔可由五個 200 MB 的虛擬記錄檔所組成。壓縮交易記錄檔會刪除未使用的虛擬記錄檔,但至少會留下二個虛擬記錄檔。因為在這個範例中,每個虛擬記錄檔的大小為 200 MB,所以交易記錄最多只能縮小成 400 MB,且一次只能增量 200 MB。若想要能夠將交易記錄檔的大小縮減,請建立一個小型的交易記錄檔,然後讓它自動擴充,而不要一次就建立一個大型的交易記錄檔。

DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 作業會立即嘗試將交易記錄檔壓縮成要求的大小 (受制於捨入)。您應先將記錄檔備份,再壓縮檔案來減少邏輯記錄檔的大小,並且將不含任何邏輯記錄部分的虛擬記錄檔標示成非使用中。如需詳細資訊,請參閱<壓縮交易記錄檔>。

最佳作法

當您計畫壓縮資料庫或檔案時,請考量下列資訊:

  • 壓縮作業在截斷資料表或卸除資料表等產生大量未用空間的作業之後最有效。

  • 大部分資料庫都需要一些空間來執行每天的例行作業。如果您反覆壓縮資料庫,發現資料庫再次增長,就表示例行作業需要被壓縮的空間。在這些情況之下,反覆壓縮資料庫是一項會造成浪費的作業。

  • 壓縮作業不會保留資料庫中索引的片段狀態,它通常會使片段增加到某個程度。例如,在重建索引之後,您就不應該壓縮資料庫或資料檔。這就是不要反覆壓縮資料庫的另一個原因。

  • 除非您有特定的需求,否則請不要將 AUTO_SHRINK 資料庫選項設定為 ON。

以資料列版本控制為基礎的隔離等級和壓縮作業

壓縮作業可能會被在以資料列版本控制為基礎之隔離等級底下執行的交易封鎖。例如,當 DBCC SHRINK DATABASE 作業執行時,如果以資料列版本控制為基礎的隔離等級之下正在進行大量刪除作業,則壓縮作業將會等到刪除作業完成之後,才會開始壓縮檔案。當這種情況發生時,DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 作業在第一個小時內,會每隔五分鐘列印一次參考用訊息 (SHRINKDATABASE 是 5202,SHRINKFILE 是 5203) 到 SQL Server 錯誤記錄檔中,之後則會每小時列印一次。如需詳細資訊,請參閱<DBCC SHRINKDATABASE (Transact-SQL)>。