Warum wurde meine Abfrage in Amazon Redshift storniert?

Kurzbeschreibung

Eine Abfrage kann in Amazon Redshift aus folgenden Gründen storniert werden:

• Einrichtung von Amazon Redshift Workload Management (WLM)-Abfrageüberwachungsregeln
• statement_timeout-Wert
• ABORT-, CANCEL- oder TERMINATE-Anforderungen (ABBRECHEN, STORNIEREN oder BEENDEN)
• Netzwerkprobleme
• Upgrades für die Cluster-Wartung
• Interne Verarbeitungsfehler
• ASSERT-Fehler

Gehen Sie so vor, um zu verhindern, dass Ihre Abfrage gestoppt wird:

• Erhöhen Sie den Wert für den Timeout-Parameter.
• Aktualisieren Sie Ihre WLM-Abfrageüberwachungsregeln.
• Planen Sie lang andauernde Vorgänge außerhalb von Wartungszeitfenstern ein.

Lösung

Einrichtung von Amazon WLM-Abfrageüberwachungsregeln

Erstellen Sie WLM-Abfrageüberwachungsregeln (Query Monitoring Rules, QMRs), um auf Metriken basierende Leistungsgrenzen für Ihre Warteschlangen zu definieren. Oder geben Sie die Aktionen an, die Amazon Redshift ergreifen soll, wenn eine Abfrage die WLM-Zeitlimits überschreitet. Erstellen Sie z. B. eine Regel, die Abfragen storniert, die für einen Schwellenwert von mehr als 60 Sekunden ausgeführt werden.

Beispiel 1: In der Abfrageüberwachungsregel angegebene Aktion abbrechen

Wenn eine Abfrage aufgrund der Aktion abort (Abbruch), die in einer Abfrageüberwachungsregel angegeben ist, abgebrochen wird, gibt die Abfrage den folgenden Fehler zurück:

"ERROR: Query (500029) cancelled by WLM abort action of Query Monitoring Rule "testrule"."

Führen Sie die folgende Abfrage aus, um zu ermitteln, ob eine Abfrage aufgrund einer „abort“-Aktion abgebrochen wurde:

select * from STL_WLM_RULE_ACTION where action = 'abort';

In der Abfrageausgabe werden alle Abfragen aufgeführt, die durch die Aktion „abort“ abgebrochen wurden. Wenn Ihre Abfrage-ID in der Ausgabe aufgeführt ist, erhöhen Sie das Zeitlimit im WLM-Abfrageüberwachungsregel-Parameter.

Beispiel 2: Keine verfügbaren Warteschlangen für die Abfrage, für die ein Hopping ausgeführt wird

Eine Abfrage kann übersprungen werden, wenn die Aktion „hop“ in der Abfrageüberwachungsregel angegeben ist. Wenn für eine Abfrage ein Hopping ausgeführt wird, versucht WLM, die Abfrage auf der Grundlage der WLM-Warteschlangenzuweisungsregeln an die nächste übereinstimmende Warteschlange weiterzuleiten. Wenn die Abfrage keiner Warteschlangendefinition entspricht, wird sie abgebrochen. Sie wird nicht der Standardwarteschlange zugewiesen. Weitere Informationen finden Sie unter Eigenschaften für den Parameter wlm_json_configuration.

Hinweis: Sie können ein Hopping für Abfragen nur in einer manuellen WLM-Konfiguration durchführen.

Wenn eine Abfrage übersprungen wird, aber keine passenden Warteschlangen verfügbar sind, gibt die abgebrochene Abfrage die folgende Fehlermeldung zurück:

"ERROR: Query (500104) canceled on user's request and ran out of wlm queues for restart."

Wenn Ihre Abfrage mit dieser Fehlermeldung abgebrochen wird, führen Sie folgende Abfrage aus, um die benutzerdefinierten Warteschlangen zu überprüfen:

select * from stl_wlm_query where query=<query-id>;

In Ihrer Ausgabe enthalten die service_class-Einträge 6–13 die benutzerdefinierten Warteschlangen. Beispielsweise kann in service_class 6 Queue1 in der WLM-Konfiguration auflisten und service_class 7 kann Queue2 auflisten.

Führen Sie die folgende Abfrage aus, um weitere Informationen zur service_class für die Zuordnung der Warteschlange zu erhalten:

select * from stv_wlm_service_class_config where service_class>5;

Nachdem Sie die Informationen zur Warteschlangenzuordnung erhalten haben, überprüfen Sie die WLM-Konfiguration von der Amazon-Redshift-Konsole aus. Stellen Sie sicher, dass die Warteschlangen der WLM-Konfiguration entsprechen. Sie können für eine Abfrage nur ein Hopping durchführen, wenn eine passende Warteschlange für die Benutzergruppen- oder Abfragegruppenkonfiguration verfügbar ist. Weitere Informationen finden Sie unter WLM-Abfragewarteschlangen-Hopping.

statement_timeout-Wert

Der Wert statement_timeout gibt die maximale Dauer an, für die eine Abfrage ausgeführt wird, bevor sie von Amazon Redshift beendet wird. Wenn ein statement_timeout-Wert überschritten wird, werden Abfragen, die während der Sitzung gesendet wurden, mit der folgenden Fehlermeldung abgebrochen:

