Dolgo opravilo SQL: ohranite ga v teku, ko VPN pade

VPN pade dvajset minut po začetku obnove indeksa, vaš odjemalec SQL prikaže prekinjeno povezavo, in očitno vprašanje v tej napaki nima odgovora. Ali se je stavek končal, se zavrnil ali je nadaljeval brez vas? Ponovna povezava in ponovno pošiljanje je najslabša od treh možnosti, ker en negotov izid spremeni v dva možna. Pred naslednjim oknom premaknite delo na nekaj s trajnim lastnikom.

Česa vam napaka povezave ne pove

Napaka na strani odjemalca opisuje odjemalca. Sporoča, da se je vtičnica zaprla, ne pa, kaj je strežnik storil s transakcijo. Stavek se morda še izvaja, morda je bil potrjen tik preden je povezava umrla, ali pa je bil zavrnjen, ko je bila seja počiščena. Vsi trije na vašem prenosniku ustvarijo isto sporočilo.

To lahko razreši samo stanje strežnika. Poglejte tja, preden karkoli odločite.

Predajte delo lastniku na strani strežnika

Pri delu, ki ne potrebuje človeka, ki bi ga nadzoroval, pustite gostitelju podatkovne baze lastništvo izvajanja. SQL Server Agent izvaja opravila na zahtevo ali po urniku in zabeleži vsako izvajanje, zato je življenjski cikel opravila neodvisen od vaše seje VPN. Identiteta opravila potrebuje natanko tista dovoljenja, ki jih zahteva naloga, ne celotnega interaktivnega konteksta skrbnika. Prenosnik nato začne delo in bere rezultate, namesto da bi bil proces, ki ga ohranja pri življenju.

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

Razpoložljivost Agenta je odvisna od izdaje in storitve, ki ste ju uvedli. Uporabite mehanizem, ki ga vaša platforma dejansko ponuja, namesto da predpostavljate, da ta obstaja povsod.

Skakalni gostitelj blizu podatkovne baze skrajša pot in ga je vredno imeti, vendar ne spremeni vprašanja lastništva. Seja se vseeno konča, ko se konča omrežje. Uporabite ga za opazovanje, ne kot stvar, ki ohranja delo pri življenju.

Pustite zapis, ki ga bo lahko prebrala naslednja seja

Zapišite ime opravila ali identifikator, ciljno podatkovno bazo in rezultat, ki ga pričakujete. Prav ta zapis omogoča drugi seji ali drugi osebi, da odgovori na vprašanje, na katero napaka ni mogla. Brez njega ostane nejasen spomin na posodobitev in nobenega načina za preverjanje.

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

Zgodovina prikazuje izid in čas za vsak korak, kar je bolj uporabno kot ena sama zastavica uspeha. Pri nalogah, ki spreminjajo podatke, dodajte tudi lastno preverjanje aplikacije: število vrstic, kontrolno vsoto ali statusno vrstico, ki jo zapiše opravilo. Dva neodvisna zapisa naredita ponovni poskus varen, in zabeležena zgodovina opravil je prvi od njiju.

Uskladite, preden znova pošljete

Ko opazovalna povezava izgine, poiščite obstoječe izvajanje, preden začnete drugo. Preberite rezultate njegovih korakov in se odločite, ali je bilo delo potrjeno, delno dokončano ali se nikoli ni začelo. Šele nato uporabite pravilo ponovnega poskusa, ki ga določa delovni tok, ker lahko slepo ponovno pošiljanje podvoji nalaganje ali drugič spodleti na pol poti.

Ohranite trajnega lastnika in pregledni rezultat, in kratka napaka pri dostopu postane nevšečnost namesto ugibanja. To je ves cilj zasnove: delo bi moralo preživeti povezavo, ki ga je zahtevalo.