Traballo SQL longo: mantelo en marcha cando cae a VPN

A VPN cae vinte minutos despois de comezar unha reconstrución de índice, o teu cliente SQL mostra unha conexión rota e a pregunta obvia non ten resposta nese erro. Rematou a sentenza, reverteuse ou seguiu executándose sen ti? Reconectar e reenviar é a peor das tres opcións, porque converte un resultado incerto en dous posibles. Move o traballo a algo cun propietario duradeiro antes da seguinte ventá.

O que o erro de conexión non che di

Un erro do lado do cliente describe o cliente. Informa de que o socket se pechou, non do que fixo o servidor coa transacción. A sentenza pode seguir executándose, pode terse confirmado xusto antes de que morrese a ligazón ou pode terse revertido cando se limpou a súa sesión. As tres producen a mesma mensaxe no teu portátil.

Só o estado do servidor pode resolvelo. Mira alí antes de decidir nada.

Entrega o traballo a un propietario do lado do servidor

Para o traballo que non necesita a ninguén vixiando, deixa que o host da base de datos sexa dono da execución. SQL Server Agent executa traballos a petición ou segundo unha programación e rexistra cada execución, así que o ciclo de vida do traballo é independente da túa sesión VPN. A identidade do traballo necesita exactamente os permisos que esixe a tarefa, non o contexto interactivo completo dun administrador. Así o portátil inicia o traballo e le os resultados en lugar de ser o proceso que o mantén vivo.

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

A dispoñibilidade de Agent depende da edición e do servizo que despregases. Usa o mecanismo que a túa plataforma ofrece de verdade en lugar de supoñer que este existe en todas partes.

Un host de salto preto da base de datos acurta o camiño e paga a pena, pero non cambia a cuestión da propiedade. A sesión segue rematando cando remata a rede. Úsao para observar, non para ser o que mantén vivo o traballo.

Deixa un rexistro que a seguinte sesión poida ler

Anota un nome de traballo ou un identificador, a base de datos de destino e o resultado que esperas. Ese rexistro é o que permite que outra sesión, ou outra persoa, responda a pregunta que o erro non puido. Sen el queda un recordo vago dunha actualización e ningunha forma de comprobalo.

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

O historial mostra o resultado e o tempo por paso, o que é máis útil que unha soa bandeira de éxito. Para as tarefas que cambian datos, engade tamén a verificación propia da aplicación: un reconto de filas, unha suma de comprobación ou unha fila de estado escrita polo traballo. Dous rexistros independentes son o que fai seguro un reintento, e o historial de traballos rexistrado é o primeiro deles.

Reconcilia antes de reenviar

Cando a conexión de observación desaparece, atopa a execución existente antes de comezar outra. Le os resultados dos seus pasos e decide se o traballo se confirmou, se se completou parcialmente ou se nunca comezou. Só entón aplica a regra de reintento que define o fluxo de traballo, porque un reenvío ás cegas pode duplicar unha carga ou fallar a metade de camiño por segunda vez.

Mantén o propietario duradeiro e o resultado inspeccionable, e unha breve falla de acceso convértese nunha molestia en lugar dunha suposición. Ese é todo o obxectivo do deseño: o traballo debería sobrevivir á conexión que o pediu.