Długie zadanie SQL: utrzymaj je w ruchu, gdy VPN padnie

VPN pada dwadzieścia minut po rozpoczęciu przebudowy indeksu, klient SQL pokazuje zerwane połączenie, a oczywiste pytanie nie ma odpowiedzi w tym błędzie. Czy instrukcja się zakończyła, została wycofana, czy działała dalej bez ciebie? Ponowne połączenie i ponowne wysłanie to najgorsza z trzech opcji, bo zamienia jeden niepewny wynik w dwa możliwe. Przenieś pracę na coś z trwałym właścicielem przed następnym oknem.

Czego błąd połączenia ci nie mówi

Błąd po stronie klienta opisuje klienta. Informuje, że gniazdo zostało zamknięte, a nie co serwer zrobił z transakcją. Instrukcja może nadal się wykonywać, mogła zostać zatwierdzona tuż przed zerwaniem łącza albo wycofana, gdy jej sesja została posprzątana. Wszystkie trzy dają na twoim laptopie ten sam komunikat.

Tylko stan serwera może to rozstrzygnąć. Zajrzyj tam, zanim cokolwiek postanowisz.

Przekaż pracę właścicielowi po stronie serwera

Pracę, która nie wymaga człowieka pilnującego, oddaj hostowi bazy danych jako właścicielowi wykonania. SQL Server Agent uruchamia zadania na żądanie lub według harmonogramu i zapisuje każde uruchomienie, więc cykl życia zadania jest niezależny od twojej sesji VPN. Tożsamość zadania potrzebuje dokładnie tych uprawnień, których wymaga zadanie, a nie pełnego interaktywnego kontekstu administratora. Wtedy laptop rozpoczyna pracę i czyta wyniki, zamiast być procesem, który utrzymuje ją przy życiu.

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

Dostępność Agenta zależy od wydania i usługi, którą wdrożyłeś. Użyj mechanizmu, który twoja platforma rzeczywiście zapewnia, zamiast zakładać, że ten istnieje wszędzie.

Host przesiadkowy blisko bazy danych skraca drogę i warto go mieć, ale nie zmienia kwestii własności. Sesja i tak kończy się, gdy kończy się sieć. Używaj go do obserwacji, nie jako tego, co utrzymuje pracę przy życiu.

Zostaw zapis, który następna sesja będzie mogła odczytać

Zapisz nazwę zadania lub identyfikator, docelową bazę danych i wynik, którego oczekujesz. Właśnie ten zapis pozwala innej sesji albo innej osobie odpowiedzieć na pytanie, na które błąd nie potrafił. Bez niego zostaje mgliste wspomnienie aktualizacji i żaden sposób, by to sprawdzić.

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

Historia pokazuje wynik i czas każdego kroku, co jest użyteczniejsze niż jedna flaga sukcesu. W zadaniach zmieniających dane dodaj też własną weryfikację aplikacji: liczbę wierszy, sumę kontrolną lub wiersz statusu zapisany przez zadanie. Dwa niezależne zapisy sprawiają, że ponowna próba jest bezpieczna, a zapisana historia zadania jest pierwszym z nich.

Uzgodnij stan, zanim wyślesz ponownie

Gdy połączenie obserwacyjne znika, znajdź istniejące uruchomienie, zanim rozpoczniesz kolejne. Odczytaj wyniki jego kroków i zdecyduj, czy praca została zatwierdzona, częściowo ukończona czy nigdy nie rozpoczęta. Dopiero wtedy zastosuj regułę ponowienia zdefiniowaną w procesie, bo ślepe ponowne wysłanie może zdublować ładowanie albo drugi raz zawieść w połowie drogi.

Zachowaj trwałego właściciela i wynik możliwy do sprawdzenia, a krótka awaria dostępu staje się niedogodnością, a nie domysłem. Taki jest cały cel projektu: praca powinna przeżyć połączenie, które jej zażądało.