Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im [Blog-Posting](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Analysieren des Abfragezusammenfassung
Wenn Sie die Ausführungsschritte und die Statistik etwas detaillierter benötigen als in dem Abfrageplan, den [EXPLAIN](r_EXPLAIN.md) ausgibt, verwenden Sie die Systemansichten [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) und [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md).
SVL\$1QUERY\$1SUMMARY zeigt Abfragestatistiken für die Stream an. Sie können die ausgegebenen Informationen verwenden, um Probleme in Zusammenhang mit besonders kostenintensiven Schritten, Schritten mit besonders langer Ausführungszeit und Schritten, bei denen Daten auf den Datenträger geschrieben werden, zu identifizieren.
Die Systemansicht SVL\$1QUERY\$1REPORT zeigt Informationen ähnlich denen von SVL\$1QUERY\$1SUMMARY an, allerdings nicht nach Streams angeordnet, sondern nach den Slices auf den Verarbeitungsknoten. Sie können diese Informationen auf Slice-Ebene verwenden, um eine ungleichmäßige Datenverteilung in dem Cluster zu erkennen (eine „verzerrte“ Datenverteilung). Eine verzerrte Datenverteilung zwingt einige Knoten dazu, mehr Arbeit zu verrichten als andere, was die Abfrageleistung beeinträchtigt.
**Topics**
+ [Verwenden der Ansicht SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md)
+ [Verwenden der Ansicht SVL\$1QUERY\$1REPORT](using-SVL-Query-Report.md)
+ [Zuweisung der Informationen in Abfrageplan und Abfragezusammenfassung](query-plan-summary-map.md)
# Verwenden der Ansicht SVL\$1QUERY\$1SUMMARY
Gehen Sie wie folgt vor, um mit [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) eine Abfragezusammenfassung nach Streams zu analysieren:
1. Führen Sie die folgende Abfrage aus, um die Abfrage-ID anzuzeigen:
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Untersuchen Sie den Abfrageausschnitt im Feld `substring`, um herauszufinden, welcher `query`-Wert Ihrer Abfrage entspricht. Wenn Sie die Abfrage mehrmals ausgeführt haben, verwenden Sie den `query`-Wert aus der Zeile mit dem niedrigeren `elapsed`-Wert. Dies ist die Zeile für die kompilierte Version. Wenn Sie viele Abfragen ausgeführt haben, können Sie den in der LIMIT-Klausel verwendeten Wert heraufsetzen, um sicherzustellen, dass die Abfrage berücksichtigt wird.
1. Wählen Sie Zeilen aus SVL\$1QUERY\$1SUMMARY für Ihre Abfrage aus. Ordnen Sie die Ergebnisse nach Stream, Segment und Schritt an:
```
select * from svl_query_summary where query = MyQueryID order by stm, seg, step;
```
Nachfolgend sehen Sie ein Beispielergebnis.
![\[Ein Beispielergebnis für Zeilen in SVL_QUERY_SUMMARY, die einer bestimmten Abfrage entsprechen.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/svl_query_summary_results.png)
1. Ordnen Sie die Schritte und die Operationen in dem Abfrageplan einander zu. Verwenden Sie dabei die Informationen in [Zuweisung der Informationen in Abfrageplan und Abfragezusammenfassung](query-plan-summary-map.md). Zusammengehörige Elemente sollten näherungsweise die gleichen Werte für Zeilen und Bytes (jeweils Zeilen \$1 Breite aus dem Abfrageplan) haben. Falls sich hier unerwartete Abweichungen ergeben, finden Sie empfohlene Lösungen unter [Die Tabellenstatistik fehlt oder ist veraltet.](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date).
1. Überprüfen Sie, ob das Feld `is_diskbased` für einen Schritt den Wert `t` (true) hat. Hashes, Aggregat- und Sortierfunktionen sind Operatoren, die mit hoher Wahrscheinlichkeit Daten auf den Datenträger schreiben, falls das System nicht genügend Arbeitsspeicher für die Verarbeitung der Abfrage zugeteilt hat.
Falls `is_diskbased` wahr ist, finden Sie empfohlene Lösungen unter [Ungenügende Speicherzuteilung für die Abfrage](query-performance-improvement-opportunities.md#insufficient-memory-allocated-to-the-query).
1. Überprüfen Sie die `label` Feldwerte und prüfen Sie, ob es irgendwo in den Schritten eine AGG-DIST-AGG Reihenfolge gibt. Eine solche Konstellation weist auf eine Aggregierung in zwei Schritten hin, die kostenintensiv ist. Sie können dieses Problem beheben, indem Sie die GROUP BY-Klausel so ändern, dass der Verteilungsschlüssel verwendet wird (bei mehreren der erste).
1. Überprüfen Sie für jedes Segment den Wert von `maxtime` (ist für alle Schritte in einem Segment gleich). Identifizieren Sie das Segment mit dem höchsten `maxtime`-Wert und durchsuchen Sie die Schritte in diesem Segment nach den folgenden Operatoren.
**Anmerkung**
Ein hoher `maxtime`-Wert muss nicht zwangsläufig ein Problem bei dem Segment bedeuten. Auch Segmente, bei denen dieser Wert hoch ist, können schnell verarbeitet worden sein. Die Zeitmessung wird für alle Segmente in einem Stream gleichzeitig gestartet. Einige nachgelagerte Segmente können aber erst dann ausgeführt werden, wenn Daten aus vorangehenden Segmenten abrufbar sind. Dies führt dazu, dass offenbar viel Zeit benötigt wird, weil der `maxtime`-Wert die Warte- und die Verarbeitungszeit beinhaltet.
+ **BCAST oder DIST**: In diesen Fällen kann ein hoher Wert von `maxtime` aufgrund einer Umverteilung einer großen Anzahl an Zeilen zustande kommen. Empfohlene Lösungen finden Sie unter [Suboptimale Datenverteilung](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
+ **HJOIN (Hash-Join)**: Wenn der betreffende Schritt im Feld `rows` im Vergleich zum `rows`-Wert im abschließenden RETURN-Schritt in der Abfrage einen sehr großen Wert hat, finden Sie empfohlene Lösungen unter [Hash join](query-performance-improvement-opportunities.md#hash-join).
+ **SCAN/SORT**: Suchen Sie nach einer einem Join-Schritt vorausgehenden SCAN-SORT-SCAN-MERGE-Schrittfolge. Ein solches Muster weist darauf hin, dass unsortierte Daten gescannt, sortiert und dann mit dem sortierten Bereich der Tabelle zusammengeführt werden.
Überprüfen Sie, ob der Zeilenwert für den SCAN-Schritt im Vergleich zu dem Zeilenwert im abschließenden RETURN-Schritt in der Abfrage einen sehr großen Wert aufweist. Ein solches Muster weist darauf hin, dass die Ausführungs-Engine Zeilen scannt, die später verworfen werden, was ineffizient ist. Empfohlene Lösungen finden Sie unter [Nicht ausreichend restriktives Prädikat](query-performance-improvement-opportunities.md#insufficiently-restrictive-predicate).
Falls der `maxtime`-Wert für den SCAN-Schritt besonders hoch ist, finden Sie empfohlene Lösungen unter [Suboptimale WHERE-Klausel](query-performance-improvement-opportunities.md#suboptimal-WHERE-clause).
Falls der `rows`-Wert für den SORT-Schritt ungleich Null ist, finden Sie empfohlene Lösungen unter [Unsortierte oder falsch sortierte Zeilen](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows).
1. Überprüfen Sie die Werte für `rows` und `bytes` in den 5 bis 10 Schritten vor dem abschließenden RETURN-Schritt, um sich einen Eindruck davon zu verschaffen, welche Datenmengen an den Client zurückgegeben werden. Dies ist nicht immer ganz einfach.
In der folgenden Beispielabfragezusammenfassung sehen Sie beispielsweise, dass der dritte PROJECT-Schritt einen Wert für `rows`, aber nicht für `bytes` hat. Wenn Sie in den vorangehenden Schritten nach demselben `rows`-Wert suchen, finden Sie den SCAN-Schritt mit Zeilen- und Byteinformationen:
Im Folgenden sehen Sie ein Beispielergebnis.
![\[Eine Zeile in den Ergebnissen der Abfragezusammenfassung, bei der es sich um einen SCAN-Schritt mit Zeilen- und Byteinformationen handelt.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/rows_and_bytes.png)
Wenn die zurückgegebene Datenmenge unerwartet groß ist, finden Sie empfohlene Lösungen unter [Sehr große Ergebnismengen](query-performance-improvement-opportunities.md#very-large-result-set).
1. Überprüfen Sie, ob der Wert für `bytes` verglichen mit den `rows`-Werten für andere Schritte relativ hoch ist. Dieses Muster kann darauf hinweisen, dass eine große Anzahl an Spalten ausgewählt ist. Empfohlene Lösungen finden Sie unter [Große SELECT-Liste](query-performance-improvement-opportunities.md#large-SELECT-list).
# Verwenden der Ansicht SVL\$1QUERY\$1REPORT
Gehen Sie wie folgt vor, um mit [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md) eine Abfragezusammenfassung nach Slices zu analysieren:
1. Führen Sie die folgende Abfrage aus, um die Abfrage-ID anzuzeigen:
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Untersuchen Sie den Abfrageausschnitt im Feld `substring`, um herauszufinden, welcher `query`-Wert Ihrer Abfrage entspricht. Wenn Sie die Abfrage mehrmals ausgeführt haben, verwenden Sie den `query`-Wert aus der Zeile mit dem niedrigeren `elapsed`-Wert. Dies ist die Zeile für die kompilierte Version. Wenn Sie viele Abfragen ausgeführt haben, können Sie den in der LIMIT-Klausel verwendeten Wert heraufsetzen, um sicherzustellen, dass die Abfrage berücksichtigt wird.
1. Wählen Sie Zeilen aus SVL\$1QUERY\$1REPORT für Ihre Abfrage aus. Ordnen Sie die Ergebnisse nach Segment, Schritt, verbrauchter Zeit und Zeilen an:
```
select * from svl_query_report where query = MyQueryID order by segment, step, elapsed_time, rows;
```
1. Überprüfen Sie, ob auch alle Slices etwa dieselbe Anzahl an Zeilen verarbeiten:
![\[Eine Liste von Datenslices, die zum Ausführen einer Abfrage verwendet werden. Jedes Slice verarbeitet ungefähr die gleiche Anzahl von Zeilen.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/SVL_QUERY_REPORT_rows.png)
Überprüfen Sie auch, ob auch alle Slices etwa dieselbe Verarbeitungsdauer haben:
![\[Eine Liste von Datenslices, die zum Ausführen einer Abfrage verwendet werden. Jedes Slice benötigt ungefähr die gleiche Zeit.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/SVL_QUERY_REPORT_elapsed_time.png)
Große Unterschiede zwischen diesen Werten können auf eine verzerrte Datenverteilung hinweisen, weil für diese Abfrage nicht der beste Verteilungsstil verwendet wird. Empfohlene Lösungen finden Sie unter [Suboptimale Datenverteilung](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
# Zuweisung der Informationen in Abfrageplan und Abfragezusammenfassung
Wenn Sie die Abfragezusammenfassung analysieren, können Sie weitere Erkenntnisse erhalten, indem Sie die Vorgänge des Abfrageplans mit den Schritten (identifiziert durch beschriftungsfeldwerte) in der Abfragezusammenfassung abgleichen. In der folgenden Tabelle werden die Vorgänge im Abfrageplan den Schritten für die Abfragezusammenfassung zugeordnet.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/query-plan-summary-map.html)