O SQL Server sempre forneceu a capacidade de capturar consultas ao vivo em uma base ad hoc em um formato de conjunto de linhas facilmente consumível – primeiro com o SQL Server Profiler legado, depois por meio de eventos estendidos no SSMS. Esse recurso é valioso ao ajustar o desempenho, pois os eventos de consulta incluem métricas discretas de CPU e E/S, bem como parâmetros de tempo de execução, que são essenciais para solucionar problemas de desempenho de consulta, como detecção de parâmetros. Além disso, os eventos de consulta contêm outros elementos importantes, como o nome do host do cliente, o nome do aplicativo, o login, o ID do processo do Windows etc.
Você sempre pode recuperar agregados métricas de desempenho para normalizadas consultas de DMVs ou Query Store, mas contêm apenas compilados parâmetros e nenhum dos elementos acima mencionados. Embora isso seja útil, não é o mesmo. Por exemplo, se você precisar ver a combinação de parâmetros específica usada por essa consulta que fez 2 bilhões de leituras ou encontrar o aplicativo que mais consumiu CPU nas últimas 24 horas, você está sem sorte.
O Banco de Dados SQL do Azure não é compatível com o Profiler herdado e a Microsoft desativou o provedor de streaming XEvents (sys.fn_MSxe_read_event_stream TVF) por motivos de confiabilidade, portanto, você não pode ativar uma sessão XE e "assistir dados ao vivo" com SSMS. O Query Performance Insights no Portal do Azure é apoiado pelo Repositório de Consultas, para que você tenha novamente apenas as consultas normalizadas e os dados de desempenho agregados, não os eventos de consulta reais.
Portanto, por alguns anos, ficamos presos – a única opção para criar perfil do Banco de Dados SQL do Azure era criar manualmente um rastreamento XEvents que grava em um buffer de anel ou destino de arquivo com o Armazenamento do Azure, nenhum dos quais é ideal. Usar o buffer de anel com consultas T-SQL pode ser problemático devido ao limite XML formatado de 4 MB, conforme abordado por Jonathan Kehayias aqui, e os destinos de arquivo exigem uma quantidade razoável de saltos e despesas adicionais. Ambos exigem consulta manual dos dados XE e, portanto, não são exatamente "vivos" no sentido tradicional.
Digite o Novo Perfil do SQL Server
Quando soube da extensão do SQL Server Profiler para o Azure Data Studio, tive o prazer de ver a Microsoft finalmente entregar uma solução gráfica para captura de consultas ao vivo no Banco de Dados SQL do Azure. Infelizmente, minha empolgação durou pouco por algumas razões.
Primeiro, o temido rastreamento "Padrão" do Profiler herdado aparentemente foi usado como modelo para a sessão do ADS Profiler XE para o Banco de Dados SQL do Azure , chamado ADS_Standard_Azure por padrão. (As sessões XE usadas para o SQL Server completo são semelhantes.) Como escrevi no blog há vários anos e ainda acredito, o rastreamento padrão é a principal razão pela qual o Profiler legado é tão mal visto. Ele contém vários eventos inúteis e não filtráveis, como início em lote SQL , entrar e sair , e como resultado, não agrega valor real para ajuste de desempenho. Além disso, com a arquitetura de rastreamento de conjunto de linhas síncrona usada pelo Profiler legado, o alto volume de eventos pode afetar o desempenho em sistemas ocupados. Por alguma razão essa coisa não vai embora!
| |
| Eventos de rastreamento "Padrão" do Profiler legado | ADS Profiler "ADS_Standard_Azure" eventos XE – parece familiar? |
Segundo, ele usa um buffer de anel com tamanho máximo de 8 MB ou 1.000 eventos, o que ocorrer primeiro. Como os eventos de login/logout são pequenos, muitas vezes você atingirá 1.000 eventos muito antes de atingir o limite de 8 MB, ou mesmo o limite XML formatado de 4 MB. No entanto, com uma mistura moderada de eventos SQL, o XML do buffer de anel ainda será de 2 a 3 MB em 1.000 eventos em meus testes, e o problema é que esse buffer inteiro é puxado pela rede toda vez que a extensão do Profiler pesquisa para atualizar sua grade , que é o mais longo de cada 1 segundo ou duração da votação anterior. O XML é então analisado do lado do cliente pela extensão ADS Profiler para determinar quais eventos são novos desde a última pesquisa e os novos eventos são adicionados à grade.
O buffer de anel é preenchido quase instantaneamente mesmo em um servidor moderadamente ocupado, e o efeito líquido é que você estará rapidamente puxando>40 megabits por segundo pela rede do seu Banco de Dados SQL do Azure . Isso se traduz em 300 megabytes por minuto, ou 18 gigabytes por hora!
Acerto de rede da extensão ADS Profiler (intervalo de 4 minutos)
Meu medo inicial era que isso pudesse levar a enormes cobranças de saída na próxima fatura do Azure, no entanto, analisando nossas próprias assinaturas do Azure, não conseguimos confirmar se o tráfego de rede para o BD SQL do Azure é cobrado. Mike Wood (b|t), da SentryOne, um MVP do Azure, passou semanas tentando encontrar a resposta e finalmente recebeu a notícia da Microsoft de que, de fato, a saída de rede atualmente não é cobrada pelo Azure SQL DB, embora isso possa mudar a qualquer momento. Mesmo assim, baixar 18 GB de dados de consulta por hora não parece responsável e certamente pode atrapalhar sua próxima sessão de maratona da Netflix.
Embora você possa definir filtros por meio da interface do usuário do Profiler, o que facilitará a revisão dos dados, isso não reduzirá o impacto da rede, pois eles operam no lado do cliente.
Uma Sessão XE Atualizada
Uma solução rápida para reduzir a carga de rede do ADS Profiler e tornar os dados muito mais consumíveis para ajuste de desempenho de consulta é atualizar o ADS_Standard_Azure Sessão XE. Abaixo está um script que irá:
- Exclua os eventos inúteis:
- servidorsql.atenção
- sqlserver.existing_connection
- sqlserver.login
- sqlserver.logout
- sqlserver.sql_batch_starting
- Defina um limite de duração> 1 segundo (1.000.000 microssegundos) para os eventos restantes:
- sqlserver.rpc_completed
- sqlserver.sql_batch_completed
- Reduza o tamanho máximo do buffer de anel de 1.000 para 10 eventos
- Isso nunca funcionaria com o rastreamento original, pois 10 eventos serão gerados em milissegundos e o buffer de anel reciclaria muito rapidamente, causando a perda da maioria dos eventos. No entanto, com o filtro de duração de 1 segundo, o fluxo de eventos será muito menor e 10 eventos devem funcionar bem com o intervalo de pesquisa de 1 segundo usado pelo 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 Após aplicar o script para atualizar a sessão XE, o firehose será imediatamente reduzido a um trickle:
Redução da ocorrência de rede após atualizar a sessão do ADS Profiler XE
Alternativas de peso ainda mais leves
O SQL Sentry e sua contraparte de SaaS, o SentryOne Monitor, são as únicas outras soluções que conheço para capturar consultas do Banco de Dados SQL do Azure, e o fazem usando uma abordagem inovadora que é consideravelmente mais leve do que a sessão XE otimizada acima para o ADS Profiler. Entre outros recursos avançados, você pode agregar facilmente por nome de host do cliente, aplicativo e login e capturar automaticamente planos de consulta para análise com o Plan Explorer integrado.
Monitor SentryOne mostrando consultas e planos capturados do Banco de Dados SQL do Azure
Fechando
A Microsoft declarou que continuará aprimorando a extensão do ADS Profiler e, quando isso acontecer, espero que eles resolvam os problemas descritos acima. Já registrei o problema aqui. Enquanto isso, o script atualizado proporcionará uma experiência de criação de perfil de consulta mais segura e amigável à largura de banda para o Banco de Dados SQL do Azure.
