www.confio.com.
Luego de algunas pruebas de laboratorio, he decidido instalarlo en un cliente en producción para un análisis más exhaustivo. Este cliente genera 800 facturas en línea por día, administra clientes, proveedores, administra stock, genera guías de distribución, maneja la contabilidad, etc., con una aplicación de terceras partes.
Para todo esto, tiene 2 servidores (uno en línea, otro de backup) con dos bases de datos y, aproximadamente 120 usuarios, locales y remotos.
En el servidor de Backup, instalo Ignite PI 8, el cual genera una base repositorio y un servicio de monitoreo sobre el servidor de producción. Esto es: nada es instalado en servidor de Producción.
El servidor principal se dispone de 4gb de RAM, 4 procesadores y 4 discos espejados de a dos. Windows 2003 y SQL 2005. Las versiones son confidenciales y sus services packs están al día.
En este cliente trabajo como DBA free lance. Lo visito 1 vez por semana y estoy conectado remotamente 7 x 24.
Durante mucho tiempo (3 años) he realizado tareas de optimización, mantenimiento, integridad, backup, etc., pero no encontraba herramienta alguna, integral, que me ayudara a prevenir problemas de performance.
Dado que contábamos con un servidor de backup, desde él ejecutaba el Profiler 7 x 24 y el Monitor de Performance para analizar el servidor en producción.
Luego de la instalación de Ignite PI 8, he mejorado la performance de mi cliente en forma significativa. Esto se debe a que, Ignite, analiza entre otras cosas, la cantidad de veces que se ha ejecutado alguna consulta SQL. Analiza el tiempo de espera y sugiere mejorarla. Con las herramientas tradicionales, se buscan las sentencias SQL de mayor duración y se tratan de optimizar, pero no se buscan las que se ejecutan muchas veces, duran poco tiempo, pero si las optimizamos, la performance crece considerablemente.
Finalmente he pensado que, escribir todas las posibilidades que ofrece Ignite, me llevaría muchísimo tiempo y, de seguro, no abarcaría todas las posibilidades.
Por lo tanto, decidí mostrarles un caso real.
Todo comienza con la recepción de un mail el 18 de agosto de 2010, generado por Ignite, a raíz de un bloqueo en la instalación del cliente en cuestión.
Como era de esperar, no me encontraba en la instalación del cliente. Por el contrario, estaba en otro cliente, pero con acceso a Internet.
El mail, avisaba sobre un bloqueo en una de las bases del cliente en cuestión.
En forma inmediata me conecté remotamente al cliente, accedo al menú principal de Ignite que se muestra en la siguiente figura.
En esta pantalla se visualiza mucha información. La que, en este caso interesa, es la columna “Alarm” con valor “Critical”. El resto de la información habla sobre el nombre del servidor, versión del SQL, etc.
Basta un click en “Critical” para visualizar la siguiente información:
Como se puede ver, tenemos información desde el 25 de Julio de 2010 hasta el 24 de agosto de 2010.
Se muestran las “top” sentencias SQL. Vemos distintos tabuladores para analizar (SQL, Waits, etc.).
Dado que el problema ocurrió el 18 de agosto de 2010 y este informe lo estoy escribiendo el 25 de agosto, debemos suponer que el análisis que voy a desarrollar ocurrió el 18 de agosto.
Genéricamente los gráficos muestras las esperas “waits” de cada sentencia SQL para cada base de datos.
Dado que el mail recibido ocurre el 18 de agosto, basta con hacer un doble click en el gráfico donde dice “ago 18”.
Luego del doble click, se visualiza la siguiente pantalla:
(1*)
Aquí podemos observar que hubo algún problema a partir de las 12 pm hasta las 1 pm horas.
Si bien todavía no sabemos muy bien cuál fue el problema, sabemos que consumió muchos segundos (Y axis).
Sin embargo, en la misma pantalla, podemos analizar cuáles fueron los recursos que han consumido los hechos ocurridos a partir de las 12 PM.
El siguiente gráfico (es la misma pantalla, parte inferior), muestra lo siguiente:
No parece haber un problema crítico de recursos de hardware.
La CPU no supera el 20%, las colas de disco están en valor 1 y las transacciones no son significativas.
En conclusión, el problema no se encuentra en los recursos (hardware, software) del SQL. Está en otro lado.
Con un doble click en las “12 Pm” en el gráfico (1*) nos despliega la siguiente información:
Aquí podemos ver gráficamente, la cantidad de segundos que consumió la sentencia que bloquea. El tipo de boqueo es: LCK_M_U.
Si el DBA desconoce qué significa este tipo de bloqueo, basta con un click en “LCK_M_U” para obtener lo siguiente:
Aquí se describe (en inglés, por supuesto) el tipo d bloqueo que ocurrió. Concretamente es un loqueo por Actualización que intenta modificar una fila o página de la base de datos.
La siguiente información, a nivel de solapas, es “Base de Datos”.
Si nos movemos a ella, vemos lo siguiente:
