Análise e solução problema de performance em banco de dados – Cliente Logística

No ambiente de tecnologia e desenvolvimento, problemas de desempenho podem surgir de maneira inesperada, impactando não apenas os resultados internos, mas também a experiência de parceiros e clientes externos.

Recentemente, a Tripletech se deparou com um desafio desse tipo ao atender um cliente do setor logístico.

O objetivo deste artigo é relatar essa experiência e destacar a abordagem adotada para resolver o problema de desempenho, utilizando a análise do operador Key Lookup.

O cliente, uma grande empresa do segmento de logística, começou a enfrentar uma queda contínua no desempenho de sua plataforma.

O banco de dados SQL apresentou uma degradação significativa, resultando em lentidão nas consultas e na exibição das informações nos dashboards. Surpreendentemente, não havia ocorrido nenhuma alteração recente no ambiente do banco de dados que pudesse explicar essa degradação.

Inicialmente, a equipe internet de infraestrutura foi mobilizada para realizar uma análise preliminar do sistema. No entanto, essa análise não revelou nenhuma anomalia aparente. Diante da persistência do problema, a Tripletech foi acionada para uma análise mais profunda, concentrando-se no banco de dados SQL Server.

Análise e Solução

Através de um minucioso processo de análise, a equipe da Tripletech identificou que uma query mal otimizada estava impactando negativamente o servidor do banco de dados. Essa degradação se tornou notável à medida que a base de dados cresceu, amplificando a falta de otimização na consulta. Ficou evidente que a saúde geral do sistema estava comprometida devido a essa query.

Uma análise técnica detalhada foi realizada pelo especialista da Tripletech, Getúlio Torres, abaixo conheça um pouco mais sobre a análise.

 

Operador Key Lookup: Entendendo o Cenário

O Key Lookup é um operador que dificilmente não iremos nós deparar em alguma análise em planos de execução. O papel principal desse operador é retornar dados que não estão sendo associados ao índice que está sendo utilizado em operadores Seek (alguma vezes Scan…).

Em nossos “Cases”, sempre nos preocupamos em eliminá-lo de uma forma positiva para todo o ambiente sem sobrecarregar nenhum outro recurso, tentando diminuir o número de leituras consideradas excessivas, já que existem formas para evitá-lo ou diminuir a frequência.

Vários artigos (99%) recomendam que sejam criados índices de cobertura (Covering Index) para solucionar quaisquer problemas, mas as vezes isso não seria a melhor escolha já que podemos ter um cenário que a necessidade de incluir várias colunas ou colunas muito grandes gere um “overhead” nas transações associadas ao objeto em questão.

Sendo assim, quando inicio uma análise no plano de execução e me deparo com “Key Lookup”, sigo alguns passos:

  1. Informações do operador
  • Número de execuções: Quanto maior esse valor, mais custoso esse operador deverá ser para o plano de execução;
  • Predicados: Significa que algum predicado na clausula “Where” faz parte desse operador
  • Lista de Saída: As colunas selecionadas no “Select”
  1. Avaliar o Objeto
  • Verificar como o objeto está sendo relacionado na consulta
  • Quais índices estão disponíveis
  • Quantidade de linhas

A partir dessas informações e o custo do operador em relação ao total o plano de execução, início uma bateria de testes para definir qual a melhor opção que será utilizada para eliminá-lo ou diminuir sua execução. Dessa forma, teremos as seguintes recomendações a seguir: 

  1. Criar um índice de cobertura (Covering Index);

 A execução dessa atividade, eliminará o operador “Key Lookup”

Obs.: Conforme já alertado, adotar essa ação requer alguns cuidados!

  1. Criar um índice com as colunas chamadas “Key Columns”

A execução dessa atividade, diminuirá a frequência de execuções, mas não eliminará o operador, sendo uma solução aceitável para poucas linhas, caso contrário não trará os benefícios esperados.

  1. Reescrever o código, de uma forma que consiga satisfazer o plano de execução sem o uso do operador “Key Loolup”

Para adoção dessa solução, se faz necessário obter um conhecimento dos dados do cliente.

  1. Caso tenha índices que possa atender a lista de saída(outputlist) e os predicados, duplicar o objeto(tabela) direcionando o conjunto de colunas para as respectivas tabelas “duplicadas”

Para realizar essa manobra, é necessário realizar uma análise profunda para entender quais índices poderiam satisfazer cada grupo de colunas.

Segue abaixo alguns exemplos, para demonstrar os cenários descritos acima.

1 – Plano de Execução “Original

2 – Plano de Execução índice de “Cobertura

3 – Plano de Execução com índice “Key Columns

4 – Plano de Execução com tabelas “Duplicadas

  • Sua empresa busca melhorar a performance de seu banco de dados SQL Server ?
  • Precisa de uma análise mais detalhada em seu banco de dados ?

Para obter mais informações e soluções relacionadas a desempenho de sistemas e otimização de bancos de dados, a equipe da Tripletech está à disposição para auxiliar e compartilhar seu conhecimento técnico.

Fale com um especialista

Fale com um especialista agora, e tenha a melhor solução de TI para sua empresa.

Acompanhe a Tripletech nas redes sociais: