Dlhá úloha SQL: udržte ju v chode, keď VPN spadne

VPN spadne dvadsať minút po začiatku prestavby indexu, váš klient SQL zobrazuje prerušené pripojenie a zjavná otázka nemá v tejto chybe odpoveď. Dokončil sa príkaz, vrátil sa späť, alebo bežal ďalej bez vás? Znova sa pripojiť a znova odoslať je najhoršia z troch možností, pretože mení jeden neistý výsledok na dva možné. Presuňte prácu na niečo s trvalým vlastníkom ešte pred ďalším oknom.

Čo vám chyba pripojenia nehovorí

Chyba na strane klienta opisuje klienta. Oznamuje, že sa zatvoril socket, nie čo server urobil s transakciou. Príkaz sa môže stále vykonávať, mohol sa potvrdiť tesne predtým, než spojenie zaniklo, alebo sa mohol vrátiť späť, keď sa jeho relácia upratala. Všetky tri prípady dajú na vašom notebooku rovnakú správu.

Rozhodnúť to môže len stav servera. Pozrite sa tam, skôr než čokoľvek rozhodnete.

Odovzdajte prácu vlastníkovi na strane servera

Pri práci, ktorá nepotrebuje ľudský dohľad, nechajte hostiteľa databázy vlastniť vykonávanie. SQL Server Agent spúšťa úlohy na požiadanie alebo podľa plánu a zaznamenáva každé spustenie, takže životný cyklus úlohy je nezávislý od vašej relácie VPN. Identita úlohy potrebuje presne tie oprávnenia, ktoré úloha vyžaduje, nie úplný interaktívny kontext správcu. Notebook potom prácu spustí a číta výsledky namiesto toho, aby bol procesom, ktorý ju drží nažive.

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

Dostupnosť Agenta závisí od edície a služby, ktorú ste nasadili. Použite mechanizmus, ktorý vaša platforma skutočne poskytuje, namiesto predpokladu, že tento existuje všade.

Preskakovací hostiteľ blízko databázy skracuje cestu a oplatí sa ho mať, ale nemení otázku vlastníctva. Relácia sa aj tak skončí, keď sa skončí sieť. Použite ho na pozorovanie, nie ako vec, ktorá drží prácu nažive.

Nechajte záznam, ktorý si ďalšia relácia prečíta

Zapíšte názov úlohy alebo identifikátor, cieľovú databázu a výsledok, ktorý očakávate. Práve tento záznam umožňuje inej relácii alebo inému človeku odpovedať na otázku, na ktorú chyba nedokázala. Bez neho zostane len hmlistá spomienka na aktualizáciu a žiadny spôsob, ako to overiť.

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

História ukazuje výsledok a čas pri každom kroku, čo je užitočnejšie než jediný príznak úspechu. Pri úlohách, ktoré menia dáta, pridajte aj vlastné overenie aplikácie: počet riadkov, kontrolný súčet alebo stavový riadok zapísaný úlohou. Dva nezávislé záznamy robia opakovanie bezpečným a zaznamenaná história úlohy je prvým z nich.

Zosúlaďte, skôr než odošlete znova

Keď pozorovacie pripojenie zmizne, nájdite existujúce spustenie, skôr než začnete ďalšie. Prečítajte si výsledky jeho krokov a rozhodnite, či sa práca potvrdila, čiastočne dokončila alebo nikdy nezačala. Až potom použite pravidlo opakovania, ktoré definuje pracovný postup, pretože slepé opätovné odoslanie môže zdvojnásobiť načítanie alebo druhýkrát zlyhať v polovici.

Zachovajte trvalého vlastníka a kontrolovateľný výsledok a krátky výpadok prístupu sa stane nepríjemnosťou, nie hádaním. To je celý cieľ návrhu: práca by mala prežiť pripojenie, ktoré ju vyžiadalo.