Transaktionsprotokollsicherungen seriell oder parallel?

Wir verwenden zufällig SQL Server 2012 Standard Edition. Ich verwende zufällig auch die Skripte von Ola Hallengren, um ein einfacheres und flexibleres Framework für die Durchführung von Backups und Wartungsarbeiten bereitzustellen.

Bei dieser Frage geht es nicht so sehr um Olas Skripte, sondern um eine bewährte Methode. Mir ist klar, dass die endgültige Antwort lautet: "Es hängt von den Anforderungen Ihres Unternehmens ab." Aber ich versuche, mich von der Community beraten zu lassen, wie ich die Anforderungen unseres Unternehmens am besten erfüllen kann.

Ich möchte alle 15 Minuten Transaktionsprotokollsicherungen einrichten. Auf diese Weise verlieren wir hoffentlich nicht mehr als 15 Minuten an Daten. Sollte ich einen Job einrichten, der ALL_DATABASES verwendet? Oder ist es besser, einen Job für jede Datenbank einzurichten und alle parallel zu starten? Ich frage, weil ich das Gefühl habe, basierend auf der Funktionsweise von Olas Skript, dass die Backups seriell gestartet werden. Der Nachteil von Serial ist, dass jedes aufeinanderfolgende Backup wartet, bis das andere abgeschlossen ist. Dies kann möglicherweise die Zeitspanne zwischen Sicherungen verlängern (dh länger als 15 Minuten). Außerdem würde ich befürchten, dass ein Fehler in einem Backup die anderen davon abhält, und ich würde nicht wollen, dass dies der Fall ist. Ich möchte, dass die anderen weiter sichern.

Stimmt es, dass Olas Skripte seriell ausgeführt werden und ein Fehler die nachfolgenden Sicherungen beendet?

Und ist es besser, für jede Datenbank einen Job zu haben? oder ein einziger Job, der alles kann? Ich neige zu getrennten Jobs, möchte aber verstehen, was SQL Server-DBAs im Allgemeinen tun.

Sollte ich einen Job einrichten, der ALL_DATABASES verwendet? Oder ist es besser, einen Job für jede Datenbank einzurichten und alle parallel zu starten?

Ich würde vorschlagen, einen Job einzurichten, der die Transaktionsprotokolle (seriell) sichert. Auf diese Weise wird auch sichergestellt, dass die Sicherung die E / A nicht überlastet, da Sie jeweils eine Sicherung für die Datenbank ausführen.

Was könnten mögliche Nachteile beim parallelen Laufen sein

1. Angenommen, Sie haben 50 Datenbanken und Sie planen die Sicherung des Transaktionsprotokolls aller Datenbanken, und alle werden parallel ausgeführt. Dies wird definitiv viel E / A verbrauchen. Und wenn die Festplatte, auf der die Dateien gesichert werden, andere Datendateien enthält, wird dies als langsam empfunden. Ich habe festgestellt, dass die Sicherung langsam wird, wenn eine schlechte Abfrage, die viele E / A anfordert, zusammen mit dem Sicherungsjob ausgeführt wird.

2. Angenommen, Sie haben 50 Datenbanken. Es wäre nicht schwierig, 50 Jobs im SQL Server-Agenten zu verwalten. Was wäre, wenn Sie 100-200 Datenbanken haben? Es würde mir einfach nicht gefallen, wenn Sie den SQL Server-Agenten öffnen und viele Jobs sehen. halte es einfach. Ich bin sicher, der gleiche Fall wäre bei Ihnen.

Der Nachteil von Serial ist, dass jedes aufeinanderfolgende Backup wartet, bis das andere abgeschlossen ist. Dies kann möglicherweise die Zeitspanne zwischen Sicherungen verlängern (dh länger als 15 Minuten).

Transaktionsprotokollsicherungen sind meistens klein, und wenn Sie eine ausgelastete Datenbank haben, die viele Protokollsätze erstellt, müssen Sie möglicherweise die Sicherungshäufigkeit ändern. Meistens habe ich gesehen, dass die Sicherung des Transaktionsprotokolls ordnungsgemäß abgeschlossen wurde, wenn die Häufigkeit 15 Minuten beträgt. Ich denke nicht, dass Sie sich Sorgen machen sollten.

Außerdem würde ich befürchten, dass ein Fehler in einem Backup die anderen davon abhält, und ich möchte nicht, dass dies der Fall ist

Ich würde sagen, mach dir keine Sorgen. Transaktionsprotokollsicherungen können nur fehlschlagen, wenn Sie einen Fehler gemacht haben. Die Fehler können sein

