En el curso de la supervisión del rendimiento o la resolución de problemas como la lentitud del sistema, puede ser necesario encontrar o capturar consultas que tengan una duración prolongada, una CPU alta o que generen E/S significativas durante la ejecución. Puede usar los DMV o el Almacén de consultas para obtener información sobre el rendimiento de las consultas, pero la información en ambas fuentes es un agregado. Los DMV representan el promedio de CPU, E/S, duración, etc. para una consulta solo durante el tiempo que ha estado en caché. Query Store también proporciona métricas promedio para numerosos recursos, pero se agregan durante un período de tiempo definido (por ejemplo, 30 minutos o una hora). Por supuesto, existen soluciones de monitoreo de terceros que son más que capaces de brindarle todo esto y más (como SentryOne), pero para esta publicación quería centrarme en las herramientas nativas.
Si desea comprender el rendimiento de las consultas para ejecuciones individuales para identificar la consulta exacta o el conjunto de consultas que podrían ser un problema, la opción más fácil es usar eventos extendidos. Y una de las formas más rápidas de comenzar es usar XEvent Profiler, que está disponible a través de SQL Server Management Studio (a partir de la versión 17.3):
XEvent Profiler en SSMS
Uso básico
Hay dos opciones para XEvent Profiler:Estándar y TSQL. Para usar cualquiera de los dos, simplemente haga doble clic en el nombre. Detrás de escena, se crea y se inicia una sesión de eventos definida internamente (si aún no existe), y el Visor de datos en vivo se abre inmediatamente con el foco. Tenga en cuenta que después de iniciar la sesión, también aparecerá en Gestión | Eventos extendidos | Sesiones. Suponiendo que tiene actividad contra el servidor, debería comenzar a mostrar entradas en el visor en cinco segundos o menos.
Visor de datos en vivo (después de hacer doble clic para iniciar la sesión estándar)
Las sesiones estándar y TSQL comparten algunos eventos, y la estándar tiene más en total. Aquí hay una lista de los eventos para cada uno:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Si busca comprender la información sobre la ejecución de consultas, como cuánto tiempo tardó en ejecutarse la consulta o cuántas E/S consumió, entonces Estándar es una mejor opción debido a los dos eventos completados. Para ambas sesiones, el único filtro es excluir las consultas del sistema para los eventos por lotes, rpc y atención.
Ver y guardar datos
Si iniciamos la sesión estándar y ejecutamos algunas consultas, en el visor vemos el evento, el texto de la consulta y otra información útil como cpu_time, logical_reads y duración. Uno de los beneficios de usar rpc_completed y sql_batch_completed es que aparece el parámetro de entrada. En un caso donde hay un procedimiento almacenado que tiene grandes variaciones en el rendimiento, capturar el parámetro de entrada puede ser extremadamente útil ya que podemos hacer coincidir una ejecución que lleva más tiempo con un valor específico pasado al procedimiento almacenado. Para encontrar dicho parámetro, debemos ordenar los datos según la duración, lo que no podemos hacer cuando la fuente de datos está activa. Para realizar cualquier tipo de análisis, se debe detener la alimentación de datos.
Detención de la fuente de datos en Live Viewer
Ahora que mis consultas ya no aparecen borrosas, puedo hacer clic en la columna de duración para ordenar mis eventos. La primera vez que haga clic, se ordenará en orden ascendente, y como soy perezoso y no quiero desplazarme por la parte inferior, haré clic nuevamente para ordenar en orden descendente.
Eventos ordenados en duración descendente
Ahora puedo ver todos los eventos que he capturado en orden de mayor a menor duración. Si estuviera buscando un procedimiento almacenado específico que fuera lento, podría desplazarme hacia abajo hasta encontrarlo (lo que podría ser doloroso), o podría agrupar o filtrar los datos. La agrupación es más fácil aquí, porque conozco el nombre del procedimiento almacenado.
El object_name se muestra en la parte superior del visor, pero al hacer clic en cualquier evento rpc_completed se muestran todos los elementos capturados en el panel Detalles. Haga clic con el botón derecho en object_name, que lo resaltará, y seleccione Mostrar columna en la tabla.
Agregar object_name al visor de datos
En el panel superior, ahora puedo hacer clic con el botón derecho en object_name y seleccionar Agrupar por esta columna. Si amplío los eventos en usp_GetPersonInfo y luego los clasifico nuevamente por duración, ahora veo que la ejecución con PersonID=3133 tuvo la mayor duración.
Eventos agrupados por object_name, usp_GetPersonInfo ordenados por duración descendente
Para filtrar los datos:utilice el botón Filtros…, la opción de menú (Eventos extendidos | Filtros…), o CTRL + R para abrir una ventana para reducir el conjunto de resultados en función de los diferentes campos que se muestran. En este caso, filtramos por object_name =usp_GetPersonInfo, pero también podría filtrar por campos como server_principal_name o client_app_name, ya que se recopilaron.
Vale la pena señalar que ni la sesión estándar ni la TSQL escriben en un archivo. De hecho, no hay un objetivo para ninguna de las sesiones de eventos (si no sabía que puede crear una sesión de eventos sin un objetivo, ahora lo sabe). Si desea guardar estos datos para un análisis posterior, debe realizar una de las siguientes acciones:
- Detenga la alimentación de datos y guarde la salida en un archivo a través del menú Eventos extendidos (Exportar a | Archivo XEL...)
- Detenga la fuente de datos y guarde la salida en una tabla en una base de datos a través del menú Eventos extendidos (Exportar a | Tabla...)
- Modifique la sesión del evento y agregue event_file como objetivo.
La opción 1 es mi recomendación, ya que crea un archivo en el disco que puede compartir con otros y revisar más tarde en Management Studio para un análisis más detallado. Dentro de Management Studio, tiene la capacidad de filtrar datos que no son relevantes, ordenarlos por una o más columnas, agrupar los datos y realizar cálculos (por ejemplo, promedios). Puede hacer esto si los datos son una tabla, pero debe escribir el TSQL; analizar los datos en la interfaz de usuario es más fácil y rápido.
Alteración de las sesiones de XEvent Profiler
Puede modificar las sesiones de eventos estándar y TSQL y los cambios que realice se mantendrán durante los reinicios de la instancia. Sin embargo, si las sesiones de eventos se eliminan (después de haber realizado modificaciones), se restablecerán a los valores predeterminados. Si se encuentra continuamente haciendo los mismos cambios, le sugiero que escriba los cambios y cree una nueva sesión de eventos que también persistirá en los reinicios. Como ejemplo, si observamos la salida capturada hasta ahora, podemos ver que tanto las consultas adhoc como los procedimientos almacenados se han ejecutado. Y aunque es genial poder ver los diferentes parámetros de entrada para los procedimientos almacenados, no veo las declaraciones individuales que se ejecutan con este conjunto de eventos. Para obtener esa información, necesitaría agregar el evento sp_statement_completed.
Comprenda que las sesiones de eventos estándar y TSQL están diseñadas para ser livianas. Los eventos statement_completed se activarán con más frecuencia que los eventos por lotes y rpc, por lo que puede haber más sobrecarga cuando estos eventos son parte de una sesión de eventos. Al usar eventos de declaración, muy recomendamos incluir predicados adicionales. Como recordatorio, los eventos rpc y por lotes solo filtran las consultas del sistema, no hay otro predicado. En general, también recomiendo predicados adicionales para estos eventos, especialmente para una carga de trabajo de gran volumen.
Si le preocupa si la ejecución de sesiones estándar o TSQL causará un impacto en el rendimiento de su sistema, comprenda que Live Data Viewer se desconectará si genera demasiada sobrecarga en el sistema. Esta es una gran seguridad, pero aún sería considerado al usar estas sesiones de eventos. Creo que son un primer paso fantástico para la resolución de problemas, especialmente para aquellos que son nuevos en SQL Server o Extended Events. Sin embargo, si tiene abierto el Visor de datos en vivo y se aleja de su máquina, la sesión del evento continúa ejecutándose . Detener o cerrar Live Data Viewer detendrá la sesión del evento, que es lo que recomiendo cuando haya terminado con la recopilación de datos o la resolución de problemas.
Para las sesiones de eventos que desea ejecutar durante un período de tiempo más prolongado, cree sesiones de eventos independientes que escriban en el destino event_file y tengan los predicados apropiados. Si necesita más información sobre cómo comenzar con Extended Events, consulte la sesión que di en SQLBits el año pasado sobre la migración de Profiler a Extended Events.
