Feina SQL llarga: manteniu-la en marxa quan cau la VPN

La VPN cau vint minuts després de començar una reconstrucció d’índex, el client SQL mostra una connexió trencada i la pregunta òbvia no té resposta en aquest error. L’ordre ha acabat, s’ha desfet o ha continuat executant-se sense vosaltres? Tornar a connectar-se i tornar a enviar és la pitjor de les tres opcions, perquè converteix un resultat incert en dos de possibles. Traslladeu la feina a alguna cosa amb un propietari durador abans de la finestra següent.

Què no us diu l’error de connexió

Un error del costat del client descriu el client. Informa que el sòcol s’ha tancat, no què ha fet el servidor amb la transacció. L’ordre encara es pot estar executant, pot haver-se confirmat just abans que morís l’enllaç, o pot haver-se desfet quan s’ha netejat la seva sessió. Les tres coses produeixen el mateix missatge al vostre portàtil.

Només l’estat del servidor ho pot resoldre. Mireu-hi abans de decidir res.

Passeu la feina a un propietari del costat del servidor

Per a la feina que no necessita ningú vigilant, deixeu que l’amfitrió de la base de dades posseeixi l’execució. SQL Server Agent executa tasques a demanda o segons una programació i enregistra cada execució, de manera que el cicle de vida de la tasca és independent de la vostra sessió VPN. La identitat de la tasca necessita exactament els permisos que demana la feina, no el context interactiu complet d’un administrador. Llavors el portàtil inicia la feina i llegeix els resultats en lloc de ser el procés que la manté viva.

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

La disponibilitat de l’Agent depèn de l’edició i del servei que hàgiu desplegat. Feu servir el mecanisme que la vostra plataforma ofereix realment en lloc de suposar que aquest existeix a tot arreu.

Un amfitrió de salt a prop de la base de dades escurça el camí i val la pena tenir-lo, però no canvia la qüestió de la propietat. La sessió igualment acaba quan acaba la xarxa. Feu-lo servir per observar, no per ser la cosa que manté la feina viva.

Deixeu un registre que la sessió següent pugui llegir

Anoteu un nom de tasca o un identificador, la base de dades objectiu i el resultat que espereu. Aquest registre és el que permet que una altra sessió, o una altra persona, respongui la pregunta que l’error no podia. Sense ell us queda un record vague d’una actualització i cap manera de comprovar-ho.

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

L’historial mostra el resultat i el moment de cada pas, cosa més útil que una sola bandera d’èxit. Per a les tasques que canvien dades, afegiu també la verificació pròpia de l’aplicació: un recompte de files, una suma de verificació o una fila d’estat escrita per la tasca. Dos registres independents són el que fa segur un reintent, i el registre de l’historial de tasques n’és el primer.

Reconcilieu abans de tornar a enviar

Quan la connexió d’observació desapareix, trobeu l’execució existent abans de començar-ne una altra. Llegiu-ne els resultats dels passos i decidiu si la feina s’ha confirmat, s’ha completat parcialment o no ha començat mai. Només llavors apliqueu la regla de reintent que defineix el flux de treball, perquè un reenviament a cegues pot duplicar una càrrega o fallar a mig camí una segona vegada.

Mantingueu el propietari durador i el resultat inspeccionable, i una breu fallada d’accés es converteix en una molèstia en lloc d’una endevinalla. Aquest és tot l’objectiu del disseny: la feina hauria de sobreviure a la connexió que la va demanar.