Sommerzeit

In meiner Umgebung laufen Server mit nativen Backups und Ola Hallengren-Plänen. Unsere Server sind eine Kombination aus 2008, 2012 und 2014. Alle vollständigen Sicherungen werden um 12 Uhr morgens durchgeführt, und Protokollsicherungen werden alle 15 Minuten durchgeführt.

Ich habe die Sommerzeit noch nie berücksichtigt. Bitte sagen Sie mir, welche Anpassungen ich vornehmen sollte.

Sind die vollständigen Sicherungen um 12 Uhr betroffen und was passiert mit den Protokollsicherungen?

Der SQL Server-Experte Paul Randal spricht genau dieses Thema in Wie wirkt sich die Sommerzeit auf die Notfallwiederherstellung aus? . Es ist ein relativ kurzer Beitrag, also zitiere ich ihn in seiner Gesamtheit. Da Sie über Ihre Transaktionsprotokollsicherungen besorgt waren, habe ich auch einen Teil des Beitrags hervorgehoben, um Sie darauf aufmerksam zu machen.

Es ist allgemein bekannt, dass SQL Server mit der Sommerzeit (DST) richtig umgeht. Warum sollten Sie sich darum kümmern?

Nun, es ist nicht so allgemein bekannt, dass SQL Agent am Ende der Sommerzeit, wenn die Uhren eine Stunde zurückgehen (in den USA immer um 02:00 Uhr), im Wesentlichen eine Stunde lang pausiert (ab mindestens SS2000). Wenn Sie also einen Job haben, der alle 15 Minuten etwas erledigt, liegt zwischen der Jobausführung um 01:45 Uhr und der Jobausführung um 02:00 Uhr eine Lücke von 75 Minuten. Dies geschieht, weil um 02:00 Uhr die Zeit auf 01:00 Uhr zurückgesetzt wird, die nächste Laufzeit aller Jobs jedoch gleich bleibt. Daher kann Ihr Job erst nach der nächsten geplanten Zeit von 02:00 Uhr ausgeführt werden. Auf der Nordhalbkugel verlieren Sie jeden Herbst und auf der Südhalbkugel jeden Frühling eine Stunde an SQL Agent-Jobs. Trotzdem, warum sollte es dich interessieren?

Nun, es kommt darauf an, welche Jobs sich um eine Stunde verzögern. Wenn Sie einen Job haben, der alle 15 Minuten eine Protokollsicherung durchführt, liegt am Tag der Sommerzeit tatsächlich eine Lücke von 75 Minuten zwischen den Protokollsicherungen. Wenn Sie ein Service Level Agreement (SLA) haben, das die maximale Menge an verlorener Arbeit im Katastrophenfall auf 15 Minuten begrenzt, sind Sie in diesen 75 Minuten möglicherweise nicht in der Lage, dieses SLA einzuhalten!

Das könnte eine ziemlich große Sache sein, besonders wenn während dieser Stunde etwas schief geht (nicht mehr oder weniger wahrscheinlich als etwas, das zu einem anderen Zeitpunkt schief geht, aber immer noch möglich). In diesem Fall müssen Sie eine alternative Lösung finden. Ein paar Möglichkeiten, um das Problem zu umgehen, das ich mir vorstellen kann:

• Lassen Sie jemanden während dieser Stunde lange aufbleiben und manuelle Protokollsicherungen durchführen.
• Wechseln Sie zur Datenbankspiegelung, die das Protokoll kontinuierlich an den redundanten Server überträgt und das DST-Problem nicht beeinträchtigt.

Beides sind praktikable Lösungen, aber ich denke, das Beste ist, einen SQL Agent-Job zu erstellen, der um 01:59 Uhr ausgeführt wird, und zusätzliche Sicherungsjobs zu erstellen, die um 01:00, 01:15, 01:30 und 01:45 Uhr ausgeführt werden. Ich verstehe nicht, warum das nicht möglich sein sollte. Heute morgen um 10:36 Uhr habe ich einen einfachen Agentenjob erstellt, um das Datum in eine Datei zu drucken und es so einzustellen, dass es um 09:40 Uhr ausgeführt wird - in der Vergangenheit. Ich habe dann meine Systemzeit um eine Stunde zurückgesetzt und der Job wurde perfekt ausgeführt. Der einzige Nachteil dieser Lösung besteht darin, dass Sie die zusätzlichen Jobs mithilfe der in Jobschritte eingebetteten T-SQL Agent-SPs für Ihren 01:59-Job erstellen und planen müssen - mühsam, aber nicht schwierig. Vielleicht könnte mir jemand ein Skript schicken und ich werde es als Folge bloggen?

Wenn die Sommerzeit am 4. November zu Ende geht, sollten Sie sich dessen unbedingt bewusst sein, auch wenn Sie sich nicht die Mühe machen möchten, mit der zusätzlichen Stunde fertig zu werden. Nebenbei bemerkt - die Daten, an denen die Sommerzeit beginnt und endet, haben sich in diesem Jahr geändert. Im KB-Artikel 931975 wird erläutert, welche Teile von SQL Server die geänderten Daten nicht kennen und was Sie dagegen tun können.