Usando o SQL Profiler em um banco de dados que está em produção

Question

Como desenvolvedor, uso o SQL Profiler com bastante frequência. É uma boa ferramenta de depuração, tanto para acompanhar o que meu código está fazendo quanto para analisar problemas de desempenho.

Mas eu sempre usei isso no meu ambiente de desenvolvimento e de uma maneira muito controlada.

• Inicie meu aplicativo e coloque-o em um estado específico
• Inicie o criador de perfil
• Execute uma sequência específica de ações no meu aplicativo
• Pare o profiler e examine os resultados.

O SQL Profiler pode ser usado praticamente em um ambiente de produção?

Minha primeira preocupação é que isso degradaria o desempenho.

Minha segunda preocupação é que, por estar em produção, você não está acionando as ações interessantes em si. Você teria que deixar o profiler executando por um longo período e analisar os resultados. O conjunto de resultados se tornaria muito pesado? (Ocupando muito espaço em disco e sendo muito difícil de consultar).

Alguém usa o SQL Profiler em produção?

Divulgação completa: publiquei a mesma pergunta no Site Beta dos Administradores de Banco de Dados . Os membros do Serverfault que desejam suportar o site DBA stackexchange têm a oportunidade de responder à pergunta lá, e não aqui.     

Answer 1

1. Sim, o ato de monitorar exigirá alguns recursos. Executá-lo em um servidor sobrecarregado poderia matá-lo.

2. Na verdade, você monitorará a carga da vida real: suas ações podem se perder no ruído dessa carga.

Nós o colocamos em produção algumas vezes. Principalmente com um filtro de texto para um código específico ou com filtros de CPU / duração para capturar uma execução mais longa. E nós não tentamos capturar planos de execução de XML ou alguma dessas besteiras

A chave é saber o que você está procurando: não tendemos a deixá-lo funcionando e prender tudo.

Neste caso, se você quiser ver os resultados de algumas ações, pode fazê-lo fora de horas?