Lang SQL-jobb: hald han i gang når VPN fell

VPN fell tjue minutt inn i ein indeksgjenoppbygging, SQL-klienten din viser ei broten tilkopling, og det openberre spørsmålet har ikkje noko svar i den feilen. Vart setninga ferdig, rulla tilbake, eller heldt ho fram utan deg? Å kopla til på nytt og senda inn på nytt er det dårlegaste av dei tre alternativa, fordi det gjer eitt usikkert utfall til to moglege. Flytt arbeidet til noko med ein varig eigar før neste vindauge.

Kva tilkoplingsfeilen ikkje fortel deg

Ein feil på klientsida skildrar klienten. Han melder at sockelen vart lukka, ikkje kva serveren gjorde med transaksjonen. Setninga køyrer kanskje framleis, vart kanskje committa like før sambandet døydde, eller vart rulla tilbake då økta vart rydda. Alle tre gir same meldinga på laptoppen din.

Berre tilstanden til serveren kan avgjera det. Sjå der før du bestemmer noko.

Gi arbeidet ein eigar på serversida

For arbeid som ikkje treng eit menneske til å følgja med, lat databaseverten eiga køyringa. SQL Server Agent køyrer jobbar på førespurnad eller etter ein plan og registrerer kvar køyring, så livssyklusen til jobben er uavhengig av VPN-økta di. Jobbidentiteten treng nøyaktig dei løyva oppgåva krev, ikkje den fulle interaktive konteksten til ein administrator. Laptoppen startar då arbeidet og les resultat i staden for å vera prosessen som held det i live.

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

Tilgjengelegheita til Agent avheng av utgåva og tenesta du har sett ut. Bruk mekanismen plattformen din faktisk tilbyr i staden for å gå ut frå at denne finst overalt.

Ein hoppvert nær databasen kortar vegen og er verdt å ha, men han endrar ikkje eigarskapsspørsmålet. Økta sluttar likevel når nettverket sluttar. Bruk han til å observera, ikkje til å vera det som held arbeidet i live.

Legg att ei registrering som neste økt kan lesa

Noter eit jobbnamn eller ein identifikator, måldatabasen og resultatet du ventar. Det er den registreringa som lèt ei anna økt, eller ein annan person, svara på spørsmålet feilen ikkje kunne svara på. Utan ho har du eit vagt minne om ei oppdatering og ingen måte å kontrollera.

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

Historia viser utfall og tid per trinn, noko som er nyttigare enn eitt suksessflagg. For oppgåver som endrar data, legg òg til verifiseringa til applikasjonen sjølv: eit radtal, ein sjekksum eller ei statusrad skriven av jobben. To uavhengige registreringar er det som gjer eit nytt forsøk trygt, og den registrerte jobbhistoria er den første av dei.

Stem av før du sender på nytt

Når den observerande tilkoplinga forsvinn, finn den eksisterande køyringa før du startar ei ny. Les trinnutfalla og avgjer om arbeidet vart committa, delvis fullført eller aldri starta. Først då brukar du gjenopprettingsregelen arbeidsflyten definerer, fordi ei blind innsending på nytt kan duplisera ei innlasting eller feila halvvegs ein andre gong.

Hald på den varige eigaren og det inspiserbare utfallet, og ein kort tilgangsfeil vert ei ulempe i staden for ei gissing. Det er heile designmålet: arbeidet bør overleva tilkoplinga som bad om det.