SQL Server va lento, tengo problemas de rendimiento ¿Y ahora qué?

He escuchado esta pregunta en muchas ocasiones, ya sea en foros o directamente en clientes, donde quienes se encargan de administrar SQL Server son DBA “por accidente” o porque han migrado desde otro gestor de base de datos y ahora tienen que lidiar con algo totalmente nuevo. El factor común es que son personas con poca o nula experiencia con SQL Server y se encuentran con una situación en la que no saben qué hacer cuando el usuario se queja de que el servidor no responde.

Si ya han usado SQL Server Management Studio (SSMS) seguramente conozcan el informe de actividad (“Activity Monitor”) al que se accede desde el menú contextual sobre la propia instancia. Este informe nos permite ver varias cosas, como puede ser el uso del procesador o del disco, el número de peticiones por segundo, las conexiones activas, etc. Sin embargo no nos dice qué le está “doliendo” a nuestra instancia en ese momento, y eso en el caso de que consigamos visualizarlo, ya que cuando el servicio no responde, muy probablemente tampoco lo vaya a hacer este informe.

Si llevamos un poco más de tiempo seguramente hayamos oído hablar de los procedimientos sp_who, sp_who2, pero ninguno de ellos nos va a aportar mucha más información que la de ver las conexiones que tiene abiertas nuestra instancia. Incluso podríamos hacer uso de sp_lock, pero sólo nos serviría si la causa del problema fueran los bloqueos.

Sin embargo, desde la versión 2005 tenemos a nuestra disposición las vistas y funciones de administración dinámicas, las DMV. Son una fuente casi inagotable de información sobre nuestro SQL Server de las que podemos sacar mucho provecho si hemos dedicado un tiempo a estudiar qué nos ofrecen cada una de ellas.

Y cómo no, una de estas DMV nos va a permitir conocer rápidamente por qué las peticiones que le llegan al servidor no están respondiendo en un tiempo razonable: sys.dm_os_waiting_tasks. Tal como dice la propia ayuda, esta DMV “devuelve información sobre la cola de tareas que están esperando en algún recurso”. La información a la que se refiere es el tiempo que lleva esperando (wait_duration_ms), el recurso por el que está esperando (resource_description) y si es por un bloqueo, la sesión que le está bloqueando (blocking_session_id). También nos informa de lo más importante: el recurso por el que está esperando (wait_type).

Hay multitud de tipos de espera (wait_type), de razones por las cuales una petición puede tener que esperar por alguna causa: el disco, la memoria, la CPU, bloqueos, etc. (en http://msdn.microsoft.com/es-es/library/ms179984.aspx tenemos la lista completa de estas razones). Pues bien, una vez que tenemos localizadas la razón (o razones) por las cuales las peticiones no son ejecutadas en un tiempo prudencial, es cuestión de investigar más a fondo qué significan esos conceptos (que al principio puedan resultar extraños) y, sobre todo, tratar de poner soluciones.

Y si pensáis que estaría bien poder obtener más datos sobre las peticiones que están esperando, no tenemos más que empezar a investigar qué otras DMV existen (http://msdn.microsoft.com/es-es/library/ms188754.aspx) y que nos puedan interesar para obtener dicha información: qué instrucción es lo que estaba ejecutando en ese momento, en qué base de datos, qué login, desde cuándo, número de lecturas, etc.

Eso, o “aprovecharnos” del trabajo de personas de la comunidad que de forma desinteresada nos cede su tiempo y esfuerzo. Una de estas personas es Adam Machanic (blog | twitter), reconocido experto en SQL Server, que nos regala mediante su procedimiento sp_whoIsActive una forma fácil y rápida de obtener toda la información (y más) que podamos necesitar acerca de qué es lo que le puede estar pasando a nuestra instancia en un momento dado.

Por cierto, si tenéis más inquietudes, os recomiendo que analicéis el código de este procedimiento: es un magnífico ejemplo de cómo deberían estar escrito todo el lenguaje TSQL que encapsulemos en algún objeto de una base de datos (procedimientos, funciones, vistas)

Referencias:

· SQL Server 2005 Performance Tuning using the Waits and Queue. Aunque el título hable de la SQL 2005, es perfectamente válido para cualquier versión posterior, incluso hasta para SQL Server 2000. Nos enseña una metodología de análisis de rendimiento basada en los tipos de espera. Imprescindible

· Wait statistics, or please tell me where it hurts. Artículo de Paul Randall (blog | twitter), antiguo miembro del equipo de desarrollo de SQL Server, en donde explica más detalladamente alguna de los tipos de espera más comunes, así como las soluciones a aplicar

Este post es una colaboración de Carlos Sacristán.

Gracias Carlos, esperamos seguir disfrutando de tus aportaciones a este blog :)