none
Planos de execução diferentes. RRS feed

  • Pergunta

  • Bom dia amigos...

    tenho uma query "pesada" que roda em um ambiente de produção que demora mais de 9 minutos para rodar e a mesma em um ambiente de testes roda em 0 segundos. Analisando percebi que os planos de execução estão diferentes porém as estatísticas, índices etc... estão iguais a única diferente seria a quantidade de registros na tabela principal que seria de mais ou menos 5%, uma com 46.000.000 de linhas e outra (mais rápida) com 42.000.000.

    Alguém já passou por isso ?

    Obrigado !!!


    OsvaldoM

    quinta-feira, 6 de novembro de 2014 12:18

Respostas

  • Osvaldo,

    Como você disse que em ambos os ambientes você possui os mesmos índices e estatísticas, pode ocorrer impacto na performance pela maior fragmentação no ambiente de Produção.

    De qualquer modo, antes de atualizar as estatísticas ou reorganizar os índices seria interessante você comparar se não há diferenças nas estruturas de alocação dos dados destes índices em cada ambiente (verifique o espaço definido no FILLFACTOR, se os índices estão nos mesmos FILEGROUPs, se estes índices utilizam o TEMPDB, ...).

    Também é importante verificar se o hint que você está utilizando no ambiente de Produção é o mais adequado, afinal mesmo tento um volume de dados semelhante, a concorrência de acessos às informações desta mesma tabela é certamente muito maior em Produção, então poderá ocorrer o "LOCK" para toda ou para uma parte dos dados que esta sua consulta utiliza.

    Outro ponto à ser verificado é que o Plano de Execução desta consulta (ou de outra relacionada) pode estar mantendo o seu CACHE desatualizado. Você poderá forçar uma atualização removendo todos CACHEs dos Planos de Execução deste banco ou apenas o referente à esta consulta, utilizando o comando "FREEPROCCACHE".

    Veja um exemplo abaixo:

    USE SeuBanco
    GO
    
    --APAGA TODO CACHE NO BANCO DE DADOS
    DBCC FREEPROCCACHE WITH NO_INFOMSGS;
    GO

    Veja outros modelos de uso em:

    http://technet.microsoft.com/pt-br/library/ms174283(v=sql.105).aspx

    Faça os ajustes necessários em um horário alternativo para minimizar o impacto na utilização de seus usuários. Antes de aplicar qualquer alteração, também é importante que você realize um BACKUP FULL deste seu banco de dados.

    Para maiores informações veja:

    http://technet.microsoft.com/pt-br/library/ms187348(v=sql.110).aspx

    http://msdn.microsoft.com/pt-br/library/ms189858.aspx

    http://technet.microsoft.com/pt-br/library/ms181714(v=sql.110).aspx

    http://technet.microsoft.com/pt-br/library/ms189122(v=sql.105).aspx


    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 6 de novembro de 2014 16:40
    Moderador

Todas as Respostas

  • Bom dia Osvaldo,

    Bem interessante sua observação e esse comportamento pode ser explicado.

    Motivo básicos podem envolver os itens:

    Configurações específicas na seção que está executando a query, por exemplo, uso de ANSI_DEFAULTS, ARITHABORT, ANSI_NULL_DFLT_OFF, DATEFIRST, ANSI_NULL_DFLT_ON, DATEFORMAT, etc. Isso por que o plano de execução em cache pode ter seu reuso prejudicado.

    A diferença de tamanho das tabelas em cada ambiente pode alterar o comportamento da leitura do index, por exemplo, o Query Optimizer pode optar por efetuar um Table Scan em vez de um Seek dependendo da situação.

    Configurações específicas diferentes entre os servidores, como por exemplo, o uso dos operadores do paralelismo.

    Podemos concluir que existem tanto fatores que podem interferir, que na verdade o difícil é você conseguir um plano de execução igual entre os ambientes.

    Sugiro para uma analise mais precisa de performance da query entre os ambientes, use as opções:

    set STATISTICS IO ON
    set STATISTICS TIME ON

    Vai conseguir um retorno melhor relacionado ao tempo de execução da CPU, tempo total e leitura das páginas por tabela.



    Att, Bruno Silva.

    quinta-feira, 6 de novembro de 2014 13:16
  • Deleted
    quinta-feira, 6 de novembro de 2014 13:39
  • Osvaldo,

    Como você disse que em ambos os ambientes você possui os mesmos índices e estatísticas, pode ocorrer impacto na performance pela maior fragmentação no ambiente de Produção.

    De qualquer modo, antes de atualizar as estatísticas ou reorganizar os índices seria interessante você comparar se não há diferenças nas estruturas de alocação dos dados destes índices em cada ambiente (verifique o espaço definido no FILLFACTOR, se os índices estão nos mesmos FILEGROUPs, se estes índices utilizam o TEMPDB, ...).

    Também é importante verificar se o hint que você está utilizando no ambiente de Produção é o mais adequado, afinal mesmo tento um volume de dados semelhante, a concorrência de acessos às informações desta mesma tabela é certamente muito maior em Produção, então poderá ocorrer o "LOCK" para toda ou para uma parte dos dados que esta sua consulta utiliza.

    Outro ponto à ser verificado é que o Plano de Execução desta consulta (ou de outra relacionada) pode estar mantendo o seu CACHE desatualizado. Você poderá forçar uma atualização removendo todos CACHEs dos Planos de Execução deste banco ou apenas o referente à esta consulta, utilizando o comando "FREEPROCCACHE".

    Veja um exemplo abaixo:

    USE SeuBanco
    GO
    
    --APAGA TODO CACHE NO BANCO DE DADOS
    DBCC FREEPROCCACHE WITH NO_INFOMSGS;
    GO

    Veja outros modelos de uso em:

    http://technet.microsoft.com/pt-br/library/ms174283(v=sql.105).aspx

    Faça os ajustes necessários em um horário alternativo para minimizar o impacto na utilização de seus usuários. Antes de aplicar qualquer alteração, também é importante que você realize um BACKUP FULL deste seu banco de dados.

    Para maiores informações veja:

    http://technet.microsoft.com/pt-br/library/ms187348(v=sql.110).aspx

    http://msdn.microsoft.com/pt-br/library/ms189858.aspx

    http://technet.microsoft.com/pt-br/library/ms181714(v=sql.110).aspx

    http://technet.microsoft.com/pt-br/library/ms189122(v=sql.105).aspx


    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 6 de novembro de 2014 16:40
    Moderador