Backup-Interna - Was passiert, wenn ein Backup-Job ausgeführt wird - in Bezug auf Sperren und Performance-Overhead in SQL Server?

Für MySQL weiß ich, dass die Datenbank in SQL-Anweisungen tabellenweise gesichert wird. Dies führt zu Sperren. Wenn Sie Spalten während der Sicherung aktualisieren, kann dies zu Integritätsproblemen führen.

Soweit ich weiß, gilt dies nicht für den Microsoft SQL Server. Wie geht der SQL Server damit um? Gibt es ein internes Einfrieren, um die Datenbank konsistent zu halten?

Außerdem habe ich gehört, dass das Sichern ein einzelner Thread ist, was bedeutet, dass nur ein Kern verwendet wird, vorausgesetzt, Sie sichern in einer einzelnen Datei. Angenommen, Sie haben eine Multicore-Maschine, z. B. 16 Kerne, oder zumindest eine deutlich größere Anzahl als eine.

Aufgrund meiner persönlichen Erfahrung hatte ich nie Probleme beim Erstellen von Backups, weder beim Sperren noch bei Overhead-Problemen, aber meine Erfahrung ist begrenzt. Aus diesem Grund empfehle ich immer, die Sicherungskomprimierung in den Servereigenschaften zu aktivieren.

Was passiert also, wenn ein Sicherungsjob ausgeführt wird? Und gibt es auch signifikante Unterschiede für die verschiedenen Versionen? Zum Beispiel 2008, 2012 und 2014 (nicht die Lizenzen).

Ihre gesamten Punkte werden in Backup-Mythen behandelt - von Paul Randal

30-01) Sicherungsvorgänge verursachen Blockierung

Nein. Bei Sicherungsvorgängen werden Benutzerobjekte nicht gesperrt . Sicherungen verursachen eine sehr hohe Leselast auf dem E / A-Subsystem, sodass es so aussehen kann, als ob die Arbeitslast blockiert wird, dies ist jedoch nicht der Fall. Es wird nur verlangsamt. Es gibt einen speziellen Fall, in dem eine Sicherung, die massenprotokollierte Bereiche aufnehmen muss, eine Dateisperre benötigt, die einen Prüfpunktvorgang blockieren kann - DML wird jedoch niemals blockiert.

Außerdem habe ich gehört, dass das Sichern ein einzelner Thread ist, was bedeutet, dass nur ein Kern verwendet wird, vorausgesetzt, Sie sichern in einer einzelnen Datei.

Eine Sicherung in einer einzelnen Datei oder auf einem einzelnen Gerät verwendet einen Writer-Thread. Wenn Sie also auf Mehrere Dateien / Geräte sichern (dh auf mehrere .bak-Dateien), wird pro Datei / Gerät ein Writer-Thread erstellt.

Die einfachste Möglichkeit, die Sicherungsleistung zu verbessern, besteht darin, die Parallelisierung des Sicherungsvorgangs zuzulassen, der als Sicherungs-Striping bezeichnet wird. Standardmäßig gibt es einen einzelnen Datenleser-Thread für jeden Laufwerksbuchstaben oder Bereitstellungspunkt, von dem gelesen wird, und einen einzelnen Datenschreiber-Thread für jedes Sicherungsgerät, auf das geschrieben wird.

Prüfen

1. Bereitschaftsvideos für Microsoft Certified Master (MCM) von SQL Server 2008, insbesondere Backup-Interna.
2. Ein Blick auf Backup-Interna und das Verfolgen des Backup- und Wiederherstellungsdurchsatzes (Teil 1) - Von: Jonathan Kehayias
3. Ein Blick auf Backup-Interna und das Verfolgen des Backup- und Wiederherstellungsdurchsatzes (Teil 2) - Von: Jonathan Kehayias

Der Artikel, den Paul über Backup-Interna geschrieben hat, ist ausgezeichnet, und Sie müssen ihn lesen. Hinzufügen zu dem, was andere gesagt haben, und Hervorheben eines bestimmten Teils Ihrer Frage

Außerdem habe ich gehört, dass das Sichern ein einzelner Thread ist, was bedeutet, dass nur ein Kern verwendet wird, vorausgesetzt, Sie sichern in einer einzelnen Datei. Angenommen, Sie haben eine Multicore-Maschine, z. B. 16 Kerne, oder zumindest eine deutlich größere Anzahl als eine.

Sicherungsvorgang, can use parallelismaber denken Sie daran, dies ist nicht die Parallelität, die von Optimizer in SQL Server gesteuert wird, sondern die Anzahl der Festplatten, von denen die Sicherung die Datendatei lesen muss und von denen die Sicherung die Datendatei und die Menge der erstellten Sicherungsdateien schreibt.

Sie können den MAXDOPHinweis nicht verwenden, wenn Sie eine SQL Server-Sicherung durchführen

Sie können in SSMS keinen Ausführungsplan für eine einfache TSQL-Sicherungsoperation generieren.