1. Der Eigentümer, der den Job ausführt, wird aus AD entfernt

2. Jemand hat das Wiederherstellungsmodell der Datenbank geändert.

3. Unzureichender Speicherplatz

Abgesehen von oben habe ich keinen Grund dafür gesehen, dass die Sicherung des Transaktionsprotokolls fehlschlägt. Es ist sehr robust, darauf können Sie sich verlassen.

Führen Sie Ihre T-Log-Sicherungen im Allgemeinen immer seriell aus. Viele meiner Instanzen haben ein paar Dutzend Datenbanken und einige sind sehr aktiv. Die Transaktionsprotokollsicherungen dauern insgesamt nur wenige Sekunden. bis zu einer halben Minute oder so, wenn es besonders beschäftigt ist.

Das parallele Ausführen von Sicherungen ist nur dann von Vorteil, wenn alle folgenden Bedingungen erfüllt sind:

• Ihre Datenbanken und Protokolldateien befinden sich alle auf eindeutigen unabhängigen Spindeln (oder auf Solid-State-Festplatten in beliebiger Kombination).

  • Bei reinen T-Log-Sicherungen müssten nur die Protokolldateien diese Anforderung erfüllen.

• Ihre Sicherungsziele für jede Datenbank befinden sich auf separaten Spindeln.

• Sie verwenden keinen gemeinsam genutzten SAN-HBA oder iSCSI oder keine andere Bandbreite zwischen der SQL Server-Instanz und dem Medium.

• dh die IOPS aus dem Lesen von Datenbank A und Schreiben von Backup A Verwenden Sie NICHT die gleichen Datenträger wie das Lesen von Datenbank B und das Schreiben von Backup B.

Wenn all dies zutrifft, kann ein gewisser Grad an Parallelität die Gesamtkalenderzeit verringern. Wenn all dies nicht zutrifft, führt dies höchstwahrscheinlich dazu, dass ein oder mehrere Festplattensätze in den Hintergrund treten und Ihre parallelen Sicherungen tatsächlich mehr Zeit in Anspruch nehmen als serielle Sicherungen, können jedoch auch zu einer Fragmentierung des Betriebssystems oder der Speicherebene führen, da Sie schreiben gleichzeitig Backup A und Backup B!

Machen Sie sich keine Sorgen, dass eine Sicherung fehlschlägt und der Rest erfolgreich ist. Wenn eine Sicherung fehlschlägt, müssen Sie ohnehin alles überprüfen.

• Festplattenfehler

• Fehler bei der Hyperbac- / Litespeed- / Drittanbieter-Komprimierungssoftware (wenn Sie Software zwischen SQL und dem fehlerhaften Datenträger haben)

  • Als Warnung kann der Fehler in Form eines Sicherungsjobs auftreten, der nie abgeschlossen wird. Daher ist es hilfreich, eine Überprüfung auf "Jobs, die länger als erwartet ausgeführt werden" durchzuführen, die Warnungen senden.

• Produktfehler bei der Verschlüsselung (wenn Sie Software zwischen SQL und dem fehlerhaften Datenträger haben)

• Netzwerkfehler (wenn sich die Datenbankdateien oder wahrscheinlich die Sicherungsdateien im Netzwerk befinden)

• Berechtigungen

  • Am häufigsten bei Neuinstallationen

  • oder brandneue Backup-Speicherorte

  • Ändern des SQL Server-Dienstbenutzers (hierfür sind die Berechtigungen für normale Sicherungen erforderlich)

  • Sperren des SQL Server-Dienstbenutzers, da er von mehr als nur einer SQL Server-Instanz verwendet wird

• Konfigurationsfehler

• Stromausfall

• Betriebssystemabsturz

Die meisten davon wirken sich nicht auf einen und nicht auf die anderen aus, es sei denn, die oben genannten Bedingungen sind ebenfalls erfüllt.

Um es hinzuzufügen, entwirft Ola seine Skripte, in denen, wenn eine Datenbanksicherung aus irgendeinem Grund fehlschlägt, die nächsten versucht werden. Wie bereits erwähnt, kann eine Warnmeldung eingerichtet werden, die Sie über den fehlgeschlagenen Job informiert, da der Sicherungsjob immer noch fehlschlagen würde, selbst wenn nur eine Datenbanksicherung aus allen Benutzerdatenbanken fehlschlägt - vorausgesetzt, Sie sichern alle Datenbanken (eine) Arbeit für alle).