Sicherungskomprimierung (SQL Server)

  • Artikel

In diesem Thema wird die Komprimierung von SQL Server -Sicherungen beschrieben, einschließlich Einschränkungen und Leistungseinbußen bei der Sicherungskomprimierung, Konfiguration der Sicherungskomprimierung sowie Komprimierungsverhältnis.

Hinweis

Informationen, welche Editionen von SQL Server 2014 die Sicherungskomprimierung unterstützen, finden Sie unter Features Supported by the Editions of SQL Server 2014. Jede Edition von SQL Server 2008 und höhere Versionen können 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.

  • Mit "NTbackup" erstellte Sicherungen können nicht auf demselben Band gespeichert werden wie komprimierte SQL Server -Sicherungen.

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 Einschränken der CPU-Nutzung durch die Sicherungskomprimierung mithilfe der Ressourcenkontrolle (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. Wird die transparente Datenverschlüsselung zum Verschlüsseln einer gesamten Datenbank verwendet, ändert sich ihre Größe bei einer komprimierten Sicherung unter Umständen kaum oder gar nicht.

  • 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.

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)