AGUARDE... CARREGANDO...

Melhorando a Performance de Consultas no Totvs Protheus – Parte 7

Fala pessoal,

Como tudo que é bom dura, pouco, esse é o último episódio da nossa série de artigos de Tuning de consultas no Totvs Protheus.

Lembrando que essas dicas valem para queries de outros sistemas também.

Antes de lerem esse post, caso ainda não tenham lido os anteriores, sugiro que façam para seguirem a linha de raciocínio:

Analisando mais umas das queries que demoram mais de 3 segundos em um cliente:

Esse Worktable nos mostra que essa query está utilizando muito tempdb:

Olhando o plano de execução também podemos ver essa informação:

Quando virem um operador com “Spool” no nome, já visualizem que sua query está armazenando dados no tempdb para reutilizar esses dados posteriormente nesse plano.

Quando verem uma seta grande, significa que muito dado está sendo trafegado por ali.

Ou seja, pelo SET STATISTICS IO eu já tinha visto que o SQL estava usando o tempdb devido a quantidade de reads no Worktable. Eu abro o plano e vejo um Spool com uma seta desse tamanho.

Tenho que tentar ver algo nessa tabela RD0010 que está envolvida nessa bagunça toda.

Sem essa análise acima, nosso primeiro pensamento seria ir direto na tabela RC1480 que é utilizada pelo WHERE e criar um índice pela coluna abaixo:

Contudo, não vou fazer isso. Vamos seguir na linha do tempdb primeiro.

Procurando a tabela RD0010 na query, vemos que um join é realizado com ela:

Não existe índice nessa coluna RD0_CODIGO. Se eu criar, será que vai ajudar?

Vamos tentar…

Criando o índice:

Rodando a query novamente…. WOW!!!!

Milagrosamente sumiu aquele número gigante de leituras no tempdb:

Muito bom Fabrício, mas ainda tem uma tabela fazendo mais 23 mil reads ai, não consegue resolver ela também?

Está bem… Vamos aproveitar a viagem e ver ela também .

Seguindo a mesma ideia da tabela anterior, criamos o índice abaixo pensando no join com essa tabela SA2010:

Rodando a query novamente, agora baixamos para 3 leituras de páginas também na SA2:

Colocando um waitfor delay na execução da query conseguimos visualizar no log de queries demoradas:

Ela rodou em 0,11 segundos e a diferença de leituras de páginas (691 mil para 2mil) e do consumo de CPU (2 mil para 100) é considerável!!!

É isso ai pessoal, melhoramos mais uma query no Protheus.

Com isso, encerramos essa série de Posts sobre Melhoria de Performance de Consultas Totvs.

A não Fabrício!!! Sério???

Sério…

Espero que tenha contribuído de alguma forma no seu aprendizado.

Gostou desse Post?

Curta, comente, compartilhe com os coleguinhas…

Assine meu canal no Youtube e curta minha Página no Facebook para receber Dicas de Leituras e Eventos sobre SQL Server.

Abraços,

Fabrício Lima

Microsoft Data Platform MVP

Consultor e Instrutor SQL Server

Trabalha com SQL Server desde 2006

Deixe uma resposta

%d blogueiros gostam disto: