壓縮 tempdb 資料庫
適用於:SQL Server Azure SQL 受控執行個體
本文討論可用來壓縮 tempdb
SQL Server 中資料庫的各種方法。
您可以使用下列任何方法來更改 tempdb
的大小。 本文將介紹前三個選項。 如果您想要使用 SQL Server Management Studio (SSMS),請遵循壓縮資料庫中所述指示。
方法 | 需要重新啟動? | 其他相關資訊 |
---|---|---|
ALTER DATABASE |
Yes | 提供預設 tempdb 檔案大小的完整控制 (tempdev 和 templog )。 |
DBCC SHRINKDATABASE |
No | 在資料庫層級運作。 |
DBCC SHRINKFILE |
No | 可讓您壓縮個別檔案。 |
SQL Server Management Studio | No | 透過圖形化使用者介面壓縮資料庫檔案。 |
備註
根據預設,tempdb
資料庫會視需要設定為自動增長。 因此,此資料庫可能會非預期地及時增長為大於所需的大小。 較大的 tempdb
資料庫大小不會對 SQL Server 的效能造成負面影響。
當 SQL Server 啟動時,tempdb
會使用 model
資料庫的複本重新建立,並且 tempdb
會重設為其最後設定的大小。 設定的大小是使用檔案大小變更運作所設定的最後一個明確大小,例如 ALTER DATABASE
使用 MODIFY FILE
選項或 DBCC SHRINKFILE
或 DBCC SHRINKDATABASE
陳述式。 因此,除非必須使用不同的值或取得大型 tempdb
資料庫的立即解析,否則您可以等候 SQL Server 服務的下一次重新啟動,大小將會減少。
tempdb
活動在進行時,您可以壓縮 tempdb
。 不過,您可能會遇到其他錯誤,例如封鎖、鎖死等等,這可能會導致壓縮無法完成。 因此,為了確保縮減 tempdb
成功,建議您在伺服器處於單一使用者模式或停止所有 tempdb
活動時執行此動作。
SQL Server 只會在 tempdb
交易記錄中記錄足夠的資訊,以便復原交易,但不會在資料庫復原期間重做交易。 這項功能會增加 tempdb
中 INSERT
陳述式的效能。 此外,不必記錄資訊來重做任何交易,因為每次重新啟動 SQL Server 時都會重新建立 tempdb
。 因此,沒有可向前復原或復原的交易。
如需管理與監視 tempdb
的詳細資訊,請參閱容量規劃和監視 tempdb 使用。
使用 ALTER DATABASE 命令
注意
此命令只會在預設 tempdb
邏輯檔案 tempdev
和 templog
上運作。 如果已將更多檔案新增至 tempdb
,可在重新啟動 SQL Server 即服務之後進行壓縮。 啟動期間會重新建立所有 tempdb
檔案。 但檔案為空,並且可移除。 若要移除 tempdb
中的其他檔案,請搭配 REMOVE FILE
選項使用 ALTER DATABASE
命令。
此方法需要您重新啟動 SQL Server。
停止 SQL Server。
在命令提示字元中,以最低組態模式啟動執行個體。 若要這樣做,請遵循下列步驟:
在命令提示字元中,變更為安裝 SQL Server 的資料夾 (取代下列範例中的
<VersionNumber>
和<InstanceName>
):cd C:\Program Files\Microsoft SQL Server\MSSQL<VersionNumber>.<InstanceName>\MSSQL\Binn
如果執行個體是 SQL Server 的具名執行個體,請執行下列命令 (取代下列範例中的
<InstanceName>
):sqlservr.exe -s <InstanceName> -c -f -mSQLCMD
如果執行個體是 SQL Server 的預設執行個體,請執行下列命令:
sqlservr -c -f -mSQLCMD
注意
-c
和-f
參數會讓 SQL Server 以最小組態模式啟動,tempdb
的資料檔案大小為 1 MB,記錄檔的大小為 0.5 MB。-mSQLCMD
參數可防止 sqlcmd 以外的任何其他應用程式接管單一使用者連線。
使用 sqlcmd 連線至 SQL Server,然後執行下列 Transact-SQL (T-SQL) 命令。 用所需大小取代
<target_size_in_MB>
:ALTER DATABASE tempdb MODIFY FILE (NAME = 'tempdev', SIZE = <target_size_in_MB>); ALTER DATABASE tempdb MODIFY FILE (NAME = 'templog', SIZE = <target_size_in_MB>);
停止 SQL Server。 若要執行此操作,請在「命令提示字元」視窗中按下
Ctrl+C
,重新啟動 SQL Server 即服務,然後確認tempdb.mdf
和templog.ldf
檔案的大小。
使用 DBCC SHRINKDATABASE 命令
DBCC SHRINKDATABASE
接收參數 target_percent
。 這是壓縮資料庫之後,資料庫檔案中要保留的所需可用空間百分比。 如果您使用 DBCC SHRINKDATABASE
,可能必須重新啟動 SQL Server。
使用
sp_spaceused
預存程序來判定tempdb
中目前使用的空間。 然後,計算剩餘可用空間的百分比,以做為DBCC SHRINKDATABASE
的參數使用。 此計算是以所需的資料庫大小為基礎。注意
在某些情況下,您可能必須執行
sp_spaceused @updateusage = true
,以重新計算使用的空間,並取得更新的報告。 如需詳細資訊,請參閱 sp_spaceused。請考慮下列範例:
假設
tempdb
有兩個檔案:1,024 MB 的主要資料檔案 (tempdb
.mdf),以及 360 MB 的記錄檔 (tempdb.ldf
)。 假設sp_spaceused
報告主要資料檔案包含 600 MB 的資料。 此外,假設您想要將主要資料檔案壓縮為 800 MB。 計算壓縮之後剩餘可用空間的所需百分比:800 MB - 600 MB = 200 MB。 現在,將 200 MB 除以 800 MB = 25%,即target_percent
。 交易記錄檔會據此壓縮,在壓縮資料庫之後,保留 25% 或 200 MB 的可用空間。使用 SSMS、Azure Data Studio 或 sqlcmd 連線 SQL Server,然後執行下列 Transact-SQL 命令。 用所需百分比取代
<target_percent>
:DBCC SHRINKDATABASE (tempdb, '<target_percent>');
tempdb
上的命令具有 DBCC SHRINKDATABASE
限制。 資料和記錄檔的目標大小不能小於建立資料庫時指定的大小,或小於使用檔案大小變更作業 (例如 ALTER DATABASE
使用 MODIFY FILE
選項) 明確設定的最後大小。 DBCC SHRINKDATABASE
的另一個限制是 target_percentage
參數的計算,及其與目前使用空間的相依性。
使用 DBCC SHRINKFILE 命令
使用 DBCC SHRINKFILE
命令來壓縮個別 tempdb
檔案。 DBCC SHRINKFILE
提供比 DBCC SHRINKDATABASE
更大的彈性,因為您可在單一資料庫檔案上使用,而不會影響屬於相同資料庫的其他檔案。 DBCC SHRINKFILE
接收 target_size
參數。 這是資料庫檔案所需的最終大小。
判定主要資料檔案 (
tempdb.mdf
)、記錄檔 (templog.ldf
) 和新增至tempdb
的其他檔案所需的大小。 請確定檔案中使用的空間小於或等於所需的目標大小。使用 SSMS、Azure Data Studio 或 sqlcmd 連線 SQL Server,然後針對您想要壓縮的特定資料庫檔案,來執行下列 Transact-SQL 命令。 用所需大小取代
<target_size_in_MB>
:USE tempdb; GO -- This command shrinks the primary data file DBCC SHRINKFILE (tempdev, '<target_size_in_MB>'); GO -- This command shrinks the log file, examine the last paragraph. DBCC SHRINKFILE (templog, '<target_size_in_MB>'); GO
DBCC SHRINKFILE
的優勢是可將檔案的大小縮減為小於其原始大小的大小。 您可在任何資料或記錄檔上發出 DBCC SHRINKFILE
。 您無法讓資料庫小於 model
資料庫的大小。
執行壓縮作業時發生錯誤 8909
如果使用 tempdb
,而且如果您嘗試使用 DBCC SHRINKDATABASE
或 DBCC SHRINKFILE
命令來壓縮,視乎您使用的 SQL Server 版本而定,您可能會收到類似下列的訊息:
Server: Msg 8909, Level 16, State 1, Line 1 Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (6:8040) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
此錯誤不會指出 tempdb
中的任何實際損毀。 然而,實體資料損毀錯誤可能有其他原因,例如錯誤 8909,且這些原因包括 I/O 子系統問題。 因此,如果錯誤發生在壓縮作業之外,您應進行更多調查。
雖然 8909 訊息會傳回給應用程式或執行壓縮作業的使用者,但壓縮作業不會失敗。