Sarcină SQL lungă: țineți-o în funcțiune când VPN-ul cade

VPN-ul cade douăzeci de minute după începerea unei reconstrucții de index, clientul SQL afișează o conexiune întreruptă, iar întrebarea evidentă nu are răspuns în acea eroare. S-a terminat instrucțiunea, a fost anulată sau a continuat fără tine? Reconectarea și retrimiterea este cea mai proastă dintre cele trei opțiuni, pentru că transformă un rezultat incert în două posibile. Mută munca pe ceva cu un proprietar durabil înainte de următoarea fereastră.

Ce nu îți spune eroarea de conexiune

O eroare pe partea clientului descrie clientul. Ea raportează că socketul s-a închis, nu ce a făcut serverul cu tranzacția. Instrucțiunea poate rula încă, poate fi fost confirmată chiar înainte de căderea legăturii sau poate fi fost anulată când sesiunea ei a fost curățată. Toate trei produc același mesaj pe laptopul tău.

Doar starea serverului poate lămuri asta. Privește acolo înainte de a decide ceva.

Predă munca unui proprietar de pe partea serverului

Pentru munca ce nu are nevoie de un om care să supravegheze, lasă gazda bazei de date să dețină execuția. SQL Server Agent rulează sarcini la cerere sau după un program și înregistrează fiecare rulare, astfel încât ciclul de viață al sarcinii este independent de sesiunea ta VPN. Identitatea sarcinii are nevoie exact de permisiunile cerute de sarcină, nu de contextul interactiv complet al unui administrator. Apoi laptopul pornește munca și citește rezultatele în loc să fie procesul care o ține în viață.

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

Disponibilitatea Agent depinde de ediția și serviciul pe care le-ai implementat. Folosește mecanismul pe care platforma ta îl oferă efectiv în loc să presupui că acesta există peste tot.

Un host de salt aproape de baza de date scurtează calea și merită să existe, dar nu schimbă întrebarea proprietății. Sesiunea tot se termină când se termină rețeaua. Folosește-l pentru a observa, nu pentru a fi lucrul care ține munca în viață.

Lasă o înregistrare pe care următoarea sesiune o poate citi

Notează un nume de sarcină sau un identificator, baza de date țintă și rezultatul pe care îl aștepți. Acea înregistrare este cea care permite unei alte sesiuni, sau unei alte persoane, să răspundă la întrebarea la care eroarea nu a putut. Fără ea rămâne o amintire vagă a unei actualizări și nicio modalitate de a verifica.

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

Istoricul arată rezultatul și momentul pentru fiecare pas, ceea ce este mai util decât un singur indicator de succes. Pentru sarcinile care modifică date, adaugă și verificarea proprie a aplicației: un număr de rânduri, o sumă de control sau un rând de stare scris de sarcină. Două înregistrări independente fac o nouă încercare sigură, iar istoricul de sarcini înregistrat este primul dintre ele.

Reconciliază înainte de a retrimite

Când conexiunea de observare dispare, găsește rularea existentă înainte de a începe alta. Citește rezultatele pașilor ei și decide dacă munca a fost confirmată, finalizată parțial sau nu a început niciodată. Abia apoi aplică regula de reîncercare definită de fluxul de lucru, pentru că o retrimitere oarbă poate duplica o încărcare sau poate eșua din nou la jumătatea drumului.

Păstrează proprietarul durabil și rezultatul inspectabil, iar o scurtă defecțiune de acces devine un inconvenient în loc de o presupunere. Acesta este întregul scop al designului: munca ar trebui să supraviețuiască conexiunii care a cerut-o.