Lång SQL-uppgift: håll den igång när VPN:en fallerar

VPN:en fallerar tjugo minuter in i en indexombyggnad, din SQL-klient visar en bruten anslutning, och den självklara frågan har inget svar i det felet. Avslutades satsen, rullades den tillbaka, eller fortsatte den utan dig? Att återansluta och skicka igen är det sämsta av de tre alternativen, eftersom det gör ett osäkert utfall till två möjliga. Flytta arbetet till något med en varaktig ägare före nästa fönster.

Vad anslutningsfelet inte berättar för dig

Ett fel på klientsidan beskriver klienten. Det rapporterar att socketen stängdes, inte vad servern gjorde med transaktionen. Satsen körs kanske fortfarande, committades kanske precis innan länken dog, eller rullades tillbaka när dess session städades. Alla tre ger samma meddelande på din laptop.

Bara serverns tillstånd kan avgöra det. Titta där innan du beslutar något.

Lämna arbetet till en ägare på serversidan

För arbete som inte behöver en människa som övervakar, låt databasvärden äga körningen. SQL Server Agent kör jobb på begäran eller enligt ett schema och registrerar varje körning, så jobbets livscykel är oberoende av din VPN-session. Jobbidentiteten behöver exakt de behörigheter som uppgiften kräver, inte en administratörs fullständiga interaktiva kontext. Då startar laptopen arbetet och läser resultat i stället för att vara processen som håller det vid liv.

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

Agentens tillgänglighet beror på den utgåva och tjänst du har distribuerat. Använd den mekanism som din plattform faktiskt erbjuder i stället för att anta att den här finns överallt.

En hoppvärd nära databasen förkortar vägen och är värd att ha, men den ändrar inte ägandefrågan. Sessionen tar fortfarande slut när nätverket tar slut. Använd den för att observera, inte för att vara det som håller arbetet vid liv.

Lämna en registrering som nästa session kan läsa

Anteckna ett jobbnamn eller en identifierare, måldatabasen och det resultat du förväntar dig. Det är den registreringen som låter en annan session, eller en annan person, svara på frågan felet inte kunde besvara. Utan den har du ett vagt minne av en uppdatering och inget sätt att kontrollera.

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

Historiken visar utfall och tid per steg, vilket är mer användbart än en enda framgångsflagga. För uppgifter som ändrar data, lägg också till applikationens egen verifiering: ett radantal, en kontrollsumma eller en statusrad som skrivs av jobbet. Två oberoende registreringar är det som gör ett nytt försök säkert, och den registrerade jobbhistoriken är den första av dem.

Stäm av innan du skickar igen

När den observerande anslutningen försvinner, hitta den befintliga körningen innan du startar en ny. Läs dess stegresultat och avgör om arbetet committades, delvis slutfördes eller aldrig startade. Först då tillämpar du den repetitionsregel som arbetsflödet definierar, eftersom en blind omsändning kan duplicera en inläsning eller misslyckas halvvägs en andra gång.

Behåll den varaktiga ägaren och det granskningsbara resultatet, och ett kort åtkomstfel blir en olägenhet i stället för en gissning. Det är hela designmålet: arbetet bör överleva anslutningen som bad om det.