Lang laufender SQL-Job: Weiterlaufen, wenn die VPN-Verbindung abbricht

Die VPN-Verbindung bricht zwanzig Minuten nach Beginn eines Index-Neuaufbaus ab, der SQL-Client meldet eine unterbrochene Verbindung, und die naheliegende Frage lässt sich aus dieser Fehlermeldung nicht beantworten. Ist die Anweisung zu Ende gelaufen, zurückgerollt oder ohne Sie weitergeholfen? Erneut verbinden und erneut absenden ist die schlechteste der drei Möglichkeiten, denn sie macht aus einem unklaren Ergebnis zwei mögliche. Verlegen Sie die Arbeit auf etwas mit einem dauerhaften Besitzer, bevor das nächste Wartungsfenster beginnt.

Was die Verbindungsfehlermeldung Ihnen nicht sagt

Ein clientseitiger Fehler beschreibt den Client. Er meldet, dass der Socket geschlossen wurde, nicht, was der Server mit der Transaktion getan hat. Die Anweisung läuft möglicherweise noch, wurde vielleicht kurz vor dem Abbruch der Verbindung festgeschrieben oder wurde beim Aufräumen ihrer Sitzung zurückgerollt. Alle drei Fälle erzeugen auf Ihrem Laptop dieselbe Meldung.

Nur der Zustand des Servers kann das klären. Sehen Sie dort nach, bevor Sie irgendetwas entscheiden.

Geben Sie die Arbeit an einen Besitzer auf Serverseite ab

Bei Arbeiten, die keinen Beobachter brauchen, sollte der Datenbank-Host die Ausführung übernehmen. Der SQL Server Agent führt Aufträge auf Anforderung oder nach Zeitplan aus und zeichnet jeden Lauf auf, sodass der Lebenszyklus des Auftrags unabhängig von Ihrer VPN-Sitzung ist. Die Identität des Auftrags braucht genau die Berechtigungen, die die Aufgabe verlangt, nicht den vollen interaktiven Kontext eines Administrators. Der Laptop stößt die Arbeit dann an und liest die Ergebnisse, statt der Prozess zu sein, der sie am Leben hält.

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Die Verfügbarkeit des Agent hängt von der Edition und dem Dienst ab, die Sie bereitgestellt haben. Nutzen Sie den Mechanismus, den Ihre Plattform tatsächlich bietet, statt anzunehmen, dieser sei überall vorhanden.

Ein Jump-Host nahe der Datenbank verkürzt den Weg und ist sinnvoll, ändert aber nichts an der Besitzerfrage. Die Sitzung endet trotzdem, wenn das Netzwerk endet. Nutzen Sie ihn zum Beobachten, nicht als das, was die Arbeit am Leben hält.

Hinterlassen Sie einen Datensatz, den die nächste Sitzung lesen kann

Halten Sie einen Auftragsnamen oder eine Kennung, die Zieldatenbank und das erwartete Ergebnis fest. Dieser Datensatz ist es, der eine andere Sitzung oder eine andere Person die Frage beantworten lässt, die der Fehler nicht beantworten konnte. Ohne ihn bleibt Ihnen eine vage Erinnerung an ein Update und keine Möglichkeit zur Prüfung.

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

Der Verlauf zeigt Ergebnis und Zeitverlauf pro Schritt, was nützlicher ist als ein einzelnes Erfolgsflag. Ergänzen Sie bei Aufgaben, die Daten ändern, die eigene Prüfung der Anwendung: eine Zeilenzahl, eine Prüfsumme oder eine vom Auftrag geschriebene Statuszeile. Zwei unabhängige Datensätze machen einen erneuten Versuch sicher, und der aufgezeichnete Auftragsverlauf ist der erste davon.

Abgleichen, bevor Sie erneut absenden

Wenn die beobachtende Verbindung verschwindet, suchen Sie den bestehenden Lauf, bevor Sie einen neuen starten. Lesen Sie die Schrittergebnisse und entscheiden Sie, ob die Arbeit festgeschrieben, teilweise abgeschlossen oder nie gestartet wurde. Wenden Sie erst dann die Wiederholungsregel des Workflows an, denn ein blindes erneutes Absenden kann einen Ladevorgang doppeln oder ein zweites Mal mittendrin scheitern.

Behalten Sie den dauerhaften Besitzer und das nachprüfbare Ergebnis bei, dann wird ein kurzer Zugriffsausfall zur Unannehmlichkeit statt zu einer Vermutung. Das ist das ganze Entwurfsziel: Die Arbeit sollte die Verbindung überleben, die sie angefordert hat.