Cómo puede influir la lentitud de discos en la indisponibilidad del servicio de SQL

Es relativamente frecuente encontrarnos con servicios de SQL en clúster que se reinician debido a la lentitud de los discos. Veamos como se produce esto.

En el log de clúster solemos encontrar errores del tipo:

ERR   [RES] SQL Server <SQL Server (Instancia)>: [sqsrvres] CheckQueryProcessorAlive: sqlexecdirect failed

ERR   [RES] SQL Server <SQL Server (Instancia)>: [sqsrvres] printODBCError: sqlstate = 08S01; native error = 0; message = [Microsoft][SQL Server Native Client 10.0]Communication link failure

Este tipo de errores lo primero que nos hacen pensar es en errores de comunicación, y revisamos la red, drivers, etc. Sin embargo, es un tipo de error genérico que puede ser causado por otras causas. En este post nos vamos a centrar en la lentitud de discos.

A veces, el primer paso que nos puede indicar que el error no está relacionado con la red, está en el mismo cluster.log, si encontramos este tipo de mensajes:

ERR   [RES] SQL Server <SQL Server (Instancia)>: [sqsrvres] checkODBCConnectError: sqlstate = 08001; native error = 1a; message = [Microsoft][SQL Server Native Client 10.0]Client unable to establish connection because an error was encountered during handshakes before login. Common causes include client attempting to connect to an unsupported version of SQL Server, server too busy to accept new connections or a resource limitation (memory or maximum allowed connections) on the server.

Este mensaje nos avisa de que la conexión no se puede crear debido a una limitación de recursos en el propio servidor, que le impide aceptar nuevas conexiones.

Otra pista importante nos la puede dar el errorlog, si encontramos mensajes del tipo:

spid6s SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [R:\Logs\DBlog.LDF] in database [DB] (5).  The OS file handle is 0x0000000000000A64.  The offset of the latest long I/O is: 0x0000002eb3a600

Este mensaje puede no aparecer aunque tengamos un tiempo de respuesta lento en los discos; la razón es que este mensaje sólo aparece cuando la operación de I/O dura más de 15 segundos. Es decir, si una operación dura catorce segundos y medio, no tendremos este mensaje, pero no podemos decir que estemos ante unos discos rápidos. Si no vemos este mensaje, tendremos que revisar los contadores de rendimiento, en particular Avg. Disk Sec/Read y Avg. Disk Sec/Write

Ahora bien: ¿Qué le impide al servidor SQL crear una nueva conexión? Es lógico pensar que las consultas irán lentas en un servidor con lentitud de discos, pero no es inmediato entender por qué no se puede crear una nueva conexión.

Tenemos más datos en el mensaje del errorlog:

-El spid que está sufriendo la lentitud de los discos tiene un número menor de 50; por lo tanto es un proceso de sistema

-El archivo en el que está realizando la operación es de tipo log de transacciones

En este caso, lo más probable es que este proceso de sistema sea el checkpoint o el log writer (los procesos que utilizan el log de transacciones). Si en dicho momento hubiésemos estado delante del servidor, podríamos comprobarlo por ejemplo usando sys.sysprocesses.

La lentitud en cualquiera de estos dos procesos de sistema provocará que el resto de transacciones en esta base de datos tenga que esperar, no dejando threads libres en el servidor. Por lo tanto, a la hora de crear una nueva conexión, no habrá recursos para la misma. Como resultado, fallará la comprobación de isAlive del clúster y reiniciará el servicio.

Raquel Vicente de la Rosa

Ingeniero de Soporte de SQL Server