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

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

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

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

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

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

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

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

Usar o Sql Server Profiler (ferramenta GUI) para rastrear um servidor de produção não é uma boa ideia. Mas isso depende da carga. Use o rastreamento sql do lado do servidor (consulte procedimentos sp_trace_XXX ) em vez dele. Também encontrei artigos:

Impacto no desempenho: rastreamento do criador de perfil vs. rastreamento SQL do lado do servidor ,

Automatizando o rastreamento do lado do servidor no SQL Server

Evite causar problemas com o Profiler

talvez seja interessante e útil.

O Book Online diz:

• Execute o Profiler remotamente em vez de diretamente no servidor
• Evite incluir eventos que ocorrem com freqüência (por exemplo, Bloqueio: adquirido), a menos que seja absolutamente necessário
• Incluir apenas as classes de eventos necessárias
• Especifique filtros limitadores para reduzir o número de eventos
• Evite dados redundantes (por exemplo, SQL: BatchStarting e SQL: BatchCompleted)
• Evite executar rastreamentos grandes com o Profiler; considere um rastreamento SQL do lado do servidor
• Limite o tamanho do arquivo de rastreamento do lado do servidor e gerencie o uso do espaço

Eu uso o SQL Profiler contra produção o tempo todo. Quando feito corretamente (filtragem para que você receba uma quantidade muito pequena de dados) em um servidor, o risco é mínimo. Rastrear tudo seria inútil.

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

2. Você realmente monitora a carga da vida real: suas ações podem se perder no barulho dessa carga.

Às vezes, rodamos na produção. Principalmente com um filtro de texto para código específico ou com filtros de CPU / duração para interceptar consultas em execução mais longas. E não tentamos capturar planos de execução XML ou algo assim

A chave é saber o que você está procurando: não tendemos a deixá-lo em execução e aprisionar tudo.

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

O Profiler sempre apresentará um impacto no desempenho.

Se você estiver usando o SQL Server 2008R2 +, poderá usar eventos estendidos. Isso fornece muitas das informações que você vê no criador de perfil com uma fração do desempenho atingido.

Introdução online de livros http://technet.microsoft.com/en-us/library/bb630354(v=sql.105).aspx

Esse recurso recebeu uma grande atualização no SQL Server 2012, que agora inclui uma GUI no SSMS.