Lang SQL-jobb: hold den i gang når VPN faller

VPN faller tjue minutter inn i en indeksgjenoppbygging, SQL-klienten din viser en brutt forbindelse, og det åpenbare spørsmålet har ikke noe svar i den feilen. Ble setningen ferdig, rullet tilbake, eller fortsatte den uten deg? Å koble til på nytt og sende inn på nytt er det dårligste av de tre alternativene, fordi det gjør ett usikkert utfall til to mulige. Flytt arbeidet til noe med en varig eier før neste vindu.

Hva tilkoblingsfeilen ikke forteller deg

En feil på klientsiden beskriver klienten. Den melder at sockelen ble lukket, ikke hva serveren gjorde med transaksjonen. Setningen kjører kanskje fortsatt, ble kanskje committet like før forbindelsen døde, eller ble rullet tilbake da økten ble ryddet. Alle tre gir samme melding på laptopen din.

Bare serverens tilstand kan avgjøre det. Se der før du bestemmer noe.

Gi arbeidet en eier på serversiden

For arbeid som ikke trenger et menneske til å følge med, la databaseverten eie kjøringen. SQL Server Agent kjører jobber på forespørsel eller etter en plan og registrerer hver kjøring, så jobbens livssyklus er uavhengig av VPN-økten din. Jobbidentiteten trenger nøyaktig de tillatelsene oppgaven krever, ikke en administratørs fulle interaktive kontekst. Laptopen starter da arbeidet og leser resultater i stedet for å være prosessen som holder det i live.

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

Agentens tilgjengelighet avhenger av utgaven og tjenesten du har distribuert. Bruk mekanismen plattformen din faktisk tilbyr i stedet for å anta at denne finnes overalt.

En hoppvert nær databasen forkorter veien og er verdt å ha, men den endrer ikke eierskapsspørsmålet. Økten avsluttes fortsatt når nettverket avsluttes. Bruk den til å observere, ikke til å være det som holder arbeidet i live.

Legg igjen en registrering som neste økt kan lese

Noter et jobbnavn eller en identifikator, måldatabasen og resultatet du forventer. Det er den registreringen som lar en annen økt, eller en annen person, svare på spørsmålet feilen ikke kunne svare på. Uten den har du et vagt minne om en oppdatering og ingen måte å kontrollere.

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

Historikken viser utfall og tid per trinn, noe som er nyttigere enn ett enkelt suksessflagg. For oppgaver som endrer data, legg også til applikasjonens egen verifisering: et radantall, en sjekksum eller en statusrad skrevet av jobben. To uavhengige registreringer er det som gjør et nytt forsøk trygt, og den registrerte jobbhistorikken er den første av dem.

Avstem før du sender på nytt

Når den observerende forbindelsen forsvinner, finn den eksisterende kjøringen før du starter en ny. Les trinnutfallene og avgjør om arbeidet ble committet, delvis fullført eller aldri startet. Først da anvender du gjenopprettingsregelen arbeidsflyten definerer, fordi en blind innsending på nytt kan duplisere en innlasting eller feile halvveis en andre gang.

Behold den varige eieren og det inspiserbare utfallet, og en kort tilgangsfeil blir en ulempe i stedet for en gjetning. Det er hele designmålet: arbeidet bør overleve forbindelsen som ba om det.