SQL Server Developer Center >
Fóruns do SQL Server
>
SQL Server - Desenvolvimento Geral
>
Update Statistics gerou plano errado
Update Statistics gerou plano errado
- E aí pessoal!!Bom, passei por um problema no mínimo incomum.Hoje, num cliente, após ser executado um sp_updatestats (é um job que roda todos dias), um plano de execução ficou completamente torto. Originalmente levava cerca de 8 segundos pra executar a consulta, passou a levar mais de 3 minutos!! Além de que o processamento ficou lacrado em 100%... e começou a dar Timeouts... resumindo... foi uma caca das grandes... Tudo isso por que a consulta é executada milhares de vezes por minuto. E com um plano de execução errado.... já viu o que resultado né...Bom, só voltou ao normal depois q eu atualizei na mão a estatística, após ter descoberto qual a query e qual tabela estavam com problema.Alguém já pegou um caso destes?? De um update stats ferrar com algum plano de execução dessa forma??Abraço a todos!!
Classifiquem as respostas. O Fórum agradece!!
Todas as Respostas
- Alexandre o fato do processador ficar em 100% durante algumas operações é um comportamento que pode ser normal em plataformas intel, existem diversos fatores que devems er analisados. Esse comportamento pode acontecer para usar todo o recurso disponivel e executar a operação o mais rapido possível, isso caso o processador esta idle.
O que não pode é o processador travar em 100% e não descer mais., porém toda essa análise depende de seu baseline.
Já referente a mudança do plano de execução se foi o que entendi, o SQL pode sim se suas estatisticas estiverem MUITO desatualizadas, ao atualiza-las mudar alguns planos de execução.
ITILF | MCP | MCTS | MCITP SQL Server 2005 & 2008. http://www.bydocs.com - Cleyton,Vou detalhar mais o caso. O normal desse servidor é ficar com processamento entre 30 e 40%. O sp_updatestats é executado todas madrugadas. Além disso estão ativados Auto Create Stats, Auto Update e Auto Update Asynch, então, com certeza as estatísticas não estavam desatualizadas.Essa query é a mais executada no banco. Quando aconteceu o sp_updatestats, o plano de execução da consulta mudou, passando para um plano completamente errado. Só de olhar para o plano já dava pra ver que estava errado.Bastou executar um UPDATE STATISTICS na referida tabela que tudo voltou ao normal, ou seja, voltou o plano de execução que estava antes do sp_updatestats.Abraço!!
Classifiquem as respostas. O Fórum agradece!! - Alexandre,
Tudo bom velho amigo!!!!
Para acaso este banco de dados que você esta utilizando é um banco migrado de alguma versão para o outra?
Por exemplo um banco nível 80 migrado para o 2005 ou 2008?
Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA - E aí Junior!!
Td tranquilo... tirando esse probleminha que está me preocupando...Olha, essa base foi migrada de SQL 2000, mas faz mais de 1 ano!! Então, não pode ser o caso de estatísticas desatualizadas ou baseadas em 80. O case das estatísticas em migrações conheço faz um bom tempo, mas não se enquadra a essa situação.Abraço!!!!
Classifiquem as respostas. O Fórum agradece!! - Alexandre a mudança no plano está relacionada a alterações entre utilização de hash e merge join?
ITILF | MCP | MCTS | MCITP SQL Server 2005 & 2008. http://www.bydocs.com - Cleyton,Não. Ele simplesmente mudou a tabela de entrada da consulta e também o índice utilizado para a tal tabela. Ao invés de iniciar pela tabela que tem o parâmetro no WHERE, ele começou pela outra, que faz JOIN. Como resultado, ao invés de trabalhar sobre um apenas alguns registros, ele passou a trabalhar sobre cerca de 44 milhões de registros, para depois fazer um "Filter".Assim, só de olhar pro plano de execução tu já vê que tem muita coisa errada.Abraço!!
Classifiquem as respostas. O Fórum agradece!! - Alexandre eu tive um caso parecido com esse utilizando a versão 2005 enterprise 64bits.
Onde o banco também está setado para atualizar estatisticas automaticamente.
No meu caso foi criado um indice IDX1 para uma nova necessidade, onde o sql deveria realizar um seek no indice covered, porém ele fazia scan no clusterizado, e utilizava hash join.
realizando alguns testes criei outro indice IDX2 que não era o mais ideal para a consulta nao era covered, ai minha surpesa, o SQL deixou de fazer o scan no clusterizado não usou o IDX2 e começou a fazer SEEK no indice correto IDX1 utilizando o merge join. ahei um comportamento meio estranho.
Continuando os testes, apaguei o IDX2 e ele vou a fazer o scan no clusterizado com hash join, recriei o IDX2 e ele voltou a fazer seek no idx1 com merge join.
onde entrou as estatisticas?
Eu apaguei o IDX2 novamente, e voltou a fazer scan. O proximo passo foi atualizar a estatistica da tabela. Após atualizar as estatisticas e apagar o IDX2 ele voltou a fazer o seek no IDX1 com merge join e apartir dai voltou ao normal.
Ainda estou estudando o caso, pode ser varias causas, cache, estatisticas, apesar de atualizar automaticamente, fases de compilação entre outros.
não consegui comprovar ainda qual a relação do IDX2 com o plano de execução, Porque quando eu criava o idx2 ele usava corretamente o idx1 e quando eu apagava o idx2 ele não usava o idx1 se era a melhor escolha para a query. Ainda estou estudando o caso.
ITILF | MCP | MCTS | MCITP SQL Server 2005 & 2008. http://www.bydocs.com - Chefia, estou tentanto entender o que aconteceu... me diga uma coisa... é uma proc? function?... view? é um Ad-Hoc?... qq é?
Outra coisa... consegue me dizer se a consulta esta parametrizada?... da uma olhada nas dmvs pra ver se o plano esta sendo reutilizado...
Outra coisa, quando você atualizou a estatistica novamente, utilizou o UPDATE STATISTICS com FULLSCAN ou não especificou nada?....
Abraço....
Fabiano Neves Amorim - MCTS / MCP - SQLServer - http://fabianosqlserver.spaces.live.com/ - E aí Fabiano!Nesse caso era uma consulta parametrizada, mas o plano não estava sendo reutilizado, devido a forma como ela esta sendo executada.E quando atualizei, utilizei apenas o UPDATE STATISTICS, sem qualquer parâmetro, ou seja, exatamente o que o sp_updatestats faz. Por isso que achei mais estranho. Está cheirando a bug. Em outros bancos, como Oracle, isso é muito comum, tanto que nele se usa muito as HINTS de consulta. Neste caso específico, passamos como a solução para o cliente, para evitar que a situação se repita.Nós vamos tentar reproduzir o problema num ambiente paralelo, não sei se vamos conseguir fazer com que se chegue ao mesmo resultado.Abraço!!
Classifiquem as respostas. O Fórum agradece!! - Alexandre,
Este banco de dados que você estava utilizando foi migrado de alguma versão anterior do SQL Server?
Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA - Junior,Já havia informado isso na sexta:
E aí Junior!!
Td tranquilo... tirando esse probleminha que está me preocupando...Olha, essa base foi migrada de SQL 2000, mas faz mais de 1 ano!! Então, não pode ser o caso de estatísticas desatualizadas ou baseadas em 80. O case das estatísticas em migrações conheço faz um bom tempo, mas não se enquadra a essa situação.Abraço!!!!
Classifiquem as respostas. O Fórum agradece!!Abraço
Classifiquem as respostas. O Fórum agradece!! - Entendi,
É cara realmente está bem estranho, também não duvido que seja algum bug.
Mas tenho 2 perguntas.
Primeiro, consegue passar algum parâmetro que irá fazer com que o SQL crie um plano igual ao que estava antes, o ruim? Ou seja, consegue simular o plano ruim?...
Segundo, O Filtro esta sendo feito utilizando um índice cluster ou nonclustered?
Outra... só por curiosidade... se a consulta está parametrizada, como assim ele não está reutilizando o plano devido a forma que está sendo executada?
Abraço.
Fabiano Neves Amorim - MCTS / MCP - SQLServer - http://fabianosqlserver.spaces.live.com/ - Alexandre,
Me desculpe, eu esqueci!!!!
Mas o que esta me chamando a atenção era justamente isso, foi justamente isso, por acaso você não realizou a migração do nível de compatibilidade?
Somente fez a atualização das estatísticas? Mas como esta o nível de fragmentação das suas tabelas?
Qual é o valor definido no Fill-Factor?
Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA - Fabiano,Tenho como reproduzir sim, só preciso passar algumas HINTS, fácil, fácil... Além disso deixei o plano ruim salvo... sempre é bom guardar.E, o filtro está sendo feito sobre um nonclustered.Cara... sobre a não reutilização... tem gente que consegue fazer as coisas da forma mais difícil/complicada/errada... Estavam passando as informações do filtro (WHERE) bem direitinho via parâmetros... só que, nas colunas era realizado um cálculo, e o valor usado para o cálculo era dinâmico, passado explicitamente pela aplicação. Resumindo, uma baita M...Bom, de qualquer forma, já estamos considerando como sendo Bug mesmo... pq isso não é nada normal. O problema é que eu pelo menos nunca tinha passado por uma situação dessas. E nem sequer achamos qualquer outro artigo na internet que falasse sobre isso.Mas, valeu a atenção aí....Grande abraço!!
Classifiquem as respostas. O Fórum agradece!!
