Confio Ignite PI 8 E studio De Un Caso

Hace aproximadamente un mes he comenzado a probar Ignite PI versión 8 de CONFIO, 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.

Description: A1.JPG

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:

Description: A01.JPG

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:

Description: Uno.JPG

(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:

Description: A2.JPG

Description: A3.JPG

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:

Description: A4.JPG

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:

Description: A5.JPG

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:

Description: A6.JPG

Continues…

Pages: 1 2




Related Articles :

  • No Related Articles Found

No comments yet... Be the first to leave a reply!

Software Reviews | Book Reviews | FAQs | Tips | Articles | Performance Tuning | Audit | BI | Clustering | Developer | Reporting | DBA | ASP.NET Ado | Views tips | | Developer FAQs | Replication Tips | OS Tips | Misc Tips | Index Tuning Tips | Hints Tips | High Availability Tips | Hardware Tips | ETL Tips | Components Tips | Configuration Tips | App Dev Tips | OLAP Tips | Admin Tips | Software Reviews | Error | Clustering FAQs | Performance Tuning FAQs | DBA FAQs |