Durante o monitoramento do desempenho ou a solução de problemas como lentidão do sistema, pode ser necessário localizar ou capturar consultas que tenham alta duração, alta CPU ou gerem E/S significativa durante a execução. Você pode usar as DMVs ou o Repositório de Consultas para obter informações sobre o desempenho da consulta, mas as informações em ambas as fontes são agregadas. Os DMVs representam CPU média, E/S, duração etc. para uma consulta apenas enquanto ela estiver em cache. O Query Store também fornece métricas médias para vários recursos, mas é agregado em uma janela de tempo definida (por exemplo, 30 minutos ou uma hora). É claro que existem soluções de monitoramento de terceiros que são mais do que capazes de fornecer tudo isso e muito mais (como o SentryOne), mas para este post eu queria focar em ferramentas nativas.
Se você quiser entender o desempenho da consulta para execuções individuais para identificar a consulta exata ou o conjunto de consultas que pode ser um problema, a opção mais fácil é usar Eventos Estendidos. E uma das maneiras mais rápidas de começar é usar o XEvent Profiler, que está disponível através do SQL Server Management Studio (a partir da versão 17.3):
XEvent Profiler no SSMS Uso Básico
Existem duas opções para o XEvent Profiler:Standard e TSQL. Para usar qualquer um, basta clicar duas vezes no nome. Nos bastidores, uma sessão de evento definida internamente é criada (se ainda não existir) e iniciada, e o Live Data Viewer abre imediatamente com foco. Observe que, depois de iniciar a sessão, ela também aparecerá em Gestão | Eventos Estendidos | Sessões. Supondo que você tenha atividade no servidor, você deve começar a exibir entradas no visualizador em cinco segundos ou menos.
Visualizador de dados ao vivo (após clicar duas vezes para iniciar a sessão padrão) As sessões Standard e TSQL compartilham alguns eventos, com a Standard tendo mais no total. Aqui está uma lista dos eventos para cada um:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Se você deseja entender as informações sobre a execução da consulta, como quanto tempo a consulta levou para ser executada ou quanta E/S ela consumiu, o Padrão é uma opção melhor devido aos dois eventos concluídos. Para ambas as sessões, o único filtro é excluir consultas do sistema para os eventos de lote, rpc e atenção.
Visualizando e salvando dados
Se iniciarmos a sessão padrão e executarmos algumas consultas, no visualizador veremos o evento, o texto da consulta e outras informações úteis, como cpu_time, logical_reads e duração. Um dos benefícios de usar rpc_completed e sql_batch_completed é que o parâmetro de entrada aparece. Em um caso em que haja um procedimento armazenado que tenha grandes variações de desempenho, capturar o parâmetro de entrada pode ser extremamente útil, pois podemos combinar uma execução que demora mais com um valor específico passado para o procedimento armazenado. Para encontrar esse parâmetro, precisamos classificar os dados com base na duração, o que não podemos fazer quando o feed de dados está ativo. Para realizar qualquer tipo de análise, o feed de dados deve ser interrompido.
Parando o feed de dados no Live Viewer Agora que minhas consultas não estão mais rolando em um borrão, posso clicar na coluna de duração para classificar meus eventos. A primeira vez que eu clicar, ele classificará em ordem crescente e, como sou preguiçoso e não quero rolar a parte inferior, clicarei novamente para classificar em ordem decrescente.
Eventos classificados em duração decrescente Agora posso ver todos os eventos que capturei em ordem de duração mais alta para a mais baixa. Se eu estivesse procurando por um procedimento armazenado específico que fosse lento, eu poderia rolar para baixo até encontrá-lo (o que poderia ser doloroso) ou poderia agrupar ou filtrar os dados. O agrupamento é mais fácil aqui, porque eu sei o nome do procedimento armazenado.
O object_name é exibido na parte superior do visualizador, mas clicar em qualquer evento rpc_completed mostra todos os elementos capturados no painel Detalhes. Clique com o botão direito do mouse em object_name, que irá realçá-lo, e selecione Show Column in Table.
Adicionar object_name ao visualizador de dados No painel superior, agora posso clicar com o botão direito do mouse em object_name e selecionar Group by this Column. Se eu expandir os eventos em usp_GetPersonInfo e depois classificar novamente por duração, agora vejo que a execução com PersonID=3133 teve a duração mais alta.
Eventos agrupados por object_name, usp_GetPersonInfo ordenados por duração decrescente Para filtrar os dados:Use o botão Filtros…, a opção de menu (Eventos estendidos | Filtros…), ou CTRL + R para abrir uma janela para reduzir o conjunto de resultados com base nos diferentes campos exibidos. Nesse caso, filtramos object_name =usp_GetPersonInfo, mas você também pode filtrar campos como server_principal_name ou client_app_name, conforme foram coletados.
Vale ressaltar que nem a sessão Standard nem a TSQL grava em um arquivo. Na verdade, não há destino para nenhuma sessão de evento (se você não sabia que pode criar uma sessão de evento sem um destino, agora você sabe). Se você deseja salvar esses dados para análise posterior, você precisa fazer o seguinte:
- Pare o feed de dados e salve a saída em um arquivo por meio do menu Extended Events (Export to | XEL File…)
- Pare o feed de dados e salve a saída em uma tabela em um banco de dados por meio do menu Extended Events (Export to | Table…)
- Altere a sessão do evento e adicione o event_file como destino.
A opção 1 é minha recomendação, pois cria um arquivo em disco que você pode compartilhar com outras pessoas e revisar posteriormente no Management Studio para análise posterior. No Management Studio, você pode filtrar dados que não são relevantes, classificar por uma ou mais colunas, agrupar os dados e realizar cálculos (por exemplo, médias). Você pode fazer isso se os dados forem uma tabela, mas você precisa escrever o TSQL; analisar os dados na interface do usuário é mais fácil e rápido.
Alterando as sessões do XEvent Profiler
Você pode modificar as sessões de eventos Standard e TSQL e as alterações feitas persistirão por meio das reinicializações da instância. No entanto, se as sessões de eventos forem descartadas (depois de fazer modificações), elas serão redefinidas para os padrões. Se você estiver fazendo as mesmas alterações continuamente, sugiro que faça o script das alterações e crie uma nova sessão de evento que também persistirá nas reinicializações. Como exemplo, se observarmos a saída capturada até agora, podemos ver que tanto as consultas ad hoc quanto os procedimentos armazenados foram executados. E embora seja ótimo poder ver os diferentes parâmetros de entrada para os procedimentos armazenados, não vejo as instruções individuais que estão sendo executadas com esse conjunto de eventos. Para obter essas informações, eu precisaria adicionar o evento sp_statement_completed.
Entenda que as sessões de evento Standard e TSQL foram projetadas para serem leves. Os eventos statement_completed serão acionados com mais frequência do que os eventos batch e rpc, portanto, pode haver mais sobrecarga quando esses eventos fazem parte de uma sessão de eventos. Ao usar eventos de instrução, eu altamente recomendo incluir predicados adicionais. Como lembrete, os eventos rpc e batch estão apenas filtrando as consultas do sistema – não há outro predicado. Em geral, também recomendo predicados adicionais para esses eventos, especialmente para uma carga de trabalho de alto volume.
Se você estiver preocupado se a execução das sessões Standard ou TSQL causará um impacto no desempenho do seu sistema, entenda que o Live Data Viewer será desconectado se estiver criando muita sobrecarga no sistema. Esta é uma grande segurança, mas eu ainda seria cuidadoso ao usar essas sessões de eventos. Eu acredito que eles são um primeiro passo fantástico para solução de problemas, principalmente para aqueles que são novos no SQL Server ou Extended Events. No entanto, se você tiver o Live Data Viewer aberto e se afastar da máquina, a sessão do evento continuará em execução . Parar ou fechar o Live Data Viewer interromperá a sessão do evento, que é o que eu recomendo quando você terminar sua coleta de dados ou solução de problemas.
Para sessões de eventos que você deseja executar por um longo período de tempo, crie sessões de eventos separadas que gravem no destino event_file e tenham predicados apropriados. Se você precisar de mais informações sobre como começar com Extended Events, confira a sessão que dei no SQLBits no ano passado sobre a migração do Profiler para Extended Events.
