Problemas de desempenho de consulta de ativos do DAM causados por avisos de passagem e uso ineficiente do índice

As consultas de ativos do Adobe Experience Manager (AEM) DAM tornam-se lentas, expiram ou falham quando conjuntos de resultados grandes, sintaxe de consulta não compatível, seleção de índice ineficiente ou filtros de consulta insuficientes causam passagem excessiva de nó. O problema afeta consultas do Construtor de consultas, consultas do SQL2, trabalhos do agendador, pontos de extremidade da API e desempenho da pesquisa de ativos do DAM. Para resolver o problema, otimize as consultas, melhore a indexação e reduza o percurso.

Descrição description

Ambiente

Adobe Experience Manager as a Cloud Service (AEMaaCS)

Problema/Sintomas

  • As consultas atingiram o tempo limite ou retornam* avisos “Índice atravessou muitos nós”*.
  • As consultas SQL2 falham com erros de análise porque o Oak transforma a sintaxe LIMIT sem suporte. Por exemplo, LIMIT 1 torna-se LIMIT(*)1, resultando em uma ParseException.
  • Os pontos de extremidade do Construtor de consultas retornam respostas de Interrupção do serviço quando caminhos DAM grandes acionam travessia intensa.
  • A saída Explicar Consulta não mostra uso de índice e exibe Índices usados: nenhum.
  • As consultas em caminhos DAM grandes, como /content/dam/..., levam centenas de segundos ou travam quando p.limit=-1 é usado.

Causa raiz

O problema ocorre porque grandes consultas do DAM sem filtros adequados forçam o Oak a verificar números excessivos de nós. Sintaxe SQL2 LIMIT/OFFSET sem suporte, seleção de índice ineficaz, condições sem suporte, como IS NULL, e conjuntos de resultados não associados impedem o uso eficiente do índice. Hierarquias de pastas grandes também podem causar tempos limite de HTTP, esgotamento de recursos e avisos de passagem quando as consultas não são otimizadas.

Resolução resolution

Siga estas etapas para identificar o problema da consulta e melhorar o desempenho da consulta do DAM:

  1. Identifique o tipo de falha da consulta revisando logs, resultados do Depurador do Construtor de Consultas, saída do Desempenho da Consulta e resultados da Consulta de Explicação.
  2. Reduza grandes conjuntos de resultados substituindo p.limit=-1 por um limite razoável e reduzindo o escopo da consulta ao consultar grandes hierarquias do DAM.
  3. Substitua a sintaxe SQL2 LIMIT/OFFSET sem suporte pela sintaxe com suporte, como OPTION(LIMIT 1), e use a paginação do Construtor de Consultas quando necessário.
  4. Revise a saída Explicar consulta e verifique se a consulta usa o índice DAM esperado em vez de índices de fallback.
  5. Imponha a tag de índice apropriada quando Explicar consulta mostrar seleção de índice incorreta. Por exemplo, adicione option(index tag assetsOmnisearch) quando necessário.
  6. Remova ou reestruture as condições IS NULL que impedem o uso do índice e forçam a passagem.
  7. Dividir as consultas em subconsultas menores quando a hierarquia do DAM contiver estruturas de pastas muito grandes. Por exemplo, divida as consultas por subpasta em vez de consultar um único caminho que contém dezenas de milhares de ativos.
  8. Adicione filtros de metadados adicionais, como data, tipo de recurso ou outras propriedades indexadas, para reduzir o número de nós digitalizados e melhorar a qualificação de índice.
  9. Valide a resolução executando novamente a consulta, revisando a saída Explicar consulta, confirmando o uso correto do índice e garantindo que avisos de passagem e tempos limite não ocorram mais.

Quando escalonar

  • Os avisos transversais continuam após a aplicação dos limites e filtros de consulta.
  • Explicar que a consulta continua a não mostrar uso de índice após a otimização da consulta.
  • A sintaxe SQL2 suportada ainda falha após a correção da consulta.
  • Os endpoints do Construtor de consultas continuam retornando erros de Interrupção do Serviço após a otimização e a validação do índice.

Leitura relacionada

recommendation-more-help
experience-cloud-kcs-help-kbarticles