Início / dba / Perguntas / 152572
Accepted
Fza
Asked: 2016-10-19 00:13:42 +0800 CST

Métodos para identificar/reconhecer a detecção de parâmetro 'ruim' no SQL Server

  • 772

Há muitas informações excelentes disponíveis sobre certas abordagens que podem ser usadas para mitigar o sniffing de parâmetro ruim, mas não há muitas informações sobre como identificar um problema de sniffing de parâmetro ruim.

Supondo que você não esteja usando o SQL Server 2016, portanto, não pode aproveitar o Query Store e não há usuários reclamando de um procedimento armazenado problemático que apresenta desempenho ruim de forma intermitente, quais métodos podem ser usados ​​para identificar proativamente um problema de detecção de parâmetro incorreto?

Utilizar Eventos Estendidos, Utilitários RML e simplesmente consultar/pesquisar os DMVs parecem abordagens viáveis.

sql-server monitoring

1 respostas

  1. Best Answer

    Identificar o sniffing de parâmetros é um trabalho árduo! Pode não ser aparente usando ferramentas de monitoramento ou consultas, porque normalmente requer alguma análise de outras execuções do plano de consulta.

    É aqui que os DMVs e uma ferramenta de análise de cache de plano como sp_BlitzCache podem ajudar. Você pode baixá-lo aqui . Divulgação completa: trabalho para Brent Ozar e contribuo para o projeto.

    Ele usa APENAS DMVs que estariam disponíveis por suas diretrizes para realizar análises do cache do plano, etc. Também é gratuito. Se você não pode instalar o procedimento armazenado, o trecho de código relevante para tentar identificar o sniffing de parâmetro está aqui:

     parameter_sniffing = CASE WHEN AverageReads > @parameter_sniffing_io_threshold
                                      AND min_worker_time < ((1.0 - (@parameter_sniffing_warning_pct / 100.0)) * AverageCPU) THEN 1
                                 WHEN AverageReads > @parameter_sniffing_io_threshold
                                      AND max_worker_time > ((1.0 + (@parameter_sniffing_warning_pct / 100.0)) * AverageCPU) THEN 1
                                 WHEN AverageReads > @parameter_sniffing_io_threshold
                                      AND MinReturnedRows < ((1.0 - (@parameter_sniffing_warning_pct / 100.0)) * AverageReturnedRows) THEN 1
                                 WHEN AverageReads > @parameter_sniffing_io_threshold
                                      AND MaxReturnedRows > ((1.0 + (@parameter_sniffing_warning_pct / 100.0)) * AverageReturnedRows) THEN 1 END

    As variáveis ​​são configuráveis ​​se você usar o procedimento armazenado. Se você quiser rolar o seu próprio, como você atribui os valores depende de você. O que observamos é se a média de certos atributos do plano é amplamente excedida ou, uh... superada pelos valores mínimo/máximo desses atributos.

    Estes são geralmente bons indicadores de detecção de parâmetros. Pensando em um plano de valor 'pequeno' que executa uma pesquisa de chave 5 vezes (e funciona bem para a maioria dos valores em várias execuções). Se um valor 'grande' vier a seguir e usar o plano em cache, forçando a pesquisa de chave a ser executada centenas de milhares de vezes, ele usaria mais CPU/fazeria mais leituras/executaria por mais tempo do que a média.

    Espero que isto ajude!

    • 5

relate perguntas