Warum überschreitet meine Amazon Redshift-Abfrage das von mir festgelegte WLM-Timeout?

Kurzbeschreibung

Ein WLM-Timeout gilt nur für Abfragen während der Abfrageausführungsphase. Wenn WLM eine Abfrage nicht wie erwartet beendet, liegt das normalerweise daran, dass die Abfrage Zeit in anderen Phasen als der Ausführungsphase verbracht hat. Beispielsweise könnte die Abfrage darauf warten, analysiert oder neu geschrieben zu werden, auf eine Sperre zu warten oder auf eine Stelle in der WLM-Warteschlange zu warten. Oder die Abfrage könnte die Rückkehrphase erreichen oder in eine andere Warteschlange springen.

Behebung

Bei der Abfrage von STV_RECENTS ist Startzeit die Uhrzeit, zu der die Abfrage in den Cluster eingetreten ist, nicht die Uhrzeit, zu der die Ausführung der Abfrage beginnt. Wenn sich die Abfrage in STV_RECENTS im Status Läuft befindet, ist sie im System live. Die Abfrage verwendet jedoch keine Rechenknotenressourcen, bis sie den Status STV_INFLIGHT erreicht hat. Weitere Informationen zur Abfrageplanung finden Sie unter Arbeitsablauf für die Abfrageplanung und -ausführung.

Um den Status einer laufenden Abfrage anzuzeigen, fragen Sie STV_INFLIGHT statt STV_RECENTS ab:

select \* from STV\_INFLIGHT where query = your\_query\_id;

Führen Sie die folgende Abfrage aus, um weitere Informationen zu Abfrageschritten zu erhalten:

select \* from SVL\_QUERY\_REPORT where query = your\_query\_id ORDER BY segment, step, slice;

Verwenden Sie die STV_EXEC_STATE-Tabelle für den aktuellen Status aller Abfragen, die aktiv auf Rechenknoten ausgeführt werden:

select \* from STV\_EXEC\_STATE where query = your\_query\_id ORDER BY segment, step, slice;

Im Folgenden sind häufige Gründe aufgeführt, warum eine Abfrage anscheinend länger als die WLM-Timeout-Periode ausgeführt wird.

Die Anfrage befindet sich in der „Rückgabe“ -Phase

Es gibt zwei „Zurück“ -Schritte. Überprüfen Sie STV_EXEC_STATE, um zu sehen, ob die Abfrage in eine dieser Rückgabephasen eingetreten ist:

• Die Rückkehr von den Rechenknoten zum Leader-Knoten
• Die Rückkehr vom Leader-Knoten zum Kunden

Ein Rollback ist im Gange

Bei einem DML-Vorgang (Data Manipulation Language) kann ein Fehler auftreten und ein Rollback durchgeführt werden. Dieser Vorgang wird möglicherweise nicht als „gestoppt“ angezeigt, da bereits ein Rollback ausgeführt wird. Sie können STV\ _EXEC\ _STATE abfragen, um Rollbacks anzuzeigen. Weitere Informationen finden Sie in STL\ _UNDONE.

Die Abfrage steht lange in der Warteschlange, bevor sie ausgeführt wird

Fragen Sie STV_WLM_QUERY_STATE ab, um die Wartezeit zu sehen:

select \* from STV\_WLM\_QUERY\_STATE where query = your\_query\_id;

Die Anfrage wartet auf einem Schloss

Wenn die Abfrage in STV\ _RECENTS sichtbar ist, aber nicht in STV\ _WLM\ _QUERY\ _STATE, wartet die Abfrage möglicherweise auf eine Sperre und wurde nicht in die Warteschlange aufgenommen. Weitere Informationen finden Sie unter Wie kann ich Sperren in Amazon Redshift erkennen und freigeben?

Eine Abfrage wurde in eine andere Warteschlange verschoben

Wenn eine Leseabfrage das Timeout-Limit für ihre aktuelle WLM-Warteschlange erreicht, wird die Abfrage an die nächste WLM-Warteschlange weitergeleitet. Oder, wenn es eine Abfrageüberwachungsregel gibt, die eine Hop-Aktion spezifiziert, dann wird die Abfrage an die nächste WLM-Warteschlange weitergeleitet. Um zu bestätigen, ob die Abfrage in die nächste Warteschlange gesprungen ist, führen Sie die folgende Abfrage basierend auf Ihrem Szenario aus:

• Wenn die Abfrage gerade ausgeführt wird, fragen Sie STV\ _WLM\ _QUERY\ _STATE ab.
• Wenn die Abfrage abgeschlossen ist, fragen Sie STL\ _WLM\ _QUERY ab.

Um zu verhindern, dass Abfragen in eine andere Warteschlange springen, konfigurieren Sie die Regeln zur Überwachung der WLM-Warteschlange oder der WLM-Abfrage. Weitere Informationen zu Query Hopping finden Sie unter WLM-Queue-Hopping.

Ein Netzwerk- oder Firewallproblem

Wenn ein Amazon Redshift-Server Probleme bei der Kommunikation mit Ihrem Client hat, bleibt der Server möglicherweise im Status „Zurück zum Client“ hängen. Suchen Sie nach Konflikten mit Netzwerkkomponenten, wie z. B. lokalen Firewalleinstellungen für eingehenden Datenverkehr, Sicherheitsgruppenregeln für ausgehenden Datenverkehr oder Netzwerk-ACL-Regeln (Network Access Control List) für ausgehenden Datenverkehr. Weitere Informationen finden Sie unter Herstellen einer Verbindung von außerhalb von Amazon EC2—Firewall-Timeout-Problem.

Ein Problem mit dem Cluster

Probleme im Cluster selbst, wie z. B. Hardwareprobleme, können dazu führen, dass die Abfrage einfriert. Wenn die Abfrage aufgrund von Clusterproblemen einfriert, befindet sich der Cluster im Status „Hardwarefehler“. Um einen Cluster mit einem Knoten wiederherzustellen, stellen Sie einen Snapshot wieder her. In Clustern mit mehreren Knoten werden ausgefallene Knoten automatisch ersetzt.

Verwandte Informationen

Optimieren der Abfrageleistung

Analysieren und Verbessern von Abfragen