Início / dba / Perguntas / 818
Accepted
Andrew Shepherd
Asked: 2011-01-24 14:19:35 +0800 CST

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

  • 772

Como desenvolvedor, 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 sempre usei no meu ambiente de desenvolvimento , e de forma bem controlada.

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

O SQL Profiler pode ser usado de forma prática 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 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 sendo muito difícil de consultar).

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

sql-server profiler

4 respostas

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

    • 21
  2. Best Answer

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

    Impacto no desempenho: Rastreamento do Profiler 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.

    Livro Online disse:

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

    1. Sim, o ato de monitorar exigirá alguns recursos. Executá-lo em um servidor sobrecarregado pode 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 executamos na produção às vezes. 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 outras bobagens

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

    Nesse caso, se você quiser ver os resultados de algumas ações, pode fazê-lo fora do horário?

    • 7

  4. O Profiler sempre apresentará um impacto no desempenho.

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

    Introdução aos livros online 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.

    • 2

relate perguntas