Ya ha pasado mucho tiempo desde la última entrada que escribí en este blog, lamentablemente hasta me había olvidado de él y lo había dejado de lado para atender otros temas.
He querido retomarlo con un tema que me resultó muy interesante y que significó en una que otra discusión álgida con otro proveedor de un cliente.
Sucede que el cliente estaba experimentando una lentitud muy importante en las transacciones de índole de escritura, es decir los queries del tipo INSERT, DELETE, UPDATE, MERGE, etc.
¿Qué es lo primero que hay que hacer?, darle una revisada a lo que se está ejecutando en este momento, analizar lo que lleva más tiempo ejecutándose y el tipo de bloqueo que está reportando. Esta información la podríamos obtener con el siguiente query:
SELECT ER.session_id, DB_NAME(ES.database_id) AS database_name, DATEDIFF(SECOND, ER.start_time, GETDATE()) AS seconds_elapsed, ER.command, ES.host_name, ES.program_name, ES.host_process_id, ER.blocking_session_id, ER.wait_type
FROM sys.dm_exec_requests ER
INNER JOIN sys.dm_exec_sessions ES
ON ER.session_id = ES.session_id
WHERE ES.is_user_process = 1
AND ER.last_wait_type NOT IN ('BROKER_RECEIVE_WAITFOR', 'XE_TIMER_EVENT', 'XE_DISPATCHER_WAIT', 'XE_LIVE_TARGET_TVF', 'FT_IFTS_SCHEDULER_IDLE_WAIT')
Me encontré con que había una lista importante de queries en ejecución y cuya cantidad de segundos transcurridos ya estaba por encima de los 10 segundos. Noté que el valor de la columna wait_type en casi todos los casos era "WRITELOG".
Si verificamos la documentación de este tipo de wait, encontraremos que está relacionado con el tiempo que le está llevando el escribir en el archivo de transacciones de las bases de datos, es decir que se está tardando en escribir en el sistema de almacenamiento.
Para confirmar la sospecha generé un medidor de rendimiento en el PerfMon y agregué el contador Physical Disk - Avg. Disk sec/Write seleccionando la unidad de almacenamiento donde se encontraban los archivos de registro de transacciones de las bases de datos.
¿Qué fue lo que encontré?, que la escritura le estaba tomando, en promedio, 170 milisegundos en ejecutarse. ¡Sí!, 170 milisegundos; no perdamos de vista que el tiempo máximo de escritura y de lectura es de 15 milisegundos, es decir que estaban muy por encima del tiempo máximo aceptable.
Después de correos, revisiones, discusiones, reuniones y llamadas; el proveedor del sistema de almacenamiento encontró (y aceptó) que el sistema de almacenamiento estaba teniendo problemas y que solamente tenía que cambiar las unidades problemáticas.
Hay veces que le echarán la culpa a SQL porque es lo que ven y lo que percibe tanto el usuario final como el departamento de TI de nuestro cliente, pero es importante tener información sólida a la mano para determinar que el problema no es el motor sino algún recurso que necesita el motor para ejecutarse correctamente.
¡Saludos y que este 2024 esté lleno de salud y de trabajo!
