Lang SQL-werk: houd het draaiend als de VPN wegvalt

De VPN valt twintig minuten na de start van een indexrebuild weg, je SQL-client toont een verbroken verbinding, en de voor de hand liggende vraag heeft geen antwoord in die fout. Is de instructie afgerond, teruggedraaid, of bleef hij zonder jou doorlopen? Opnieuw verbinden en opnieuw indienen is de slechtste van de drie opties, want het maakt één onzekere uitkomst tot twee mogelijke. Verplaats het werk naar iets met een duurzame eigenaar vóór het volgende venster.

Wat de verbindingsfout je niet vertelt

Een fout aan de clientkant beschrijft de client. Hij meldt dat de socket is gesloten, niet wat de server met de transactie heeft gedaan. De instructie draait misschien nog, is misschien net voor het wegvallen van de verbinding vastgelegd, of is teruggedraaid toen de sessie werd opgeruimd. Alle drie geven dezelfde melding op je laptop.

Alleen de toestand van de server kan dat beslechten. Kijk daar voordat je iets beslist.

Geef het werk een eigenaar aan de serverkant

Laat voor werk dat geen mens hoeft te controleren de databasehost de uitvoering bezitten. SQL Server Agent voert taken op verzoek of volgens een schema uit en legt elke run vast, zodat de levenscyclus van de taak onafhankelijk is van je VPN-sessie. De taakidentiteit heeft precies de rechten nodig die de taak vereist, niet de volledige interactieve context van een beheerder. De laptop start dan werk en leest resultaten, in plaats van het proces te zijn dat het in leven houdt.

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

De beschikbaarheid van Agent hangt af van de editie en dienst die je hebt uitgerold. Gebruik het mechanisme dat je platform daadwerkelijk biedt in plaats van aan te nemen dat dit overal bestaat.

Een spronghost dicht bij de database verkort het pad en is de moeite waard, maar verandert niets aan de eigendomsvraag. De sessie eindigt nog steeds wanneer het netwerk eindigt. Gebruik hem om te observeren, niet om het ding te zijn dat het werk in leven houdt.

Laat een registratie achter die de volgende sessie kan lezen

Noteer een taaknaam of identificatie, de doeldatabase en het resultaat dat je verwacht. Juist die registratie stelt een andere sessie, of een ander persoon, in staat de vraag te beantwoorden die de fout niet kon. Zonder die registratie heb je een vage herinnering aan een update en geen manier om die te controleren.

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

De geschiedenis toont resultaat en timing per stap, wat nuttiger is dan één succesvlag. Voeg voor taken die gegevens wijzigen ook de eigen verificatie van de applicatie toe: een rijaantal, een controlesom of een statusrij die door de taak is geschreven. Twee onafhankelijke registraties maken een nieuwe poging veilig, en de vastgelegde taakgeschiedenis is de eerste daarvan.

Verzoen voordat je opnieuw indient

Wanneer de observerende verbinding verdwijnt, zoek de bestaande run voordat je een nieuwe start. Lees de resultaten per stap en beslis of het werk is vastgelegd, gedeeltelijk voltooid of nooit begonnen. Pas daarna de herhaalregel toe die de werkstroom definieert, want een blinde herindiening kan een laadproces dupliceren of een tweede keer halverwege mislukken.

Behoud de duurzame eigenaar en het inspecteerbare resultaat, en een korte toegangsstoring wordt een ongemak in plaats van een gok. Dat is het hele ontwerpdoel: het werk moet de verbinding overleven die erom vroeg.