Si un Linked Server desde SQL Server hacia MySQL deja de funcionar después de instalar un parche de Windows Server, una causa posible es la incompatibilidad entre la actualización de seguridad, las librerías TLS/Schannel del sistema operativo y una versión antigua del driver MySQL Connector/ODBC. La solución recomendada es actualizar el driver ODBC, validar los DSNs afectados y corregir las referencias del Registro de Windows si los orígenes de datos quedan asociados a una versión anterior del controlador.
El problema: una actualización de Windows rompió los Linked Servers a MySQL
A todos nos ha pasado alguna vez: llega la ventana de mantenimiento, se aplican las actualizaciones acumulativas de seguridad en Windows Server y, al día siguiente, empiezan los incidentes. Procesos que funcionaban correctamente dejan de responder, conexiones que estaban estables comienzan a fallar y tareas críticas quedan interrumpidas sin una causa evidente a simple vista.
Recientemente nos enfrentamos a un caso de este tipo. Después de instalar la actualización de seguridad KB5094128 en el sistema operativo, todos los Linked Servers configurados desde SQL Server hacia instancias remotas de MySQL dejaron de funcionar. El impacto era directo: consultas distribuidas, procesos de integración y flujos de información que dependían de esos vínculos quedaron afectados.
El error en SQL Server Management Studio era genérico, por lo que el primer paso fue aplicar una regla básica de administración de bases de datos: aislar el problema. Antes de modificar Linked Servers, credenciales o configuraciones de SQL Server, era necesario verificar si el origen del error estaba en la conexión ODBC.
Diagnóstico inicial: el problema estaba en el driver ODBC
La revisión comenzó en el Administrador de Orígenes de Datos ODBC de 64 bits del servidor. Allí se probó el DSN de sistema utilizado para conectar SQL Server con MySQL. El resultado fue contundente: al presionar el botón de prueba, la herramienta de ODBC sufría un cierre inesperado. No devolvía un error de autenticación, timeout o configuración. Simplemente se cerraba.
Ese comportamiento indicaba que el problema no estaba necesariamente en la consulta SQL ni en la definición del Linked Server, sino en una capa inferior: el driver ODBC o las librerías nativas utilizadas para establecer la conexión.
Para profundizar el diagnóstico, se habilitó el trazado de ODBC. La secuencia fallaba al ingresar en la función nativa SQLDriverConnectW, antes de retornar un código de error controlado. Esto permitió identificar que el incidente no era una falla lógica de configuración, sino un problema de compatibilidad a nivel de driver.
Causa probable: incompatibilidad entre TLS, Schannel y MySQL Connector/ODBC
El diagnóstico técnico indicó que la actualización de seguridad había endurecido los requisitos criptográficos asociados a Schannel y TLS en Windows. El driver instalado, MySQL Connector/ODBC 9.2, no lograba negociar correctamente esos nuevos requisitos del sistema operativo. Como consecuencia, se producía una violación de acceso en memoria que terminaba cerrando el proceso.
Este tipo de incidentes es particularmente delicado porque no siempre deja mensajes claros para el administrador. Desde SQL Server, el error puede parecer genérico. Desde ODBC, la herramienta puede cerrarse sin explicación. Y desde la aplicación, simplemente se observa que la integración dejó de funcionar.
La lección principal es clara: cuando una actualización de seguridad modifica componentes del sistema operativo relacionados con conectividad, cifrado o librerías nativas, los drivers de terceros pueden quedar expuestos si no están actualizados.
Solución paso a paso
La solución definitiva fue actualizar el driver MySQL Connector/ODBC a una versión compatible y más reciente. En este caso, se reemplazó MySQL Connector/ODBC 9.2 por MySQL Connector/ODBC 9.7 de 64 bits.
Durante la instalación, Windows informó que algunos archivos a reemplazar estaban bloqueados por procesos de SQL Server. Para resolverlo de forma controlada y evitar un reinicio completo del servidor físico, se detuvieron temporalmente los servicios de SQL Server y SQL Server Agent. Con esos servicios detenidos, el instalador pudo reemplazar las librerías antiguas por las nuevas en pocos segundos.
Este paso fue clave porque SQL Server puede mantener cargadas en memoria determinadas DLL utilizadas por drivers externos. Si esas librerías están bloqueadas, la actualización del driver puede quedar incompleta o requerir un reinicio del servidor. Detener los servicios de forma planificada permitió una intervención más limpia.
El problema posterior: DSNs huérfanos después de actualizar el driver
La actualización del driver resolvió el problema de compatibilidad, pero generó un efecto secundario habitual: los DSNs existentes quedaron asociados al nombre anterior del driver. Al abrir el Administrador de ODBC, algunos orígenes de datos mostraban el mensaje: “The driver of this 64-bit System DSN does not exist”.
Si se trata de un solo DSN, recrearlo manualmente puede ser aceptable. Pero cuando existen múltiples entornos, como Producción, Test y Desarrollo, volver a cargar IPs, puertos, nombres de base, parámetros y credenciales puede consumir tiempo y aumentar el riesgo de error.
Para evitar una reconfiguración completa, se trabajó directamente sobre el Registro de Windows.
Cómo corregir los DSNs desde el Registro de Windows
La corrección se realizó desde regedit, navegando a la siguiente ruta:
HKLM\SOFTWARE\ODBC\ODBC.INI\
Dentro de la clave ODBC Data Sources, se modificó el valor de los DSNs afectados para reemplazar el nombre del driver anterior:
MySQL ODBC 9.2 ANSI Driver
por el nombre exacto del nuevo driver:
MySQL ODBC 9.7 ANSI Driver
Luego, se ingresó a la subcarpeta individual de cada DSN afectado y se actualizó el valor Driver, modificando la ruta de la DLL para que apuntara al directorio correspondiente a la versión 9.7.
Después de este ajuste, el Administrador de ODBC volvió a reconocer los DSNs, el botón de configuración quedó habilitado y la configuración original se mantuvo intacta.
Resultado final
Una vez corregidas las referencias del Registro, se realizaron las pruebas correspondientes. Primero, el test desde el Administrador de ODBC devolvió una conexión exitosa. Luego, se iniciaron nuevamente los servicios de SQL Server y SQL Server Agent para que el motor cargara la nueva DLL del driver actualizado.
Finalmente, se ejecutó el Test Connection del Linked Server desde SQL Server Management Studio y la conexión con MySQL volvió a funcionar correctamente. Los flujos de datos se restablecieron y los procesos dependientes del Linked Server pudieron operar nuevamente.
Este caso dejó varias lecciones importantes para administradores de bases de datos, equipos de infraestructura y responsables de plataformas de información:
- las actualizaciones de seguridad pueden afectar drivers de terceros;
- los errores de Linked Server no siempre se originan en SQL Server;
- probar el DSN desde ODBC ayuda a aislar el problema;
- un crash en ODBC suele indicar conflicto con el driver o librerías nativas;
- mantener drivers actualizados reduce riesgos de compatibilidad;
- los DSNs pueden quedar huérfanos después de actualizar un driver;
- el Registro de Windows permite corregir referencias sin recrear todo desde cero;
- detener servicios de SQL Server puede evitar bloqueos durante la actualización del driver.
Recomendación para entornos productivos
En entornos productivos, no alcanza con aplicar parches de seguridad y esperar que todo continúe funcionando. Las actualizaciones acumulativas son necesarias por cumplimiento, seguridad y reducción de vulnerabilidades, pero deben formar parte de una estrategia de mantenimiento más amplia.
Antes de aplicar parches en servidores que integran SQL Server con fuentes externas, conviene revisar:
- versión de drivers ODBC instalados;
- matriz de compatibilidad con el sistema operativo;
- dependencias de Linked Servers;
- procesos críticos que consumen esas conexiones;
- ventanas de prueba en ambientes no productivos;
- plan de rollback;
- documentación de DSNs, credenciales, puertos y rutas de drivers.
Este tipo de control preventivo puede evitar interrupciones críticas y reducir significativamente el tiempo de troubleshooting.
En BigTelligent trabajamos con administración, mantenimiento, integración y optimización de plataformas de datos basadas en SQL Server, Azure, Power BI, Microsoft Fabric, Data Warehouse, Qlik y soluciones de conectividad con sistemas externos.
Casos como este muestran que una plataforma de datos confiable no depende solo del motor de base de datos. También requiere una gestión integral de drivers, conectores, seguridad, compatibilidad, monitoreo, mantenimiento y arquitectura.
Nuestro enfoque busca ayudar a las organizaciones a reducir riesgos operativos, mejorar la continuidad de sus plataformas y asegurar que sus integraciones críticas funcionen de manera estable y escalable.
Preguntas frecuentes
¿Por qué puede fallar un Linked Server después de una actualización de Windows?
Porque una actualización de seguridad puede modificar componentes del sistema operativo relacionados con TLS, Schannel, conectividad o librerías nativas. Si el driver ODBC no es compatible con esos cambios, la conexión puede fallar.
¿Cómo saber si el problema está en SQL Server o en el driver ODBC?
Una buena práctica es probar primero el DSN desde el Administrador de Orígenes de Datos ODBC. Si el test falla o la herramienta se cierra, el problema probablemente esté en el driver, el DSN o la capa de conectividad, no en la consulta SQL.
¿Es recomendable actualizar el driver MySQL Connector/ODBC?
Sí. Mantener actualizado el driver reduce riesgos de incompatibilidad, mejora estabilidad y permite adaptarse a cambios de seguridad del sistema operativo.
¿Qué significa que un DSN quede huérfano?
Significa que el DSN sigue existiendo, pero apunta a un driver que ya no está registrado o fue reemplazado por una nueva versión. En ese caso, Windows no puede utilizarlo correctamente hasta que se actualice la referencia.
¿Se deben recrear todos los DSNs después de actualizar el driver?
No necesariamente. Si la configuración original sigue en el Registro de Windows, es posible corregir las referencias al nuevo driver y conservar los parámetros existentes.
Conclusión
Las actualizaciones de seguridad en Windows Server son necesarias, pero pueden generar efectos colaterales en componentes de conectividad, especialmente cuando existen drivers ODBC desactualizados o integraciones con sistemas externos.
En este caso, un parche de seguridad afectó Linked Servers desde SQL Server hacia MySQL debido a una incompatibilidad con el driver MySQL Connector/ODBC instalado. El problema se resolvió actualizando el driver, corrigiendo las referencias de los DSNs en el Registro de Windows y reiniciando los servicios de SQL Server para cargar correctamente las nuevas librerías.
La principal enseñanza es que la administración de bases de datos no termina en el motor SQL. También incluye drivers, conectores, compatibilidad, seguridad, mantenimiento preventivo y documentación. Una buena estrategia de plataforma reduce riesgos, evita interrupciones y permite que los datos sigan fluyendo cuando el negocio los necesita.
