Clique no banner para conhecer e adquirir o meu treinamento de Bancos de Dados no Azure

SQL Server – Como identificar e monitorar a execução de triggers

Visualizações: 3.190 views
Tempo de Leitura: 5 minutos

Em um ambiente com muitas triggers sendo disparadas, muitas vezes é necessário conseguir identificar e monitorar a execução de triggers para analisar um determinado comportamento ou entender como um dado está sendo alterado.

Isso acaba ficando ainda mais complexo quando uma trigger altera dados de outra(s) tabela(s) e várias triggers são disparadas em sequência, aninhadamente, a partir de um único comando SQL.

É isso que você aprenderá nesse artigo.

Um das formas de conseguir identificar o comando DML que disparou uma trigger é alterar a própria trigger para capturar o comando SQL.

Veja como fazer isso nos artigos abaixo:

Exemplo:

Criação da base de testes

Para a demonstração desse post, compartilharei os scripts utilizados para que você possa testar no seu ambiente também.

Criação das tabelas
Clique aqui para visualizar o código das tabelas

Criação das triggers
Clique aqui para visualizar o código das triggers

Como identificar e monitorar a execução de triggers

Agora que temos as tabelas e triggers criadas, vamos iniciar o nosso monitoramento, alterar alguns dados e testar se está tudo funcionando conforme o esperado.

Vamos criar um Extended Event (XE) para capturar a execução das triggers:

Vamos executar algumas alterações de dados para testar o nosso monitor de triggers:

E agora vamos ler os dados coletados do Extended Event para visualizar o histórico de execução das triggers

Resultado:

Com esse script, você pode identificar cada comando executado dentro da trigger (coluna statement) ou o comando que disparou a trigger (coluna sql_text).

Caso você queira algo mais simples e resumido, para saber só quando as triggers foram disparadas, pode usar esse script aqui:

Resultado:

Nessa versão mais resumida, fica bem fácil identificar que um único update ativou 2 triggers ao observarmos as colunas de eventDate, nest_level e sql_text. Após o comando UPDATE, a trigger “trgFuncionario” foi disparada e como essa trigger faz um outro UPDATE na tabela “Cliente”, ela ativou a trigger “trgHistorico_Cliente”.

Agora ficou fácil identificar triggers sendo disparadas no ambiente, especialmente as triggers aninhadas como esse exemplo, onde um único comando pode acabar disparando várias triggers, ficando difícil de rastrear num ambiente grande.

Espero que tenham gostado dessa dica e até o próximo artigo!
Abraços.