Tâche SQL longue : gardez-la en cours quand le VPN tombe

Le VPN tombe vingt minutes après le début d’une reconstruction d’index, votre client SQL affiche une connexion rompue, et la question évidente n’a pas de réponse dans cette erreur. L’instruction s’est-elle terminée, annulée, ou a-t-elle continué sans vous ? Se reconnecter et renvoyer est la pire des trois options, car elle transforme un résultat incertain en deux résultats possibles. Déplacez le travail vers quelque chose qui a un propriétaire durable avant la prochaine fenêtre.

Ce que l’erreur de connexion ne vous dit pas

Une erreur côté client décrit le client. Elle signale que la socket s’est fermée, pas ce que le serveur a fait de la transaction. L’instruction s’exécute peut-être encore, a peut-être été validée juste avant la mort du lien, ou a peut-être été annulée lors du nettoyage de sa session. Les trois produisent le même message sur votre ordinateur portable.

Seul l’état du serveur peut trancher. Regardez là avant de décider quoi que ce soit.

Confiez le travail à un propriétaire côté serveur

Pour un travail qui ne demande personne pour le surveiller, laissez l’hôte de la base de données posséder l’exécution. SQL Server Agent exécute des tâches à la demande ou selon une planification et enregistre chaque exécution, de sorte que le cycle de vie de la tâche est indépendant de votre session VPN. L’identité de la tâche a besoin exactement des autorisations que demande le travail, pas du contexte interactif complet d’un administrateur. L’ordinateur portable lance alors le travail et lit les résultats au lieu d’être le processus qui le maintient en vie.

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

La disponibilité d’Agent dépend de l’édition et du service que vous avez déployés. Utilisez le mécanisme que votre plateforme fournit réellement au lieu de supposer que celui-ci existe partout.

Un hôte de saut proche de la base de données raccourcit le chemin et vaut la peine, mais il ne change pas la question de la propriété. La session se termine toujours quand le réseau se termine. Utilisez-le pour observer, pas pour être ce qui maintient le travail en vie.

Laissez un enregistrement que la prochaine session pourra lire

Notez un nom de tâche ou un identifiant, la base de données cible et le résultat attendu. C’est cet enregistrement qui permet à une autre session, ou à une autre personne, de répondre à la question que l’erreur ne pouvait pas trancher. Sans lui, il vous reste un souvenir vague d’une mise à jour et aucun moyen de vérifier.

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

L’historique montre le résultat et le minutage par étape, ce qui est plus utile qu’un simple indicateur de succès. Pour les tâches qui modifient des données, ajoutez aussi la vérification propre à l’application : un nombre de lignes, une somme de contrôle ou une ligne d’état écrite par la tâche. Deux enregistrements indépendants sont ce qui rend une nouvelle tentative sûre, et l’historique des tâches enregistré est le premier des deux.

Réconciliez avant de renvoyer

Quand la connexion d’observation disparaît, retrouvez l’exécution existante avant d’en lancer une autre. Lisez le résultat de ses étapes et décidez si le travail a été validé, partiellement terminé ou jamais commencé. C’est seulement alors que vous appliquez la règle de nouvelle tentative définie par le processus, car un renvoi aveugle peut dupliquer un chargement ou échouer à mi-chemin une seconde fois.

Conservez le propriétaire durable et le résultat inspectable, et une brève panne d’accès devient une gêne plutôt qu’une supposition. C’est tout l’objectif de conception : le travail devrait survivre à la connexion qui l’a demandé.