Leistungsprobleme bei DAM-Asset-Abfragen, die durch Durchlaufwarnungen und ineffiziente Indexnutzung verursacht werden

Letzte Aktualisierung: 15. Juli 2026

Adobe Experience Manager (AEM) DAM-Asset-Abfragen werden langsam, verzögern die Zeit oder schlagen fehl, wenn große Ergebnismengen, nicht unterstützte Abfragesyntax, ineffiziente Indexauswahl oder unzureichende Abfragefilter zu übermäßigem Durchlaufen der Knoten führen. Das Problem betrifft Query Builder-Abfragen, SQL2-Abfragen, Planungsaufträge, API-Endpunkte und die DAM-Asset-Suchleistung. Um das Problem zu beheben, optimieren Sie Abfragen, verbessern Sie die Indizierung und reduzieren Sie Durchläufe.

Beschreibung description

Umgebung

Adobe Experience Manager as a Cloud Service (AEMaaCS)

Problem/Symptome

Zeitüberschreitung bei Abfragen oder Rückgabe von Warnhinweisen*„Index zu viele Knoten durchlaufen“*.
SQL2-Abfragen schlagen mit Analysefehlern fehl, da Oak die nicht unterstützte LIMIT-Syntax transformiert. Beispielsweise wird LIMIT 1 zu LIMIT(*)1, was zu einer ParseException führt.
Query Builder-Endpunkte geben Antworten auf Dienstausfälle zurück, wenn große DAM-Pfade einen starken Trigger verursachen.
Die Ausgabe „Abfrage erläutern“ zeigt keine Indexnutzung an und Verwendete Indizes: keine.
Abfragen für große DAM-Pfade, z. B. /content/dam/..., dauern bei Verwendung von p.limit=-1 Hunderte von Sekunden oder hängen ab.

Grundursache

Das Problem tritt auf, weil große DAM-Abfragen ohne ausreichende Filter Oak zwingen, eine übermäßige Anzahl von Knoten zu scannen. Nicht unterstützte SQL2 LIMIT/OFFSET-Syntax, ineffektive Indexauswahl, nicht unterstützte Bedingungen wie IS NULL und ungebundene Ergebnismengen verhindern eine effiziente Indexnutzung. Große Ordnerhierarchien können auch zu HTTP-Timeouts, Ressourcenerschöpfung und Durchlaufwarnungen führen, wenn Abfragen nicht optimiert sind.

Lösung resolution

Führen Sie die folgenden Schritte aus, um das Abfrageproblem zu identifizieren und die DAM-Abfrageleistung zu verbessern:

Identifizieren Sie den Typ des Abfragefehlers, indem Sie die Protokolle, die Ergebnisse des Query Builder-Debuggers und die Ausgabe der Abfrageleistung überprüfen und die Abfrageergebnisse erklären.
Verringern Sie große Ergebnismengen, indem Sie p.limit=-1 durch eine vernünftige Beschränkung ersetzen und den Abfragebereich bei der Abfrage großer DAM-Hierarchien reduzieren.
Ersetzen Sie die nicht unterstützte SQL2 LIMIT/OFFSET-Syntax durch eine unterstützte Syntax wie OPTION(LIMIT 1) und verwenden Sie bei Bedarf die Paginierung im Query Builder.
Überprüfen Sie „Abfrageausgabe erläutern“ und stellen Sie sicher, dass die Abfrage den erwarteten DAM-Index anstelle von Fallback-Indizes verwendet.
Erzwingen Sie das entsprechende Index-Tag, wenn „Abfrage erläutern“ eine falsche Indexauswahl anzeigt. Fügen Sie bei Bedarf beispielsweise option(index tag assetsOmnisearch) hinzu.
Entfernen oder restrukturieren Sie IS NULL-Bedingungen, die die Indexnutzung verhindern und das Durchlaufen erzwingen.
Aufspaltung von Abfragen in kleinere Unterabfragen, wenn die DAM-Hierarchie sehr große Ordnerstrukturen enthält. Teilen Sie beispielsweise Abfragen nach Unterordnern auf, anstatt einen einzelnen Pfad mit Zehntausenden von Assets abzufragen.
Fügen Sie zusätzliche Metadatenfilter wie Datum, Ressourcentyp oder andere indizierte Eigenschaften hinzu, um die Anzahl der gescannten Knoten zu reduzieren und die Indexeignung zu verbessern.
Validieren Sie die Auflösung, indem Sie die Abfrage erneut ausführen, die Abfrageausgabe überprüfen, die korrekte Indexverwendung bestätigen und sicherstellen, dass keine Durchlaufwarnungen und Zeitüberschreitungen mehr auftreten.

Wann eskalieren

Durchlaufwarnungen werden nach Anwenden von Abfragebeschränkungen und Filtern fortgesetzt.
Explain Query zeigt nach der Abfrageoptimierung weiterhin keine Indexnutzung an.
Die unterstützte SQL2-Syntax schlägt nach der Korrektur der Abfrage weiterhin fehl.
Query Builder-Endpunkte geben nach der Optimierung und Indexvalidierung weiterhin Service-Ausfallfehler zurück.