Lang SQL-opgave: hold den kørende, når VPN falder

VPN'et falder tyve minutter inde i en genopbygning af et indeks, din SQL-klient viser en brudt forbindelse, og det indlysende spørgsmål har ikke noget svar i den fejl. Blev sætningen færdig, rullet tilbage eller fortsatte den uden dig? At genoprette forbindelsen og sende igen er den dårligste af de tre muligheder, fordi den gør ét usikkert udfald til to mulige. Flyt arbejdet over til noget med en holdbar ejer inden det næste vindue.

Hvad forbindelsesfejlen ikke fortæller dig

En fejl på klientsiden beskriver klienten. Den rapporterer, at soklen blev lukket, ikke hvad serveren gjorde ved transaktionen. Sætningen kører måske stadig, blev måske committet lige før forbindelsen døde, eller blev rullet tilbage, da dens session blev ryddet op. Alle tre giver den samme meddelelse på din bærbare.

Kun serverens tilstand kan afgøre det. Se der, før du beslutter noget.

Giv arbejdet en ejer på serversiden

For arbejde der ikke kræver et menneske til at holde øje, lad databaseværten eje udførelsen. SQL Server Agent kører job på kommando eller efter en tidsplan og registrerer hver kørsel, så jobbets livscyklus er uafhængig af din VPN-session. Jobidentiteten skal have præcis de tilladelser, opgaven kræver, ikke en administrators fulde interaktive kontekst. Den bærbare starter så arbejdet og læser resultater i stedet for at være den proces, der holder det i live.

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

Agentens tilgængelighed afhænger af den udgave og tjeneste, du har udrullet. Brug den mekanisme, din platform faktisk tilbyder, i stedet for at antage, at denne findes overalt.

En springvært tæt på databasen forkorter vejen og er værd at have, men den ændrer ikke ejerskabsspørgsmålet. Sessionen slutter stadig, når netværket slutter. Brug den til at observere, ikke til at være det, der holder arbejdet i live.

Efterlad en registrering, som den næste session kan læse

Noter et jobnavn eller en identifikator, måldatabasen og det resultat, du forventer. Det er den registrering, der lader en anden session, eller en anden person, besvare det spørgsmål, fejlen ikke kunne. Uden den har du en vag erindring om en opdatering og ingen måde at kontrollere.

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

Historikken viser udfald og tidsforløb for hvert trin, hvilket er mere nyttigt end et enkelt succesflag. Tilføj for opgaver, der ændrer data, også applikationens egen verifikation: et rækkeantal, en kontrolsum eller en statusrække skrevet af jobbet. To uafhængige registreringer er det, der gør et nyt forsøg sikkert, og den registrerede jobhistorik er den første af dem.

Afstem, før du sender igen

Når den observerende forbindelse forsvinder, find den eksisterende kørsel, før du starter en ny. Læs dens trinudfald, og afgør, om arbejdet blev committet, delvist fuldført eller aldrig startet. Først da anvender du den gentagelsesregel, arbejdsgangen definerer, fordi en blind genafsendelse kan duplikere en indlæsning eller fejle halvvejs anden gang.

Behold den holdbare ejer og det inspicerbare udfald, og en kort adgangsfejl bliver en ulejlighed i stedet for et gæt. Det er hele designmålet: arbejdet bør overleve den forbindelse, der bad om det.