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:
- 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”
- 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:
- 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!
- 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.
- 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.
- 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 agora, e tenha a melhor solução de TI para sua empresa.
Acompanhe a Tripletech nas redes sociais:
facebook twitter linkedin instagram
