Trabajo SQL largo: mantenlo en marcha cuando cae la VPN

La VPN se cae veinte minutos después de empezar una reconstrucción de índice, tu cliente SQL muestra una conexión rota y la pregunta obvia no tiene respuesta en ese error. ¿Terminó la sentencia, se revirtió o siguió ejecutándose sin ti? Reconectar y reenviar es la peor de las tres opciones, porque convierte un resultado incierto en dos posibles. Mueve el trabajo a algo con un propietario duradero antes de la siguiente ventana.

Lo que el error de conexión no te dice

Un error del lado del cliente describe al cliente. Informa de que el socket se cerró, no de lo que hizo el servidor con la transacción. La sentencia puede seguir ejecutándose, puede haberse confirmado justo antes de que muriera el enlace o puede haberse revertido cuando se limpió su sesión. Las tres producen el mismo mensaje en tu portátil.

Solo el estado del servidor puede resolverlo. Mira allí antes de decidir nada.

Entrega el trabajo a un propietario del lado del servidor

Para el trabajo que no necesita a nadie vigilando, deja que el host de la base de datos sea dueño de la ejecución. SQL Server Agent ejecuta trabajos a petición o según una programación y registra cada ejecución, así que el ciclo de vida del trabajo es independiente de tu sesión VPN. La identidad del trabajo necesita exactamente los permisos que exige la tarea, no el contexto interactivo completo de un administrador. Así el portátil inicia el trabajo y lee los resultados en lugar de ser el proceso que lo mantiene vivo.

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

La disponibilidad de Agent depende de la edición y el servicio que hayas desplegado. Usa el mecanismo que tu plataforma ofrece realmente en lugar de suponer que este existe en todas partes.

Un host de salto cerca de la base de datos acorta el camino y merece la pena, pero no cambia la cuestión de la propiedad. La sesión sigue terminando cuando termina la red. Úsalo para observar, no para ser lo que mantiene vivo el trabajo.

Deja un registro que la siguiente sesión pueda leer

Anota un nombre de trabajo o un identificador, la base de datos de destino y el resultado que esperas. Ese registro es lo que permite que otra sesión, u otra persona, responda la pregunta que el error no pudo. Sin él te queda un recuerdo vago de una actualización y ninguna forma de comprobarlo.

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

El historial muestra el resultado y el tiempo por paso, lo que es más útil que una sola bandera de éxito. Para las tareas que cambian datos, añade también la verificación propia de la aplicación: un recuento de filas, una suma de comprobación o una fila de estado escrita por el trabajo. Dos registros independientes son lo que hace seguro un reintento, y el historial de trabajos registrado es el primero de ellos.

Reconcilia antes de reenviar

Cuando la conexión de observación desaparece, encuentra la ejecución existente antes de empezar otra. Lee los resultados de sus pasos y decide si el trabajo se confirmó, se completó parcialmente o nunca empezó. Solo entonces aplica la regla de reintento que define el flujo de trabajo, porque un reenvío a ciegas puede duplicar una carga o fallar a mitad de camino por segunda vez.

Mantén el propietario duradero y el resultado inspeccionable, y un breve fallo de acceso se convierte en una molestia en lugar de una conjetura. Ese es todo el objetivo del diseño: el trabajo debería sobrevivir a la conexión que lo pidió.