Die durch das Abfrageoptimierungsprogramm in SQL Server ausgelöste Parallelität ist im Wesentlichen für die beteiligten Operatoren bestimmt (tatsächlich ist sie komplexer, aber der Einfachheit halber können Sie dies in Kauf nehmen), da für den Sicherungsvorgang keine Operatoren erforderlich sind, da die vom Optimierungsprogramm ausgelöste Parallelität nicht verwendet werden kann.

Ich habe im Technet-Wiki einen Artikel über Sicherung und Parallelität geschrieben, in dem ich anhand einfacher Beispiele die Parallelität während der SQL Server-Sicherung erläuterte. Es folgt die Schlussfolgerung

1. Wenn sich Datenbankdateien auf mehreren Datenträgern befinden, wird der Sicherungsvorgang auf einem Thread pro Gerätelaufwerk zum Lesen der Daten gestartet. Wenn die Wiederherstellung auf mehreren Laufwerken / Bereitstellungspunkten durchgeführt wird, wird durch den Sicherungsvorgang ein Thread pro Laufwerk / Bereitstellungspunkt initiiert

2. Selbst wenn Sie mehrere Sicherungskopien auf demselben Laufwerk sichern, wird pro Sicherungsdatei ein Thread gesichert.

3. Die mit der Sicherung verbundene Parallelität hängt mit den Streifen zusammen. Jeder Stripe erhält einen eigenen Worker-Thread und das ist wirklich der einzige Teil der Sicherung / Wiederherstellung, den man als parallele Operationen betrachten sollte.

4. Der maximale Parallelitätsgrad hat keine Auswirkungen auf den Sicherungsvorgang.

Ich habe dazu eine Expertenmeinung von Paul und Bob Dorr erhalten.

Was passiert also, wenn ein Sicherungsjob ausgeführt wird? Und gibt es auch signifikante Unterschiede für die verschiedenen Versionen? Zum Beispiel 2008, 2012 und 2014 (nicht die Lizenzen).

Ich würde Ihnen empfehlen, diesen blog.msdn-Artikel von Bob Dorr zu lesen . Einige wichtige Punkte, die er hervorhob, sind

1. Wenn eine Sicherung gestartet wird, werden eine Reihe von Puffern erstellt, die aus dem Speicher außerhalb des Pufferpools zugewiesen werden. Das Ziel ist üblicherweise 4 MB für jeden Puffer, was ungefähr 4 bis 8 Puffer ergibt. Details zur Berechnung finden Sie unter: http://support.microsoft.com/kb/904804/en-us

2. Die Puffer werden zwischen der freien Warteschlange und der Datenwarteschlange umgeschaltet. Der Reader zieht einen freien Puffer, füllt ihn mit Daten und stellt ihn in die Datenwarteschlange. Die Schreiber ziehen gefüllte Datenpuffer aus der Datenwarteschlange, verarbeiten den Puffer und geben ihn an die freie Liste zurück.

3. Sie erhalten einen Writer pro Sicherungsgerät, der jeweils aus der Datenwarteschlange abruft. Ein Sicherungsbefehl mit vier (4) Datenträgerspezifikationen hat also vier Schreiber und einen Leser. Der Leser verwendet asynchrone E / A, um mit den Schreibern Schritt zu halten.

Sie können aktivieren trace flags 3213 and 3605, beide sind nicht dokumentiert. Verwenden Sie sie daher in der Testumgebung, und überprüfen Sie, welche interessante Meldung im SQL Server-Fehlerprotokoll ausgegeben wird. Etwas wie das Folgende würde erscheinen

Memory limit: 249MB
BufferCount:                7
Sets Of Buffers:            1
MaxTransferSize:            1024 KB
Min MaxTransferSize:        64 KB
Total buffer space:         7 MB
Tabular data device count:  1
Fulltext data device count: 0
Filestream device count:    0
TXF device count:           0
Filesystem i/o alignment:   512
Media Buffer count:            7
Media Buffer size:          1024KB

Mir sind keine wesentlichen Änderungen im Sicherungscode für verschiedene Versionen bekannt, solche Dinge sind nicht dokumentiert. Ich kenne nur die Verbesserungen, die beim SQL Server 2012 SP1 Cumulative Update 2,Aktivieren der Sicherung und Wiederherstellung über den Windows Azure Blob-Speicherdienst von SQL Server mithilfe von TSQL oder SMO eingeführt wurden. Lesen Sie hier

Grundsätzlich erstellt SQL Server eine fehlerhafte Kopie aller Seiten auf der Festplatte. Diese Seiten sind wahrscheinlich inkonsistent, wenn es eine gleichzeitige Aktivität gibt oder wenn es zuvor eine Aktivität ohne Checkpoint gab.

Anschließend kopiert SQL Server auch den erforderlichen Teil des Transaktionsprotokolls, der erforderlich ist, um die veralteten Seiten auf die neueste Version zu bringen und bei der Wiederherstellung für Konsistenz zu sorgen.

Ich kann nicht mit dem Multithreading des Sicherungsvorgangs sprechen. Ich gehe davon aus, dass es parallelisiert wird. Wie sonst könnten Sie eine 10-TB-Datenbank auf einem 10-GB / s-E / A-Subsystem sichern?