„ERROR: (FEHLER:) Query (150) cancelled on user's request“ (Anfrage (150) wurde auf Anfrage des Benutzers storniert)

Führen Sie die folgende Abfrage aus, um zu überprüfen, ob eine Abfrage aufgrund eines überschrittenen Zeitlimits für die Anweisung abgebrochen wurde:

select * from SVL_STATEMENTTEXT where text ilike '%set%statement_timeout%to%' and pid in (select pid from STL_QUERY where query = <queryid>);

Zeitlimits für Anweisungen können auch in der Cluster-Parametergruppe festgelegt werden. Überprüfen Sie Ihre Cluster-Parametergruppe und alle Konfigurationseinstellungen für statement_timeout, um weitere Bestätigungen zu erhalten. Weitere Informationen finden Sie unter Ändern einer Parametergruppe.

ABORT-, CANCEL- oder TERMINATE-Anforderungen (ABBRECHEN, STORNIEREN oder BEENDEN)

Um zu überprüfen, ob eine bestimmte Abfrage von einem Benutzer (beispielsweise einem Superuser) gestoppt oder storniert wurde, führen Sie die folgende Abfrage mit Ihrer Abfrage-ID aus:

select * from SVL_STATEMENTTEXT where text ilike '%cancel%' and xid
    in (select xid from STL_QUERY where query = <queryid>);
select * from SVL_STATEMENTTEXT where text ilike '%abort%' and xid in (select xid from STL_QUERY where query = <queryid>);

Wenn die Abfrage in der Ausgabe erscheint, wurde sie auf Benutzeranfrage entweder gestoppt oder abgebrochen.

Hinweis: Benutzer können nur ihre eigene Sitzung beenden. Ein Superuser kann alle Sitzungen beenden.

Abfragen können auch gestoppt werden, wenn ein Benutzer einen entsprechenden Prozess (in dem die Abfrage ausgeführt wird) abbricht oder beendet. Im Folgenden finden Sie Beispiele für Prozesse, mit denen eine Abfrage storniert oder beendet werden kann:

• PG_TERMINATE_BACKEND
• PG_CANCEL_BACKEND
• CANCEL

Wenn ein Prozess durch diese Befehle abgebrochen oder beendet wird, wird ein Eintrag in SVL_TERMINATE protokolliert. Um zu überprüfen, ob eine Abfrage beendet wurde, weil eine Sitzung beendet wurde, überprüfen Sie die SVL_TERMINATE-Protokolle. Führen Sie die folgende Abfrage aus, um die SVL_TERMINATE-Protokolle zu überprüfen:

select * from SVL_TERMINATE where pid=(select pid from STL_QUERY where query=500534);

Netzwerkprobleme

Manchmal werden Abfragen aufgrund von zugrunde liegenden Netzwerkproblemen abgebrochen. Um zu überprüfen, ob Netzwerkprobleme dazu führen, dass Ihre Abfrage abgebrochen wird, führen Sie die folgende Abfrage aus, um die STL_CONNECTION_LOG-Einträge zu überprüfen:

select * from STL_CONNECTION_LOG where pid in (select pid from STL_QUERY where query = <query_id>);

STL_CONNECTION_LOG zeichnet Authentifizierungsversuche und Netzwerkverbindungen oder Verbindungsabbrüche auf. Wenn Ihre Abfrage in der Ausgabe erscheint, kann ein Netzwerkverbindungsproblem dazu führen, dass Ihre Abfrage abgebrochen wird.

Upgrades für die Cluster-Wartung

Wenn bei der Ausführung einer Abfrage eine geplante Wartung stattfindet, wird die Abfrage beendet und ein Rollback durchgeführt, sodass ein Cluster-Neustart erforderlich ist. Planen Sie lang andauernde Vorgänge (z. B. das Laden großer Datenmengen oder den VACUUM-Vorgang) ein, um Wartungszeitfenster zu vermeiden. Weitere Informationen finden Sie unter Planen rund um Wartungszeitfenster.

Um zu überprüfen, ob an Ihrem Amazon-Redshift-Cluster Wartungsarbeiten durchgeführt wurden, wählen Sie in Ihrer Amazon Redshift-Konsole den Tab Events (Ereignisse).

Interne Verarbeitungsfehler

In der Tabelle STL_ERROR werden interne Verarbeitungsfehler aufgezeichnet, die von Amazon Redshift generiert wurden. In der Tabelle STL_ERROR werden keine SQL-Fehler oder -Meldungen aufgezeichnet.

Um zu überprüfen, ob Ihre Abfrage durch einen internen Fehler abgebrochen wurde, führen Sie die folgende Abfrage aus, um die STL_ERROR-Einträge zu überprüfen:

select * from STL_ERROR where userid=<user id>;

ASSERT-Fehler

Manchmal werden Abfragen aufgrund eines ASSERT-Fehlers gestoppt. Der ASSERT-Fehler kann auftreten, wenn ein Problem mit der Abfrage selbst auftritt. Wenn Sie nach einem Patch-Upgrade einen ASSERT-Fehler erhalten, aktualisieren Sie Amazon Redshift auf die neueste Cluster-Version. Überprüfen Sie dann den Cluster-Versionsverlauf. Sie können auch ein Rollback der Cluster-Version durchführen.