Transaktionsprotokollsicherungen seriell oder parallel?

15

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.

Chris Aldrich
quelle
1
Ich neige zu einem Job pro Datenbank, da er auf diese Weise besser zu verwalten ist, aber dann bin ich ein "Kontrollfreak", oder so wurde mir gesagt ... Vielleicht haben Sie eine Datenbank, die einen Datenverlust von 15 Minuten aushält, aber eine andere, die nur 5 Minuten haben kann, nur für den Anfang.
Max Vernon
1
Ihr schlimmster Fall (mit Ausnahme der Beschädigung von Sicherungsdateien) wäre, wenn der Server mitten in der Ausführung eines Protokollauftrags abstürzt. Auf diese Weise können Sie die vorherige Protokollsicherung wiederherstellen. Wenn seriell, würde die allererste gesicherte Datenbank einen Datenverlust von 15 Minuten haben, jede nachfolgende Protokollsicherung würde 15 Minuten haben - Gesamtzeit jedes vorherigen Sicherungsdatenverlusts. Das Trennen von Jobs würde es Ihnen ermöglichen, unterschiedliche RPOs pro Datenbank zu haben (dh einige Datenbanken
könnten
@ MaxVernon - vielleicht. Einige meinungsbasierte Fragen sind jedoch gültig. Ich versuche, Fragen zu stellen, die sinnvoll sind, anstatt nur Flammenkriege auszulösen. Außerdem war ich bei all meinen Jobs in der Regel ein versehentlicher / Junior-DBA. Zuerst DB2 und jetzt SQL Server. Ich habe also keinen Senior, von dem ich lernen kann. Meine einzige Ressource ist die Community. Ich denke, eine Frage wie diese ist fair. Es ermöglicht mir und anderen Zufälligen / Junioren, daraus zu lernen.
Chris Aldrich
Nehmen Sie vielleicht nur alle 10 Minuten Protokollsicherungen vor, damit die tatsächliche Verzögerung nie mehr als 15 Minuten beträgt?
USR

Antworten:

6

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.

Shanky
quelle
6

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.

Anti-Weakpasswords
quelle
2

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

rvsc48
quelle