Dlouhá úloha SQL: udržte ji v chodu, když VPN spadne

VPN spadne dvacet minut po začátku přestavby indexu, váš klient SQL ukazuje přerušené připojení a zřejmá otázka nemá v této chybě odpověď. Dokončil se příkaz, vrátil se zpět, nebo běžel dál bez vás? Znovu se připojit a znovu odeslat je nejhorší ze tří možností, protože mění jeden nejistý výsledek ve dva možné. Přesuňte práci na něco s trvalým vlastníkem ještě před dalším oknem.

Co vám chyba připojení neřekne

Chyba na straně klienta popisuje klienta. Oznamuje, že se zavřel socket, ne co server udělal s transakcí. Příkaz se může stále vykonávat, mohl se potvrdit těsně předtím, než spojení zemřelo, nebo se mohl vrátit zpět, když byla jeho relace uklizena. Všechny tři případy dají na vašem notebooku stejnou zprávu.

Jen stav serveru to může rozhodnout. Podívejte se tam, než cokoli rozhodnete.

Předejte práci vlastníkovi na straně serveru

U práce, která nepotřebuje lidský dohled, nechte hostitele databáze vlastnit provádění. SQL Server Agent spouští úlohy na vyžádání nebo podle plánu a zaznamenává každé spuštění, takže životní cyklus úlohy je nezávislý na vaší relaci VPN. Identita úlohy potřebuje přesně ta oprávnění, která úkol vyžaduje, ne úplný interaktivní kontext správce. Notebook pak práci spustí a čte výsledky, místo aby byl procesem, který ji drží naživu.

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

Dostupnost Agenta závisí na edici a službě, kterou jste nasadili. Použijte mechanismus, který vaše platforma skutečně poskytuje, místo abyste předpokládali, že tento existuje všude.

Přeskakovací hostitel blízko databáze zkracuje cestu a vyplatí se ho mít, ale nemění otázku vlastnictví. Relace stejně skončí, když skončí síť. Použijte ho k pozorování, ne jako věc, která drží práci naživu.

Zanechte záznam, který si příští relace přečte

Zapište název úlohy nebo identifikátor, cílovou databázi a výsledek, který očekáváte. Právě tento záznam umožňuje jiné relaci nebo jinému člověku odpovědět na otázku, na kterou chyba nedokázala. Bez něj vám zůstane jen mlhavá vzpomínka na aktualizaci a žádný způsob, jak to ověřit.

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

Historie ukazuje výsledek a čas u každého kroku, což je užitečnější než jediný příznak úspěchu. U úloh, které mění data, přidejte i vlastní ověření aplikace: počet řádků, kontrolní součet nebo stavový řádek zapsaný úlohou. Dva nezávislé záznamy dělají opakování bezpečným a zaznamenaná historie úlohy je prvním z nich.

Srovnejte stav, než odešlete znovu

Když pozorovací připojení zmizí, najděte existující spuštění, než začnete další. Přečtěte si výsledky jeho kroků a rozhodněte, zda se práce potvrdila, částečně dokončila, nebo nikdy nezačala. Teprve potom použijte pravidlo opakování, které definuje pracovní postup, protože slepé opětovné odeslání může zduplikovat načtení nebo podruhé selhat v polovině.

Zachovejte trvalého vlastníka a kontrolovatelný výsledek a krátký výpadek přístupu se stane nepříjemností, ne hádankou. To je celý cíl návrhu: práce by měla přežít připojení, které ji vyžádalo.