Melhorando a Performance de Consultas no Totvs Protheus – Parte 9
Fala Pessoal,
Esse post está há tanto tempo no rascunho do meu Blog que até o nome da empresa na foto está antigo. Vou manter assim mesmo.
Estamos de volta com mais um episódio da série de análise de queries de ambientes Totvs Protheus.
Antes de lerem esse post, caso ainda não tenham lido os anteriores, sugiro que façam:
- https://www.fabriciolima.net/blog/2017/12/11/melhorando-a-performance-de-consultas-no-totvs-protheus-parte-1/
- https://www.fabriciolima.net/blog/2017/12/18/melhorando-a-performance-de-consultas-no-totvs-protheus-parte-2/
- https://www.fabriciolima.net/blog/2018/01/08/melhorando-a-performance-de-consultas-no-totvs-protheus-parte-3/
- https://www.fabriciolima.net/blog/2018/01/16/melhorando-a-performance-de-consultas-no-totvs-protheus-parte-4/
- https://www.fabriciolima.net/blog/2018/01/23/melhorando-a-performance-de-consultas-no-totvs-protheus-parte-5/
- https://www.fabriciolima.net/blog/2018/01/30/melhorando-a-performance-de-consultas-no-totvs-protheus-parte-6/
- https://www.fabriciolima.net/blog/2018/02/07/melhorando-a-performance-de-consultas-no-totvs-protheus-parte-7/
- Melhorando a Performance de Consultas no Totvs Protheus – Parte 8
Nesse post vamos analisar uma query com código simples, mas que foi executada mais de 13 mil vezes em 5 dias em um cliente.
Ela também retornava 27 milhões de linhas para a aplicação (tamanho da tabela). Esse tipo de query é bem comum no Protheus:
1 |
SELECT R_E_C_N_O_ FROM dbo.CTK010 WHERE D_E_L_E_T_ = ' ' ORDER BY CTK_FILIAL,CTK_SEQUEN,R_E_C_N_O_ |
Olhando o plano dela, da para ver que o maior custo da query é o Sort :
Nesse caso o Sort é devido ao order by da query:
1 |
ORDER BY CTK_FILIAL,CTK_SEQUEN,R_E_C_N_O_ |
Colunas chaves do índice utilizado: D_E_L_E_T_, CTK_FILIAL
Colunas no include: CTK_SEQUEN, R_E_C_N_O_
O INCLUDE não tem as colunas ordenadas. Assim, o SQL, depois de fazer um seek no índice, ainda tem que ordenar o resultado e isso é muito custoso para 27 milhões de linhas.
E se eu colocar todas essas colunas no índice para que fiquem ordenadas???
Vamos tentar:
1 2 |
create nonclustered index CTK010W01 on CTK010(D_E_L_E_T_, CTK_FILIAL,CTK_SEQUEN, R_E_C_N_O_) with(FILLFACTOR=90) |
Olha como ficaram os planos das queries com o índice antigo e o índice novo:
Deu certo. A operação de SORT morreu.
Segue abaixo o consumo de CPU antes e depois:
1 2 3 4 5 6 7 |
Antes: SQL Server Execution Times: CPU time = 171163 ms, elapsed time = 73272 ms. Depois: SQL Server Execution Times: CPU time = 10873 ms, elapsed time = 11414 ms. |
O SQL gastava 171 segundos nos cores de CPU processando essa query e agora com esse novo índice fica apenas 10 segundos.
Agora imagina isso sendo executado 2.500 vezes por dia?
De nada em CPU!!! =)
Claro que o cliente vai validar o motivo dessa execução com essa frequência toda, mas até ele descobrir e solucionar, a CPU já me mandou um obrigado e pagou meu almoço, porque ela vai trabalhar muito menos.
Gostou dessa dica?
Publiquei um curso com 11 horas de duração que tem mais 9 queries como essa sendo analisadas e muito mais dicas de performance:
Curso: Melhorando a Performance de Consultas no Totvs Protheus
Também gravei uma aula grátis com 60 minutos de duração sobre o que você deve aprender para melhorar a performance no Protheus:
Curta, comente, compartilhe…
Curta nossa página no Facebook , LinkedIn e Instagram para receber Dicas de Leituras, Vídeos 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
RECNO É A COLUNA DE “ID” do protheus, toda tabela deles tem essa coluna.
Provavelmente tem um processo rodando a x tempos pra listar todos os recnos e executar uma tarefa em ordem pelo clustered que geralmente é o recno.
Se por acaso esse tabela for uma tabela que entra e sai dados, ok, se for uma tabela onde so se incrementa mais dados, a poderia ser melhorada utilizando um identificador para o último recno ja processado ou algo assim, pra evitar ler e trazer sempre tudo.
Obrigado pela resposta.
Realmente não lembro o que o cliente fez, mas mandei para ele resolver lá.
Imagina o dia que essa tabela terá 500 milhões de linhas?
Não tem como ficar rodando essa query toda hora.