Consumo de recursos na execução do profiler do Deadlock no banco de dados de produção

Question

É bem conhecido que o a execução de um profiler consome muitos recursos, dependendo de quais eventos estão sendo monitorados.

Estou interessado em monitorar os deadlocks que ocorrem ocasionalmente (3 a 5 por semana).
usando o SQL Server Profiler com as seguintes seleções de eventos (todos os eventos, mas os destacados de TSQL_Locks template)

Será que diminuir a velocidade para monitorar (por uma semana inteira sem parar) bloqueia apenas os bancos de dados de produção?

Existem regras gerais sobre when e how long para executar o profiler de deadlocks?

    

Answer 1

Use um rastreamento do lado do servidor. Faça uma pesquisa usando o Profiler para criar rastreios do lado do servidor para descobrir os detalhes.

Aqui está uma decente postagem no blog sobre o tópico. Essa é a melhor maneira de reduzir o impacto no seu banco de dados de produção.

Sua outra alternativa é ativar os sinalizadores de rastreamento 1204 e / ou 1222 & monitorar a saída no log de erros.

Por quanto tempo você deve executar o rastreamento? Tempo suficiente para descobrir & consertar o código envolvido. Você também desejará executar o rastreamento novamente assim que a correção for implementada para garantir que não ocorra novamente.

Talvez alguns argumentem que é sempre bom ter os sinalizadores de rastreamento ativados. Eu acho que depende da aplicação, como sinalizadores de rastreamento também criam carga adicional.