Excelente herramienta para monitorear SQL Server

Varias personas me preguntan con que se puede monitorear el performance de SQL Server. Una herramienta bastante ligera, muy sencilla de usar, instalar y que es bastante gráfica y no consume muchos recursos es ApexSQL Monitor.

Este artículo muestra los principales problemas de una base de datos lenta y como verificar los causales usando una herramienta de monitoreo.

Usted se puede bajar el producto del siguiente sitio web:

http://www.apexsql.com/sql_tools_monitor.aspx

El instalador no ocupa más de 9 MB. Es muy fácil de instalar. La versión de prueba gratuita no tiene limitaciones de funcionamiento pero si de tiempo de uso.

Al comprar la licencia si no le gusta, se le devuelve el dinero antes de los 30 días de uso.

Para instalar ejecute el instalador ejecutable.

Elija instalar todos los componentes.

Le pedirán conectarse con el servidor y colocar cuentas del administrador. Para el uso interno, se creará una cuenta de sysadmin.

 Una vez instalado el programa, inicie el programa ApexSQL.
Posteriormente se deben agregar el servidor o los servidores de SQL Server.

 Y colocar la información del servidor y la información para iniciar sesión.

 El sistema muestra la información general del sistema, el sistema operativo, las alertas, memoria.
También muestra la versión de SQL Server que nos indica los parches (llamados en inglés Service Packs) instalados. Otro tema importante es mostrar el estado donde se ve si está en línea (ONLINE) o si el servicio está abajo (OFFLINE).

La aplicación en la sección de Overview muestra la cantidad de Memoria máximo y mínimo del servidor al igual que las alertas según la gravedad del problema (alerta roja, anaranjada y amarilla).

Los procesadores y el número de usuarios cuya sesión a expirado son uno de los varios datos mostrados por este software.

 Existen 5 secciones mostrados por la aplicación.

1. El Overview que es un visor de datos generales tanto del sistema operativo como la base de datos. 
2. El system performance muestra el performance del sistema operativo. Que es muy importante para ver si el causante de la base de datos lenta es el sistema operativo en sí.
3. SQL Server performance que mide el performance de la base de datos en cuanto a datos de contadores.
4. Database performance muestra el performance de bases de datos específicas.
5. Finalmente query performance muestra estadísticas de las consultas más pesadas.

La siguiente gráfica muestra el estado de las bases de datos y su tamaño al igual que estadísticas en memoria Caché, scans por minuto, escrituras lazzy. Las bases de datos pueden estar en línea (ONLINE) o desconectadas (OFFLINE). Las gráficas de memoria caché nos muestran si tenemos suficiente memoria caché. De tener insuficiente memoria caché, la paginación aumenta y comenzamos a tener malas estadísticas de paginación que ya mostrarían lentitud en el sistema.

 La siguiente imagen muestra gráficas de performance del procesador. En Servidores de base de datos donde múltiples usuarios tienen varias consultas que consumen varios recursos de bases de datos, es recomendable incrementar el número de procesadores. El % de uso de procesador en general tiene que estar por debajo del 80%. Si no es así considere en aumentar los procesadores y cores. Lo mismo con el dato de Queue lenght, este dato debe ser menor que 2 por procesaror. Si es mayor, el problema de lentitud es el procesador mismo.

 Esta gráfica muestra estadísticas de red. En general la red no suele ser el problema. Sobre todo en redes locales dentro de una oficina. Sin embargo si ve los datos en 0, significa que se cayó la red.

 Las entradas de paginación por segundo también son monitoreadas. Si ve rangos altos de Page inputs, significa que la memoria es insuficiente y que el disco duro esta trabajando (trabajando duro) y por eso está el sistema más lento.

 Otro factor importante es medir que la base de datos no crezca mucho. Total size muestra el tamaño total. Lo que generalmente se dispara en tamaño de la base de datos es el Log de la base de datos. Si se actualizan o insertan muchos datos, el log que normalmente está su modelo de recuperación en Completo (o Full en inglés) suele llenar el log haciendo crecer mucho la base de datos. Es recomendable que si va a cargar muchos datos que cambie el modelo de recuperación a bulk Logged (Por medio de registros de operaciones masivas). Para mayor información sobre este tema visite el haga clic acá.

La última imagen muestra estadísticas de consultas. Muchas veces el problema es la consulta en sí. Esta consulta puede ser optimizada ya sea utilizando algún tipo de índice, actualización de estadísticas o cambiando la lógica de la consulta reformulándola de una manera más eficiente. Con ApexSQL podemos ver de manera gráfica que consultas consumen más tiempo, el tiempo del CPU de estas consultas en ms, la base de datos en las cuales se ejecutan las consultas, las lecturas, escrituras lógicas y físicas hechas por las consultas.

Este sistema también muestra deadlocks, conexiones de usuarios, memoria utilizada, Buffer cache hits, lecturas y escrituras de paginación, splits de páginas, tamaño de bases de datos, de logs, crecimiento de logs y mucho más.

Deadlocks son bloqueos muy comunes cuando se realizan varias consultas entre tablas dependientes unas de otras.

Las conexiones de usuarios nos dan una idea de que si la cantidad de gente es mucha para la base de datos y si es mucha hay que pensar en un servidor más potente o un balanceo de carga en diferentes servidores de ser necesario. Finalmente otro problema común es que el disco duro no es lo suficientemente potente por lo que hay que pensar en mejores discos duros para mejorar el performance.

Conclusión

Si usted quiere una herramienta sencilla, no muy cara, gráfica, ligera y fácil de aprender, le recomiendo ApexSQL Monitor. Usted ha visto como se puede monitorear la base de datos a Nivel de Sistema operativo, Servidor de base de datos, Base de datos y finalmente un monitoreo a nivel de consulta.