Qué pasa cuando una actualización de SQL Server se queda a medias

Una actualización acumulativa de SQL Server no es una instalación: es una migración del motor y de sus bases de sistema. Cuando termina bien, nadie se entera. Cuando se interrumpe a la mitad —porque el servicio se reinició, porque un disco se llenó, porque una base quedó en un estado que el script no esperaba— el motor arranca, empieza a aplicar el cambio sobre master, no puede cerrarlo y se detiene. Desde afuera todo parece un servicio caído. Desde adentro, el motor está haciendo exactamente lo que le pidieron: no dejar a medias un cambio estructural.

Esto lo vivimos en un cliente del sector farmacéutico, en plena operación. La historia completa está resumida en un caso publicado: el servicio volvió en cuarenta minutos y el ambiente original se reconstruyó esa misma noche. Lo que sigue es cómo se llega a esa decisión.

Primero: leer, no reiniciar

El primer impulso —reiniciar el servicio a ver si arranca— es el peor. Cada reinicio vuelve a lanzar el mismo script de actualización, que vuelve a fallar en el mismo punto, y de paso agrega ruido al diagnóstico. Antes de tocar nada hay que ir al registro del servidor, el ERRORLOG del motor, que está en la carpeta LOG de la instancia y se puede leer con cualquier editor aunque el servicio no esté arriba.

Ahí aparece la frase que ordena todo lo demás. Una actualización que no cierra suele dejar un mensaje sobre el nivel de script de la base master, con el número de paso en el que se detuvo y el error que lo detuvo. Ese número es el que importa: dice si el motor se quedó esperando espacio, si tropezó con un objeto que alguien modificó a mano años atrás, o si una base de usuario quedó en recuperación y bloquea el resto.

Lo que se mira, en orden

• El último bloque del ERRORLOG, que dice en qué paso de la actualización se detuvo.
• El espacio libre en las unidades de datos, de registro de transacciones y de la base tempdb.
• El estado de cada base: si alguna quedó en recuperación o sospechosa, el arranque no va a cerrar.
• El visor de eventos de Windows, para saber si el servicio se detuvo solo o lo detuvo algo más: un reinicio por actualización del sistema operativo, un agente de respaldo, una política de grupo.

Segundo: decidir contra el reloj, no contra el orgullo

Con el diagnóstico en la mano aparece la pregunta real, y no es técnica: ¿cuánto vale cada minuto de esta base detenida? Reparar el motor en su sitio puede tomar veinte minutos o tres horas, y esa incertidumbre es el problema. Un diagnóstico honesto no dice «lo arreglo»; dice «no sé todavía cuánto tarda».

Por eso, cuando existe una réplica sincronizada y la operación está corriendo, la decisión correcta casi siempre es la misma: conmutar. El servicio vuelve con un tiempo acotado y conocido, la presión desaparece, y la reparación del nodo original deja de ser una emergencia para convertirse en un trabajo de ventana nocturna, con calma y con evidencia.

Eso es lo que hace que una réplica valga lo que cuesta. No está ahí para un desastre de película: está ahí para el martes en que una actualización se queda a medias.

Tercero: reconstruir y dejarlo escrito

Una vez el servicio está arriba en la réplica, el nodo original se reconstruye sin público: se completa o se revierte la actualización, se valida la integridad de las bases, se vuelve a establecer la sincronización y se confirma que el conjunto quedó otra vez con dos nodos sanos. Lo que no puede faltar después es el análisis del evento por escrito, con la causa, el tiempo real de indisponibilidad y qué cambia para la próxima.

Lo que evita que vuelva a pasar

• Ventana de parcheo con plan de reversión, notificada antes, no avisada después.
• Respaldo verificado inmediatamente antes de aplicar la actualización, incluidas las bases de sistema.
• Actualizar primero el nodo que no atiende la operación, y conmutar solo cuando ese ya está sano.
• Umbrales de espacio vigilados, para que el disco no sea la causa raíz de un incidente de base de datos.

Ninguna de esas cuatro cosas es cara. La que sí sale cara es la otra: descubrir en medio del incidente que la réplica existía, pero que nadie había conmutado nunca a ella.

Si quiere revisar cómo está parada su plataforma de datos, escríbanos: el diagnóstico es acotado y de ahí sale un mapa, no una propuesta de cuarenta páginas.