Como DBA, abordar los problemas de rendimiento suele ser un evento reactivo; ocurre un problema, usted tiene que responder. A veces está mirando una instancia de SQL Server que conoce bien, otras veces puede ser su primer encuentro con un entorno. Esto ocurre también en el mundo de la consultoría. Cuando ayudo a un cliente a largo plazo, ya tengo archivados los detalles sobre el medio ambiente. Sin embargo, cuando recibimos un correo electrónico de alguien con quien no hemos trabajado antes, y es una situación de emergencia en la que quiere ayuda inmediata, no tenemos antecedentes sobre el medio ambiente y no tenemos idea de en qué nos estamos metiendo. Brindamos asistencia sin pasar por el extenso proceso de recopilación y análisis de datos que comienza cada nuevo compromiso con el cliente.
Por esta razón, tengo un conjunto de cinco elementos que compruebo inmediatamente cuando me enfrento a un nuevo entorno. La información que recopilo sienta las bases para la forma en que enfoco la solución de problemas en el futuro y, aunque rara vez identifica EL problema específico, me ayuda a descartar lo que NO es el problema, que a veces es igual de importante.
Métodos de recopilación de datos
Reconozco que todos tienen un enfoque diferente al abordar un nuevo entorno. Hay varias secuencias de comandos gratuitas y ampliamente disponibles que puede descargar y ejecutar para darle la "disposición del terreno" para una instancia de SQL Server (me vienen a la mente las secuencias de comandos DMV de Glenn Berry). El enfoque aquí no es cómo recopilas los datos, es qué datos que recopila y qué analiza primero .
Propiedades del servidor
Lo primero que quiero saber cuando miro una instancia es la versión y edición de SQL Server. La forma más rápida de obtener esta información es ejecutar:
SELECT @@VERSION;
Con este resultado, puedo verificar la compilación para determinar los paquetes de servicio, las actualizaciones acumulativas y las revisiones aplicadas, y sé qué edición se usa. También me gusta saber si la instancia está agrupada, por lo que también ejecuto:
SELECT SERVERPROPERTY('IsClustered'); A veces tengo esta información del cliente, pero nunca está de más verificarla, ya que la versión y la edición pueden afectar los pasos y recomendaciones posteriores para la solución de problemas. Por ejemplo, un cliente se comunicó recientemente con nosotros sobre un problema de rendimiento intermitente que vio con SQL Server 2008. Una revisión rápida de la versión reveló que estaban ejecutando SQL Server 2008 SP3 y que se lanzaron varias actualizaciones acumulativas después del SP3 que abordaban una variedad de problemas de desempeño. Si bien reuní más información antes de recomendar que aplicaran la CU más reciente, esta fue una señal de alerta inmediata sobre lo que podría estar causando el problema.
configuraciones del sistema
Esta vista de catálogo ayuda a construir sobre la base que comenzó con las propiedades del servidor y nos ayuda a comprender cómo se configura la instancia. Con esta vista, busco las configuraciones que se han cambiado de los valores predeterminados, pero que no deberían haberlo hecho, y las que no ha sido modificado, pero debería.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Considere la configuración de memoria máxima del servidor (MB), que limita la cantidad de memoria disponible para el grupo de búfer. El valor predeterminado es 2147483647, pero debe cambiarse a un valor menor que la memoria total en el servidor para garantizar que haya suficiente memoria para el sistema operativo, otras aplicaciones y otras tareas de SQL Server que requieren memoria que no se tome del grupo de búfer. . Para obtener orientación sobre cómo configurar el valor apropiado para la memoria máxima del servidor (MB), recomiendo la publicación de Jonathan, ¿Cuánta memoria necesita realmente mi SQL Server?
Por el contrario, la configuración de aumento de prioridad tiene un valor predeterminado de cero y siempre debe dejarse como tal. De hecho, Microsoft recomienda no cambiarlo y la opción se eliminará en una versión futura de SQL Server.
sys.bases de datos
Después de entender cómo está configurada la instancia, luego miro para ver qué existe en el nivel de la base de datos.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Cuando reviso el resultado de esta vista de catálogo, busco antipatrones, cualquier cosa que salte como inesperada o atípica, en los datos. El resultado es propicio para un análisis rápido:muchas de las configuraciones enumeran un 0 o 1 para el valor (desactivado o activado) y tomo nota mental de lo que es diferente. Espero que las estadísticas de creación automática y las estadísticas de actualización automática estén habilitadas (establecidas en 1). Espero que el cierre automático y la reducción automática estén deshabilitados (establecidos en 0). Miro para ver cuál es la intercalación para las bases de datos de usuario, específicamente si todas tienen la misma intercalación y si esa intercalación es la misma que tempdb. También observo opciones de seguridad como el encadenamiento entre bases de datos y la opción is_trustworthy, ambas deshabilitadas (0) de forma predeterminada. Si encuentro que alguna de estas configuraciones se desvía de lo que esperaba, lo anoto y sigo adelante. En ningún momento detengo mi recopilación o análisis para hacer un cambio, ya que simplemente estoy recopilando información lo más rápido posible para obtener una buena comprensión del entorno.
Además de comprobar la configuración de las bases de datos, también tomo nota del número de bases de datos de los usuarios. No hay un "número correcto" de bases de datos de usuario para una instancia:una instancia puede funcionar mal con una base de datos y puede funcionar maravillosamente con 100. Hay una gran cantidad de factores en juego, y la cantidad de bases de datos es simplemente un punto de datos. digno de mención.
Registros de errores
Lo admito, solía descuidar el ERRORLOG de SQL Server; fue como una ocurrencia tardía cuando investigué un problema de SQL Server. Entonces me di cuenta del error de mis caminos, y no lo he dado por sentado desde entonces. Tiendo a navegar a través de Management Studio para acceder al registro (dentro de Management | SQL Server Logs), aunque puede usar el procedimiento almacenado sp_readerrorlog o buscar el archivo y abrirlo con su editor de texto favorito.
En el REGISTRO DE ERRORES, busco errores recientes, por ejemplo, cualquier cosa relacionada con la memoria, y también busco qué marcas de seguimiento, si las hay, están en uso. También verifico si Bloquear páginas en la memoria está habilitado, si el caché se está vaciando (ya sea a propósito o no) y si ocurre alguna otra actividad inusual con regularidad. Dependiendo de cuán urgente sea el problema, también miro los registros de Windows (Evento, Aplicación y Seguridad), de nuevo no solo busco errores, sino también patrones de mensajes inesperados.
Estadísticas de espera
El área final de SQL Server que reviso cuando observo un problema de rendimiento en una instancia desconocida son las estadísticas de espera. Cada instancia de SQL Server tendrá esperas, sin importar qué tan bien ajustado esté el código, sin importar cuánto hardware haya detrás. Como DBA, desea saber cuáles son sus esperas típicas para una instancia, y cuando estoy buscando un entorno nuevo, no sé de inmediato si las esperas que veo son típicas o se deben al problema de rendimiento. Le pregunto al cliente si tiene estadísticas de espera de referencia, y si no, le pregunto si puedo borrarlas y dejar que comiencen a acumularse mientras ocurre el problema de rendimiento. Para verificar las estadísticas de espera, puede usar el script en la publicación a la que se hace referencia con frecuencia de Paul Randal, o la versión en las consultas del DMV de Glenn.
Una vez que revise las estadísticas de espera acumuladas, tendrá la pieza final que proporciona el "panorama general" de la instancia de SQL Server y la información que necesita para comenzar a solucionar problemas. No es poco común verificar primero las estadísticas de espera al solucionar problemas, pero las esperas por sí solas no son información suficiente para determinar qué debe investigar a continuación, a menos que también comprenda la configuración básica de SQL Server.
Siguientes pasos
Como mencioné anteriormente, normalmente no hay un solo dato que le diga dónde se encuentra el problema de rendimiento, son varios puntos de datos obtenidos los que lo señalan en la dirección correcta. La forma en que captura esa información depende de usted, pero una vez que revise el resultado, debe tener una buena comprensión de cómo está configurado el entorno de SQL Server, y ese conocimiento, combinado con las estadísticas de espera, puede ayudarlo a decidir qué investigar a continuación. La solución de problemas funciona mejor con un enfoque metódico, así que comience con lo básico y avance, y cuando crea que ha determinado la causa raíz, indague un poco más y encuentre una o dos pruebas adicionales que respalden su hallazgo. Una vez que tenga esos datos, puede hacer una recomendación para ayudar a mejorar o resolver el problema.
