Gostaria de configurar um tipo de sistema de trilha de auditoria no meu banco de dados para monitorar UPDATE/INSERTinstruções em uma tabela específica com atividade muito alta. Tenho duas opções à minha frente: usando o sistema de auditoria interno do SQL Server ou vá com Eventos estendidos.
Como a Auditoria do SQL Server usa internamente Eventos Estendidos, presumo que haverá algum tipo de sobrecarga quando usar Auditoria em vez de Eventos Estendidos diretamente.
Existe alguma maneira de fazer alguns testes para analisar qual sistema está impactando mais o servidor? Se eu pudesse saber o que realmente acontece quando qualquer sessão XE é criada, isso me ajudaria a analisar o impacto no servidor.
Consideramos gatilhos e deixamos de fora essa opção por causa de sobrecarga. Mas isso foi decidido com base em informações da Internet.
— karun_r
Nem todos os eventos capturados por meio de uma auditoria SQL são acessíveis pelo XEvents. A auditoria do SQL utiliza o mesmo mecanismo por trás do XEvents, mas são recursos separados.
Sim. Veio a saber sobre isso. Porém, quando fizemos algum tipo de teste de carga (veja abaixo), observamos que o XE tem mais sobrecarga do que a auditoria. Se a auditoria usa o XE em segundo plano, alguma idéia de por que está causando mais sobrecarga?
Criei uma plataforma de teste simples para testar a Auditoria do SQL Server contra gatilhos e potencialmente outras opções. Nos meus testes de inserção de 1 milhão de linhas em uma tabela, obtive 52, 67 e 159 segundos para a linha de base, a Auditoria SQL e meu gatilho, respectivamente:
Agora, isso não é particularmente científico, mas potencialmente oferece uma maneira de comparar abordagens. Dê uma olhada no script, veja se ele pode ser útil para você:
Embora a opção de gatilho não tenha se saído muito bem aqui, meu código de gatilho pode ser simplificado dependendo do que você deseja capturar e permite acessar os valores antigos e novos em um formato bastante utilizável que o SQL Audit não faz. Eu usei essa técnica para uma tabela de configuração de atividade mais baixa e funciona muito bem. Dependendo do que você deseja capturar, você também pode considerar o Change Data Capture .
Deixe-me saber como você continua suas tentativas. Boa sorte.
Um benefício da Auditoria que vem à mente é que ela grava automaticamente quem a liga e desliga, o XE não fará isso imediatamente (embora você possa encontrar um evento que rastreie a parada / partida do XE). Você também pode descobrir que os dois capturam dados diferentes, dependendo exatamente do que você deseja.
Ao fazer alguns testes, você precisaria ter um backup do banco de dados, capturar um rastreio do aplicativo sob carga e restaurar a cópia enquanto fazia uma repetição / repetição com auditoria / substituição com o XE e comparando dados de desempenho.
Quais dados de desempenho? Você decide. Para algumas idéias - Linchi Shea fez uma comparação entre Audit e Trace, concentrando-se em Transações / s, enquanto Kehayias fez uma comparação entre Trace e XE, concentrando-se em lotes / s e no tempo de execução geral da reprodução.
Encorajo-vos a ler ambos e seus comentários, porque você deve saber que, não importa o que faça, estará aberto à interpretação. É difícil conseguir maçãs para comparação de maçãs. Além disso, um rastreamento / reprodução pode falhar ao simular a carga corretamente - por exemplo, quando seu aplicativo está realizando muitas cargas em massa de arquivos de disco que não existem mais.
Mas o importante é que você tente pelo menos uma coisa, para poder justificar suas decisões e também publicar um blog sobre isso para o resto de nós.
Quando você diz que a auditoria captura automaticamente os eventos ON / OFF de auditoria, você está falando sobre os tipos de ação AUSC na trilha de auditoria? Além disso, para um teste de desempenho ideal, acho que devo considerar os gargalos atuais do aplicativo e ver se a auditoria ou o XE os estão piorando.