SQL Server siempre ha brindado la capacidad de capturar consultas en vivo ad hoc en un formato de conjunto de filas fácilmente consumible, primero con SQL Server Profiler heredado, luego a través de eventos extendidos en SSMS. Esta capacidad es valiosa cuando se ajusta el rendimiento, ya que los eventos de consulta incluyen métricas discretas de CPU y E/S, así como parámetros de tiempo de ejecución, que son clave para solucionar problemas de rendimiento de consultas, como la detección de parámetros. Además, los eventos de consulta contienen otros elementos importantes, como el nombre de host del cliente, el nombre de la aplicación, el inicio de sesión, el ID del proceso de Windows, etc.
Siempre puede recuperar agregados métricas de rendimiento para normalizado consultas de DMV o Query Store, pero solo contienen compilado parámetros y ninguno de los elementos antes mencionados. Aunque esto es útil, no es lo mismo. Por ejemplo, si necesita ver la combinación de parámetros específica utilizada por esa consulta que hizo 2 mil millones de lecturas o encontrar la aplicación que más CPU ha consumido durante las últimas 24 horas, no tiene suerte.
Azure SQL Database no es compatible con Profiler heredado y Microsoft deshabilitó el proveedor de transmisión de XEvents (sys.fn_MSxe_read_event_stream TVF) por razones de confiabilidad, por lo que no puede activar una sesión XE y "ver datos en vivo" con SSMS. Query Performance Insights en Azure Portal está respaldado por Query Store, por lo que solo tiene las consultas normalizadas y los datos de rendimiento agregados, no los eventos de consulta reales.
Entonces, durante algunos años estuvimos atascados:la única opción para crear perfiles de Azure SQL Database era crear manualmente un seguimiento de XEvents que escribe en un búfer de anillo o un destino de archivo con Azure Storage, ninguno de los cuales es óptimo. El uso del búfer de anillo con consultas T-SQL puede ser problemático debido al límite de XML formateado de 4 MB, como lo explica Jonathan Kehayias aquí, y los destinos de archivos requieren una cantidad considerable de saltos de aro y gastos adicionales. Ambos requieren una consulta manual de los datos XE y, por lo tanto, no están exactamente "en vivo" en el sentido tradicional.
Introduce la Nueva Analizador de SQL Server
Cuando me enteré de la extensión SQL Server Profiler para Azure Data Studio, me complació ver que Microsoft finalmente ofrecía una solución gráfica para la captura de consultas en vivo en Azure SQL Database. Desafortunadamente, mi entusiasmo duró poco por un par de razones.
En primer lugar, el temido seguimiento "estándar" de Profiler heredado aparentemente se ha utilizado como modelo para la sesión ADS Profiler XE para Azure SQL Database , llamado ADS_Standard_Azure por defecto. (Las sesiones XE utilizadas para SQL Server completo son similares). Como escribí en un blog hace varios años y sigo creyendo, el seguimiento estándar es una de las razones principales por las que Profiler heredado es tan mal visto. Contiene múltiples eventos inútiles y no filtrables, como inicio por lotes de SQL , iniciar sesión y cerrar sesión y, como resultado, no agrega ningún valor real para el ajuste del rendimiento. Además, con la arquitectura de seguimiento de conjunto de filas síncrono que utiliza Profiler heredado, el alto volumen de eventos puede afectar el rendimiento en sistemas ocupados. ¡Por alguna razón esto no desaparecerá!
| |
| Eventos de seguimiento "estándar" de Legacy Profiler |
Eventos XE de ADS Profiler “ADS_Standard_Azure” |
En segundo lugar, utiliza un búfer de anillo con un tamaño máximo de 8 MB o 1000 eventos, lo que ocurra primero. Debido a que los eventos de inicio/cierre de sesión son pequeños, a menudo llegará a 1000 eventos mucho antes de alcanzar el límite de 8 MB, o incluso el límite de XML con formato de 4 MB. Sin embargo, con una combinación moderada de eventos de SQL, el XML del búfer de anillo seguirá siendo de 2 a 3 MB en 1000 eventos en mis pruebas, y el problema es que todo este búfer se extrae de la red cada vez que la extensión Profiler sondea para actualizar su grilla , que es el más largo de cada segundo o duración de la encuesta anterior. Luego, la extensión ADS Profiler analiza el XML en el lado del cliente para determinar qué eventos son nuevos desde la última encuesta y los nuevos eventos se agregan a la cuadrícula.
El búfer de anillo se llena casi instantáneamente, incluso en un servidor moderadamente ocupado, y el efecto neto es que usará rápidamente>40 megabits por segundo a través de la red desde su base de datos Azure SQL. . ¡Esto se traduce en 300 megabytes por minuto o 18 gigabytes por hora!
Acceso a la red de la extensión ADS Profiler (rango de 4 minutos)
Mi temor inicial era que esto podría dar lugar a enormes cargos de salida en la próxima factura de Azure, sin embargo, al observar nuestras propias suscripciones de Azure, no pudimos confirmar que se cobra el tráfico de red para Azure SQL DB. Mike Wood (b|t) de SentryOne, un MVP de Azure, pasó semanas tratando de encontrar la respuesta y finalmente recibió la noticia de Microsoft de que, de hecho, la salida de la red actualmente no se cobra por Azure SQL DB, aunque esto podría cambiar en cualquier momento. Aun así, extraer 18 GB de datos de consulta por hora no parece responsable y, sin duda, podría poner un freno a tu próxima sesión de atracones de Netflix.
Aunque puede establecer filtros a través de la interfaz de usuario de Profiler, lo que facilitará la revisión de los datos, no reducirá el impacto en la red, ya que operan del lado del cliente.
Una sesión XE actualizada
Una solución rápida para reducir la carga de la red de ADS Profiler y hacer que los datos sean mucho más consumibles para el ajuste del rendimiento de las consultas es actualizar el ADS_Standard_Azure sesión XE. A continuación se muestra un script que:
- Eliminar los eventos inútiles:
- sqlserver.atención
- sqlserver.existing_connection
- sqlserver.iniciar sesión
- sqlserver.cerrar sesión
- sqlserver.sql_batch_starting
- Establezca un umbral de duración> 1 segundo (1000000 microsegundos) en los eventos restantes:
- sqlserver.rpc_completed
- sqlserver.sql_batch_completed
- Reducir el tamaño máximo del búfer circular de 1000 a 10 eventos
- Esto nunca funcionaría con el seguimiento original, ya que se generarían 10 eventos en milisegundos y el búfer circular se reciclaría demasiado rápido, lo que provocaría la pérdida de la mayoría de los eventos. Sin embargo, con el filtro de duración de 1 segundo, el flujo de eventos será mucho menor, y 10 eventos deberían funcionar bien con el intervalo de sondeo de 1 segundo que utiliza ADS Profiler.
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
DROP EVENT sqlserver.attention,
DROP EVENT sqlserver.existing_connection,
DROP EVENT sqlserver.login,
DROP EVENT sqlserver.logout,
DROP EVENT sqlserver.rpc_completed,
DROP EVENT sqlserver.sql_batch_completed,
DROP EVENT sqlserver.sql_batch_starting
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
ADD EVENT sqlserver.rpc_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000)))),
ADD EVENT sqlserver.sql_batch_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000))))
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
DROP TARGET package0.ring_buffer
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
ADD TARGET package0.ring_buffer(SET max_events_limit=(10),max_memory=(51200))
GO Después de aplicar la secuencia de comandos para actualizar la sesión XE, el incendio se reducirá inmediatamente a un goteo:
Golpe de red reducido después de actualizar la sesión de ADS Profiler XE
Alternativas de peso aún más ligero
SQL Sentry y su homólogo de SaaS, SentryOne Monitor, son las únicas otras soluciones que conozco para capturar consultas de Azure SQL Database, y lo hacen mediante un enfoque innovador que es considerablemente más ligero que la sesión XE optimizada anterior para ADS Profiler. Entre otras características avanzadas, puede agregar fácilmente por nombre de host del cliente, aplicación e inicio de sesión, y capturar automáticamente planes de consulta para su análisis con el Explorador de planes integrado.
Monitor SentryOne que muestra consultas y planes capturados de Azure SQL Database
Cierre
Microsoft ha declarado que continuarán mejorando la extensión ADS Profiler y, cuando lo hagan, espero que aborden los problemas descritos anteriormente. He registrado el problema aquí. Mientras tanto, la secuencia de comandos actualizada hará que la experiencia de generación de perfiles de consultas sea más segura y más amigable con el ancho de banda para Azure SQL Database.
