共用方式為


備份壓縮 (SQL Server)

適用於:SQL Server

本文描述 SQL Server 備份的壓縮,包括限制、壓縮備份的效能取捨、備份壓縮的組態及壓縮比率。 下列 SQL Server 版本支援備份壓縮:Enterprise、Standard 和 Developer。 每個 SQL Server 2008 (10.0.x) 版本與更新版本都可以還原壓縮的備份。

優點

  • 由於壓縮的備份小於相同資料的未壓縮備份,所以壓縮備份通常需要更少的裝置 I/O 而且通常會大幅提升備份速度。

    如需詳細資訊,請參閱本文稍後介紹的壓縮備份的效能影響

限制

下列限制適用於壓縮的備份:

  • 壓縮和未壓縮的備份無法並存於媒體集中。

  • 舊版 SQL Server 無法讀取壓縮備份。

  • NTbackups 無法與壓縮的 SQL Server 備份共用磁帶。

SQL Server 2025 中引進的 ZSTD 壓縮演算法

從 SQL Server 2025(17.x)開始,新增一種壓縮演算法 ZSTD 可用於備份壓縮。 此演算法比先前的MS_XPRESS演算法更快且更有效率。

您可以使用 ZSTD 演算法,以下列其中一種方式進行備份壓縮:

  • 藉由在WITH COMPRESSION (ALGORITHM = ZSTD) Transact-SQL 命令中的選項來指定特定備份
  • 備份壓縮演算法伺服器組態選項 設定為 3。 這個選項會將所有使用選項的備份之預設備份壓縮演算法設定為 ZSTD。

壓縮備份的效能影響

根據預設,壓縮會大幅增加 CPU 使用量,而且壓縮程序所耗用的額外 CPU 可能會對並行作業造成不良的影響。 因此,您可能會想要在由資源管理員所限制之 CPU 使用量的工作階段中建立低優先權的壓縮備份。 如需詳細資訊,請參閱使用 Resource Governor 限制備份壓縮時的 CPU 使用量 (Transact-SQL)

從 SQL Server 2022 (16.x) 開始,您可以使用整合式卸載和加速,來壓縮備份及卸載備份的 CPU 資源。

若要全盤了解備份 I/O 效能,您可以透過評估下列效能計數器種類,隔離往返裝置之間的備份 I/O:

如需有關 Windows 計數器的詳細資訊,請參閱 Windows 說明。 如需如何使用 SQL Server 計數器的相關資訊,請參閱 使用 SQL Server 物件

計算壓縮備份的壓縮率

若要計算備份的壓縮率,請使用 backupset 記錄資料表的 backup_sizecompressed_backup_size 資料行中的備份值,如下所示:

backup_sizecompressed_backup_size

例如,3:1 壓縮比例表示您在磁碟空間上節省約66%。 若要針對這些資料行進行查詢,您可以使用下列 Transact-SQL 陳述式:

SELECT backup_size/compressed_backup_size FROM msdb..backupset;  

壓縮備份的壓縮比取決於已經壓縮的資料。 有許多因素可能會影響取得的壓縮比。 主要的因素包括:

  • 資料的類型。

    字元資料的壓縮比較其他資料類型要高。

  • 頁面上資料列之間的資料一致性。

    一般而言,如果某個頁面包含許多資料列,而且其中某個欄位包含相同的值,則系統可能會針對該值進行大幅壓縮。 反之,如果某個資料庫包含隨機資料或者每個頁面僅包含單一大型資料列,則壓縮的備份幾乎會與未壓縮的備份一樣大。

  • 資料是否經過加密

    加密資料的壓縮比大幅低於對等的未加密資料。 例如,如果在資料行層級以 Always Encrypted 加密資料,或使用其他應用層級加密來加密資料,則壓縮備份可能不會明顯縮減大小。

    如需壓縮以透明資料加密 (TDE) 加密的資料庫詳細資訊,請參閱使用 TDE 備份壓縮

  • 資料庫是否經過壓縮。

    如果資料庫已壓縮,壓縮備份可能不會大幅縮減其大小 (如果有的話)。

使用 TDE 備份壓縮

從 SQL Server 2016 (13.x) 開始,設定MAXTRANSFERSIZE 會針對透明資料加密 (TDE) 加密的資料庫啟用最佳化壓縮演算法,此演算法會先將頁面解密、將其壓縮,然後再次加密。 如果未 MAXTRANSFERSIZE 指定,或是 MAXTRANSFERSIZE = 65536 使用 (64 KB) 時,使用 TDE 加密資料庫的備份壓縮會直接壓縮加密的頁面,而且可能不會產生良好的壓縮比例。 如需詳細資訊,請參閱適用於已啟用 TDE 之資料庫的備份壓縮 \(英文\)。

從 SQL Server 2019 (15.x) CU5 開始,不再需要設定 MAXTRANSFERSIZE 即可針對 TDE 啟用這個最佳化壓縮演算法。 如果備份命令指定了 WITH COMPRESSION,或 backup compression default 伺服器組態設為 1,則 MAXTRANSFERSIZE 會自動增加至 128K,以啟用最佳化演算法。 如果在 MAXTRANSFERSIZE 備份命令上指定值為 > 64K,則會接受所提供的值。 換句話說,SQL Server 永遠不會自動降低值,其只會增加。 如果需要使用 MAXTRANSFERSIZE = 65536 備份 TDE 加密的資料庫,則必須指定 WITH NO_COMPRESSION,或確定 backup compression default 伺服器組態設為 0。

如需詳細資訊,請參閱 BACKUP (Transact-SQL)

警告

如果您在套用 SQL Server 2019 CU5 之後,要對單一備份媒體集執行多個備份,請安裝 SQL Server 2019 CU9 (KB13768244) 以解決已知的還原問題。 否則可能會導致備份無法還原。 套用 SQL Server 2019 CU9 之後,備份程式會強制執行選項 INIT ,以防止將使用 TDE 或具有不同資料庫加密金鑰 (DEK) 的資料庫備份合併到單一備份媒體集中。

備份檔案的空間配置

對於壓縮備份,最後備份檔案的大小取決於資料可壓縮的程度,但是在備份作業完成之前,無法得知這項資訊。 因此,根據預設,使用壓縮備份資料庫時,Database Engine 會針對備份檔使用預先配置演算法。 此演算法會預先配置資料庫大小的一個定義好的百分比給備份檔案。 如果在備份作業期間需要更多空間,Database Engine 會增加檔案大小。 如果最後的大小小於配置的空間,在備份作業結束時,Database Engine 會將檔案縮小為最後的實際備份大小。

若要讓備份檔案只依照需要增加至最終大小,請使用追蹤旗標 3042。 追蹤旗標 3042 會導致備份作業略過預設備份壓縮預先配置演算法。 如果您只要配置壓縮備份所需的實際大小,藉以節省空間,這個追蹤旗標就很有用。 不過,使用此追蹤旗標可能會導致效能稍微降低 (可能會增加備份作業的持續時間)。

相關工作

下一步

備份概觀 (SQL Server)
使用 DBCC TRACEON 設定追蹤旗標 (Transact-SQL)