Sicherungskomprimierung (SQL Server)

Gilt für:yes SQL Server (alle unterstützten Versionen)

In diesem Thema wird die Komprimierung von SQL Server Sicherungen beschrieben, einschließlich Einschränkungen, Leistungsbeeinträchtigungen beim Komprimieren von Sicherungen, Konfiguration der Sicherungskomprimierung und Komprimierungsverhältnis. Die Sicherungskomprimierung wird für SQL Server Editionen unterstützt: Enterprise, Standard und Developer. Jede Edition von SQL Server 2008 und höher kann eine komprimierte Sicherung wiederherstellen.

Vorteile

  • Da eine komprimierte Sicherung kleiner als eine unkomprimierte Sicherung derselben Daten ist, wird für das Komprimieren einer Sicherung normalerweise weniger Geräte-E/A benötigt, und daher steigt die Sicherungsgeschwindigkeit in der Regel erheblich.

    Weitere Informationen finden Sie unter Auswirkungen der Sicherungskomprimierung auf die Leistungweiter unten in diesem Thema.

Beschränkungen

Für komprimierte Sicherungen gelten die folgenden Einschränkungen:

  • Komprimierte und nicht komprimierte Sicherungen können nicht nebeneinander in einem Mediensatz bestehen.

  • Frühere Versionen von SQL Server können komprimierte Sicherungen nicht lesen.

  • NTbackups können ein Band nicht für komprimierte SQL Server Sicherungen freigeben.

Auswirkungen der Sicherungskomprimierung auf die Leistung

Standardmäßig steigt die CPU-Nutzung durch die Komprimierung erheblich, und die bei der Komprimierung zusätzlich verbrauchten CPU-Ressourcen können sich negativ auf gleichzeitige Vorgänge auswirken. Daher ist es u.U. sinnvoll, in einer Sitzung, bei der die CPU-Nutzung durchResource Governoreingeschränkt ist, komprimierte Sicherungen mit niedriger Priorität zu erstellen. Weitere Informationen finden Sie unter Use Resource Governor to Limit CPU Usage by Backup Compression (Transact-SQL) (Verwenden von Resource Governor zum Einschränken der CPU-Auslastung durch Sicherungskomprimierung (Transact-SQL)).

Wenn Sie genau wissen möchten, welche Leistung die Sicherungs-E/A erbringt, können Sie die Sicherungs-E/A zu und von den Geräten beurteilen, indem Sie die folgenden Arten von Leistungsindikatoren analysieren:

  • Windows-E/A-Leistungsindikatoren, wie die Indikatoren für physische Datenträger

  • Der Leistungsindikator Mediumsdurchsatz Bytes/Sekunde des Objekts SQLServer:Sicherungsmedium

  • Der Leistungsindikator Sicherungs-/Wiederherstellungsdurchsatz/Sekunde des Objekts SQLServer:Datenbanken

Informationen zu den Windows-Indikatoren finden Sie in der Windows-Hilfe. Informationen zur Arbeit mit SQL Server-Indikatoren finden Sie unter Verwenden von SQL Server-Objekten.

Berechnen des Komprimierungsverhältnisses einer komprimierten Sicherung

Zum Berechnen des Komprimierungsverhältnisses einer Sicherung verwenden Sie die Werte für die Sicherung in den Spalten backup_size und compressed_backup_size der Verlaufstabelle backupset wie folgt:

backup_size:compressed_backup_size

So gibt ein Komprimierungsverhältnis von 3:1 beispielsweise an, dass Sie etwa 66 Prozent an Speicherplatz sparen. Für eine Abfrage in diesen Spalten können Sie die folgende Transact-SQL-Anweisung verwenden:

SELECT backup_size/compressed_backup_size FROM msdb..backupset;  

Das Komprimierungsverhältnis einer komprimierten Sicherung ist abhängig von den komprimierten Daten. Das erzielte Komprimierungsverhältnis kann durch eine Reihe von Faktoren beeinflusst werden. Zu den Hauptfaktoren gehören:

  • Die Art der Daten.

    Zeichendaten lassen sich stärker komprimieren als andere Arten von Daten.

  • Die Einheitlichkeit der Daten unter den Zeilen einer Seite.

    In der Regel enthält eine Seite mehrere Zeilen, in denen ein Feld den gleichen Wert aufweist. Dieser Wert kann möglicherweise sehr stark komprimiert werden. Dagegen ist bei Datenbanken mit Zufallsdaten oder nur einer großen Zeile pro Seite die komprimierte Sicherung beinahe so groß wie eine nicht komprimierte Sicherung.

  • Verschlüsselungsstatus der Daten

    Verschlüsselte Daten lassen sich deutlich weniger komprimieren als entsprechende unverschlüsselte Daten. Wenn die Daten beispielsweise auf Spaltenebene mit Always Encrypted oder einer anderen Verschlüsselung auf Anwendungsebene verschlüsselt wurden, wird die Größe von Sicherungen durch die Komprimierung möglicherweise nicht erheblich reduziert.

    Weitere Informationen zum Komprimieren von mit TDE (Transparent Data Encryption) verschlüsselten Datenbanken finden Sie unter mit TDE.

  • Komprimierungsstatus der Datenbank.

    Falls die Datenbank bereits komprimiert ist, ändert sich ihre Größe bei einer komprimierten Sicherung unter Umständen kaum oder gar nicht.

