No meu último post, ilustrei um motivo pelo qual você deve parar de usar tabelas de sistema obsoletas como
sysprocesses . Isso não foi por motivos de desempenho, diretamente, ou simplesmente para seguir as práticas recomendadas documentadas da Microsoft, mas girava mais em torno das decisões que você pode tomar quando tiver acesso apenas a alguns dos dados. Desta vez, quero falar sobre um recurso incluído nas ferramentas de cliente do SQL Server que não devemos usar hoje em dia – não apenas porque está obsoleto, mas, mais importante, porque tem o potencial de derrubar completamente um servidor:
SQL Server Profiler
Desde o SQL Server 2012 (e, em menor grau, desde o SQL Server 2008), a solução mais completa e flexível para monitorar eventos em uma instância do SQL Server tem sido o Extended Events. Por outro lado, desde que foi inventado (mais ou menos na época em que comecei minha carreira), o SQL Server Profiler tem sido uma das maneiras mais prolíficas de acidentalmente derrubar um servidor.
Não muito tempo atrás, algo assim aconteceu conosco. Um desenvolvedor fez uma alteração em seu aplicativo para reduzir o número de viagens de ida e volta que estava fazendo. Eles executaram o aplicativo localmente e em nosso ambiente de desenvolvimento, usando o Profiler com um rastreamento filtrado, para confirmar que suas alterações estavam funcionando conforme o esperado. Deixe-me lembrá-lo neste momento que a documentação oficial do SQL Server Profiler inclui o seguinte aviso:
O SQL Trace e o SQL Server Profiler foram preteridos. O namespace Microsoft.SqlServer.Management.Trace que contém os objetos Trace e Replay do Microsoft SQL Server também foi preterido. Esse recurso será removido em uma versão futura do Microsoft SQL Server. Evite usar esse recurso em novos trabalhos de desenvolvimento e planeje modificar os aplicativos que atualmente usam esse recurso.
De qualquer forma, quando eles implantaram a nova versão de seu aplicativo em produção e direcionaram o servidor de produção com o mesmo rastreamento filtrado, não foi tão bom. Seu filtro curinga no nome do aplicativo não levou em consideração os outros aplicativos (com nomes semelhantes) que também se conectavam a esse servidor e eles imediatamente começaram a capturar muito mais informações do que a janela aberta do Profiler poderia manipular. Isso resultou em um aumento catastrófico no tempo de conexão para todos os usuários e aplicativos conectados a essa instância. Seria um eufemismo dizer que as queixas foram apresentadas.
Quando o culpado foi determinado e obtivemos uma resposta do desenvolvedor, você pode ver que o tempo de conexão voltou ao normal quase imediatamente depois que eles interromperam o rastreamento do Profiler (clique para ampliar):
Um mini-desastre do SQL Server Profiler Este é definitivamente um cenário em que a antiga declaração "funcionou na minha máquina" não significa de forma alguma que funcionará bem em um servidor de produção ocupado. E esse incidente levou a uma conversa ativa sobre como modificar o gatilho de logon que já existe em todos os servidores em nosso ambiente para simplesmente bloquear o nome do aplicativo que o Profiler passa em sua string de conexão.
Talvez isso não seja um problema do Profiler. (Mas meio que é.)
Não estou aqui para sugerir que outras ferramentas de monitoramento, incluindo Extended Events, não possam ser usadas de forma inadequada para derrubar um servidor de maneira semelhante (ou pior!). Há muitas oportunidades para afetar inadvertidamente uma instância do SQL Server, de maneiras realmente adversas, sem tocar no SQL Server Profiler.
Mas o Profiler é notório por esse tipo de sintoma devido à forma como ele consome dados. É uma interface de usuário com uma grade que apresenta novas linhas à medida que as recebe; infelizmente, ele faz o SQL Server esperar enquanto os renderiza antes de permitir que o SQL Server transmita mais linhas. Esse comportamento é semelhante a como o SQL Server Management Studio pode tornar as consultas mais lentas e causar alta
ASYNC_NETWORK_IO espera enquanto tenta renderizar uma grande quantidade de saída para sua própria grade. Isso é uma simplificação (e não deve ser confundido com a maneira como o SQL Trace subjacente pode se comportar, o que Greg Gonzalez (@SQLsensei) explica em "Don't Fear the Trace"), mas é exatamente o que leva a o tipo de cenário mostrado acima:esse gargalo tem um efeito em cascata em qualquer outro processo que tente fazer qualquer coisa no mesmo caminho de código que você está rastreando (incluindo tentar estabelecer uma conexão). Medo de eventos prolongados?
Não seja. Já é hora de abandonarmos o Profiler e abraçarmos o presente . Não faltam tutoriais e guias por aí, incluindo o QuickStart da própria Microsoft e vários artigos aqui mesmo neste site.
Se você tem rastreamentos existentes nos quais confia, Jonathan Kehayias (@SQLPoolBoy) tem um script realmente útil para converter um rastreamento existente em Eventos Estendidos. Você ainda pode se sentir à vontade para configurar o rastreamento original com a IU do Profiler, se for onde estiver mais confortável; apenas faça isso sem se conectar a um servidor de produção. Você pode ler sobre esse script aqui e ver alguns dos outros artigos de eventos estendidos de Jonathan aqui.
Se você está tendo dificuldades com a experiência do usuário, você não está sozinho, mas existem algumas respostas:
- Erin Stellato (@erinstellato) tem sido uma defensora espetacular de Eventos Estendidos e muitas vezes se pergunta em voz alta por que as pessoas estão relutantes em deixar de lado o Profiler e o SQL Trace em geral. Ela tem alguns insights (e inspirou muitos comentários) em seu post de 2016, "Por que VOCÊ evita Eventos Estendidos?"; talvez haja alguma dica sobre se seus motivos para resistir ainda são válidos em 2021.
- Há um XEvent Profiler integrado às versões modernas do SSMS, com uma extensão equivalente para o Azure Data Studio. Embora, confusamente, eles chamassem essa extensão – de todas as coisas que se poderia imaginar – SQL Server Profiler . Erin também tem alguns pensamentos sobre essa escolha.
- Erik Darling (@erikdarlingdata) criou
sp_HumanEventspara aliviar um pouco a dor de mudar para Eventos Estendidos. Uma das minhas pessoas favoritas do tipo "seja direto ao ponto", Erik descrevesp_HumanEventsda seguinte forma:"Se você quiser uma maneira fácil de criar perfis de métricas de consulta, aguardar estatísticas, bloquear, compilar ou recompilar com eventos estendidos, este é o seu unicórnio."
