
En un artículo anterior sobre la herramienta de monitoreo Foglight for Databases, hablamos sobre
las capacidades de monitoreo desde una única interfaz: SQL Server, Oracle, PostgreSQL, MySQL, SAP ASE, DB2, Cassandra y MongoDB. Hoy analizaremos los enfoques para identificar rápidamente las causas del funcionamiento anormal de Microsoft SQL Server:
- Busque una fuente de bloqueo;
- Comparación de la configuración de la base de datos "was-it-Become" con referencia a las métricas de rendimiento;
- Busque cambios en la estructura de la base de datos, debido a que el rendimiento ha disminuido.
Detalles debajo del corte.
Foglight for Databases es una herramienta para monitorear el rendimiento y los cambios en las bases de datos populares. Si no está familiarizado con este producto, le recomendamos que lea el
artículo anterior . Y a continuación presentamos capturas de pantalla de la interfaz para demostrar las capacidades de Foglight y la facilidad de encontrar problemas en la base de datos.
Buscar fuente de bloqueo
Puede buscar el motivo de los bloqueos en Management Studio. Pero una estación de trabajo con esta utilidad puede no estar disponible, y abrir la consola no siempre es conveniente. En Quest Foglight, puede encontrar la razón del bloqueo en unos pocos clics. En la captura de pantalla a continuación, verá la consola de monitoreo de la base de datos principal.

Un administrador de servicio que ya recibió una notificación ingresa a la vista SQL PI (Performance Investigator). La columna Workload tiene un campo rojo notable, que indica un valor distinto de cero del parámetro Lock Wait.

Después de hacer clic en el gráfico de Carga de trabajo, se abre una vista detallada de las fuentes de carga de la base de datos, y en la columna izquierda del menú para el análisis de rendimiento multivariante. Aquí, como en la captura de pantalla anterior, se puede ver que el bloqueo provoca una gran utilización de los recursos. En el menú de la izquierda hay una vista especial de Objetos bloqueados, en la que se detecta un objeto bloqueado.

Objetos bloqueados almacena objetos bloqueados. En el lado derecho de la pantalla, los motivos del bloqueo: la duración, desde qué servidor (o estación de trabajo), qué programa, desde qué usuario y objeto ejecutable que condujo al bloqueo.

Cuando cambia a un objeto ejecutable, se abre una nueva vista con la capacidad de ver el contenido de este objeto. Y después de hacer clic en Ver texto por lotes, se abrirá el código ejecutado.

Acelerar el tiempo de diagnóstico es la clave del éxito del equipo de TI.
Comparación de la configuración de DB
Los cambios realizados por desarrolladores o DBA también pueden conducir a una desaceleración dramática. Pero en el momento del problema, no importa quién lo hizo, es importante lo que sucedió. Intentaremos resolver esto. Abra el menú contextual de la instancia de la base de datos del problema.

En el menú que se abre, vaya a SQL PI (Performance Investigator) para abrir la vista con análisis multivariado.

Pasemos a la vista de línea de base para evaluar el comportamiento de una métrica en comparación con sus valores habituales.

El gráfico muestra que después de las 13:40 comenzó un aumento anormal en el consumo de recursos.

En esta vista, configuraremos con qué comparar. Ahora considere la comparación de la métrica consigo misma (a lo largo de la línea de base), porque Desviación anormal revelada arriba. En general, también puede comparar el rendimiento con otra instancia de base de datos.

Después de seleccionar objetos para la comparación, aparecerá el preciado botón Comparar.

La vista promedio muestra que las métricas observaron valores anómalos: tiempo activo, ejecuciones y tasa de inicio de sesión. Comencemos una nueva comparación para identificar los cambios.

Compare los valores de las métricas con nosotros mismos, pero hace un día.

Después de seleccionar la configuración, aparecerá el botón Comparar, en el que debe hacer clic.

Aparece una vista en la que hay medidas para comparar. Para una demostración, seleccionaremos el elemento del menú Programas. La sección Estadísticas ya muestra un aumento doble en el valor de la métrica Ejecuciones.

A la izquierda y derecha de la escala, en la sección del menú Programas, se muestran los valores métricos. Aquí vemos que el tiempo activo y las ejecuciones casi se duplicaron, y esta es una ocasión para un análisis detallado de la situación.

Del mismo modo, puede realizar un análisis comparativo de otras métricas y cargar cualquier presentación en un informe PDF.
Buscar cambios en la estructura de la base de datos.
Los cambios en los índices, los planes de ejecución y otros objetos pueden estar indocumentados. El desarrollador o administrador de la base de datos realiza cambios aparentemente menores, de los que puede olvidarse después de un tiempo. En la interfaz de Foglight for Databases, los cambios de configuración están vinculados a los cambios de rendimiento. Para identificar los cambios, vaya desde la pantalla principal de monitoreo de la base de datos a la vista Carga de trabajo.

Supongamos que sabemos que se genera una gran carga en la base de datos desde alguna máquina cliente. Revelamos máquinas cliente en la vista izquierda.

Los lotes se ordenan según la carga en la base de datos. Vayamos al primer objeto de la lista y luego veamos los cambios en él (Change Tracking).

En el gráfico, según la leyenda de la derecha, se marcan los cambios correspondientes para el período seleccionado. El primer cambio aquí es la eliminación del índice, el segundo es la adición de un nuevo plan de ejecución. Como puede ver, una vez que se ha eliminado el índice, la carga de Otra espera ha aumentado considerablemente: la zona púrpura (la ejecución del trabajo por lotes también se refiere a ella). El cuarto cambio es un aumento en el nivel de paralelismo, que potencialmente condujo a un aumento en el número de solicitudes (IO Wait - zona azul). Considere las implicaciones de agregar un nuevo plan de ejecución.

Después de la transición, se han abierto los detalles del nuevo plan de ejecución. Ahora compare los cambios que han ocurrido.

Después de la transición, se han abierto los detalles del nuevo plan de ejecución.

El mismo plan de ejecución se puede abrir en Management Studio directamente desde la interfaz de Quest Foglight.

Así se ve en la consola de Management Studio.

Cuando cambia a la vista Historial, puede ver cambios en las métricas a lo largo del tiempo.

La vista Historial se puede usar para evaluar el impacto de los cambios en una métrica en particular. A continuación, vaya a la otra vista.

En esta vista, puede ver qué lotes afectaron la carga de la base de datos. Ya están ordenados en orden descendente.

Además de realizar un seguimiento automático de los cambios, un usuario de Foglight puede agregar cambios manualmente. En caso de degradación del rendimiento, el administrador de turno ya no buscará la causa de la degradación del servicio.
Si le gustó Foglight para bases de datos y desea probarlo en sus bases de datos, deje una solicitud de distribución y clave de prueba
en el formulario de comentarios de nuestro sitio web. ¡Funcionamiento estable de la base de datos y localización rápida de trabajos anormales!