Attività SQL lunga: mantienila in corso quando la VPN cade

La VPN cade venti minuti dopo l’inizio di una ricostruzione dell’indice, il client SQL mostra una connessione interrotta e la domanda ovvia non ha risposta in quell’errore. L’istruzione è terminata, è stata annullata o ha continuato senza di te? Riconnettersi e reinviare è la peggiore delle tre opzioni, perché trasforma un esito incerto in due possibili. Sposta il lavoro su qualcosa con un proprietario durevole prima della finestra successiva.

Cosa non ti dice l’errore di connessione

Un errore lato client descrive il client. Segnala che il socket è stato chiuso, non cosa ha fatto il server con la transazione. L’istruzione potrebbe essere ancora in esecuzione, essere stata confermata subito prima che il collegamento morisse, o essere stata annullata quando la sua sessione è stata ripulita. Tutti e tre producono lo stesso messaggio sul tuo portatile.

Solo lo stato del server può risolverlo. Guarda lì prima di decidere qualsiasi cosa.

Affida il lavoro a un proprietario lato server

Per il lavoro che non richiede una persona a sorvegliare, lascia che l’host del database possieda l’esecuzione. SQL Server Agent esegue i processi su richiesta o secondo una pianificazione e registra ogni esecuzione, così il ciclo di vita del processo è indipendente dalla tua sessione VPN. L’identità del processo ha bisogno esattamente dei permessi richiesti dall’attività, non del contesto interattivo completo di un amministratore. Allora il portatile avvia il lavoro e legge i risultati invece di essere il processo che lo tiene in vita.

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

La disponibilità di Agent dipende dall’edizione e dal servizio distribuiti. Usa il meccanismo che la tua piattaforma offre davvero invece di supporre che questo esista ovunque.

Un host di salto vicino al database accorcia il percorso e vale la pena averlo, ma non cambia la questione della proprietà. La sessione finisce comunque quando finisce la rete. Usalo per osservare, non per essere ciò che tiene in vita il lavoro.

Lascia un registro che la sessione successiva possa leggere

Annota un nome di processo o un identificatore, il database di destinazione e il risultato che ti aspetti. È quel registro che permette a un’altra sessione, o a un’altra persona, di rispondere alla domanda che l’errore non poteva risolvere. Senza, ti resta un ricordo vago di un aggiornamento e nessun modo di verificarlo.

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

La cronologia mostra esito e tempi per ogni passo, cosa più utile di un singolo indicatore di successo. Per le attività che modificano dati, aggiungi anche la verifica propria dell’applicazione: un conteggio di righe, un checksum o una riga di stato scritta dal processo. Due registri indipendenti sono ciò che rende sicuro un nuovo tentativo, e la cronologia dei processi registrata è il primo dei due.

Riconcilia prima di reinviare

Quando la connessione di osservazione scompare, trova l’esecuzione esistente prima di avviarne un’altra. Leggi gli esiti dei suoi passi e decidi se il lavoro è stato confermato, completato in parte o mai iniziato. Solo allora applica la regola di nuovo tentativo definita dal flusso di lavoro, perché un reinvio cieco può duplicare un caricamento o fallire a metà una seconda volta.

Mantieni il proprietario durevole e il risultato ispezionabile, e un breve guasto di accesso diventa un fastidio invece di una supposizione. È tutto l’obiettivo del progetto: il lavoro dovrebbe sopravvivere alla connessione che l’ha richiesto.