Sicherungskomprimierung mit TDE

Ab SQL Server 2016 (13.x) ermöglicht das Festlegen MAXTRANSFERSIZEMAXTRANSFERSIZE einen optimierten Komprimierungsalgorithmus für Transparent Data Encryption (TDE) verschlüsselte Datenbanken, die zuerst eine Seite entschlüsseln, komprimieren und dann erneut verschlüsseln. Wenn MAXTRANSFERSIZE nicht angegeben ist, oder wenn MAXTRANSFERSIZE = 65536 (64 KB) verwendet wird, komprimiert die Sicherungskomprimierung mit TDE-verschlüsselten Datenbanken die verschlüsselten Seiten direkt und gibt möglicherweise keine guten Komprimierungsraten aus. Weitere Informationen finden Sie unter Backup Compression for TDE-enabled Databases (Sicherungskomprimierung für TDE-fähige Datenbanken).

Ab SQL Server 2019 (15.x) CU5 ist keine Einstellung MAXTRANSFERSIZE mehr erforderlich, um diesen optimierten Komprimierungsalgorithmus mit TDE zu aktivieren. Wenn der Sicherungsbefehl angegeben WITH COMPRESSION ist oder die WITH COMPRESSION auf 1 festgelegt ist, wird automatisch auf 128 KB erhöht, MAXTRANSFERSIZE um den optimierten Algorithmus zu aktivieren. Wenn MAXTRANSFERSIZE im Sicherungsbefehl mit dem Wert > 64K angegeben ist, wird der angegebene Wert berücksichtigt. Anders ausgedrückt: SQL Server verringert den Wert nie automatisch, sondern erhöht ihn nur. Wenn Sie eine TDE-verschlüsselte Datenbank mit MAXTRANSFERSIZE = 65536sichern müssen, müssen Sie angeben WITH NO_COMPRESSION oder sicherstellen, dass die Standardserverkonfiguration für die MAXTRANSFERSIZE = 65536 auf 0 festgelegt ist.

Weitere Informationen finden Sie unter BACKUP (Transact-SQL).

Speicherplatzzuordnung für die Sicherungsdatei

Bei komprimierten Sicherungen ist die Größe der finalen Sicherungsdatei davon abhängig, wie stark die Daten komprimiert werden können, und dies ist erst bekannt, wenn der Sicherungsvorgang abgeschlossen ist. Wenn eine Datenbank daher mithilfe einer Komprimierung gesichert wird, verwendet die Datenbank-Engine standardmäßig einen Vorabzuordnungsalgorithmus für die Sicherungsdatei. Dieser Algorithmus ordnet der Sicherungsdatei vorab einen vordefinierten Prozentsatz der Größe der Datenbank zu. Wenn während des Sicherungsvorgangs mehr Platz benötigt wird, lässt die Datenbank-Engine die Datei wachsen. Wenn die finale Größe kleiner als der reservierte Platz ist, verkleinert die Datenbank-Engine die Datei am Ende des Sicherungsvorgangs auf die tatsächliche finale Größe der Sicherung.

Verwenden Sie das Ablaufverfolgungsflag 3042, damit die Sicherungsdatei nur so viel größer werden kann, wie erforderlich, um die finale Größe zu erreichen. Durch das Ablaufverfolgungsflag 3042 wird bewirkt, dass der Sicherungsvorgang den standardmäßigen Vorabzuordnungsalgorithmus für die Sicherungskomprimierung umgeht. Dieses Ablaufverfolgungsflag ist nützlich, wenn Sie Speicherplatz einsparen müssen, indem Sie nur die tatsächliche für die komprimierte Sicherung benötigte Größe zuordnen. Dieses Ablaufverfolgungsflag kann jedoch eine leichte Leistungseinbuße (eine mögliche Verlängerung des Sicherungsvorgangs) verursachen.

Related Tasks

Weitere Informationen

Backup Overview (SQL Server)
Ablaufverfolgungsflags (Transact-SQL)