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.
# WLM-Abfrageüberwachungsregeln
In Amazon Redshift Workload Management (WLM) definieren Abfrageüberwachungsregeln auf Metriken basierende Leistungsgrenzen für WLM-Warteschlangen und geben an, welche Aktion durchgeführt werden soll, wenn eine Abfrage diese Grenzwerte überschreitet. So können Sie etwa für eine für kurze Abfragen dedizierte Warteschlange eine Regel erstellen, die Abfragen abbricht, die länger als 60 Sekunden ausgeführt werden. Zur Nachverfolgung schlecht gestalteter Abfragen können Sie eine weitere Regel verwenden, die Abfragen mit eingebetteten Schleifen protokolliert.
Sie definieren die Abfrageüberwachungsregeln im Rahmen Ihrer Workload Management (WLM)-Konfiguration. Sie können für jede Warteschlange bis zu 25 Regeln definieren. Dabei liegt die Grenze für alle Warteschlangen insgesamt bei 25 Regeln. Jede Regel enthält bis zu drei Bedingungen (oder Prädikate) sowie eine Aktion. Ein *Prädikat* besteht aus einer Metrik, einer Vergleichsbedingung (=, <, oder >) und einem Wert. Wenn alle Prädikate für eine Regel erfüllt sind, wird die Aktion der Regel ausgelöst. Mögliche Regelaktionen sind log, hop und abort, wie nachfolgend erläutert.
Die Regeln in einer Warteschlange gelten nur für Abfragen, die in dieser Warteschlange ausgeführt werden. Eine Regel ist unabhängig von anderen Regeln.
WLM evaluiert die Metriken alle 10 Sekunden. Amazon Redshift wendet Regeln zur Abfrageüberwachung auf der Ebene untergeordneter Abfragen an, wenn Abfragen automatisch neu geschrieben werden. Wenn mehr als eine Regel ausgelöst wird, wählt WLM die Regel mit der schwerwiegendsten Aktion. Wenn die Aktion für zwei Regeln denselben Schweregrad hat, führt WLM die Regeln in alphabetischer Reihenfolge auf der Grundlage des Regelnamens aus. Wenn die Aktion hop oder abort ist, wird die Aktion protokolliert, und die Abfrage wird aus der Warteschlange entfernt. Wenn die Aktion log ist, wird die Abfrage weiterhin in der Warteschlange ausgeführt. WLM initiiert nur eine log-Aktion pro Abfrage und Regel. Wenn die Warteschlange weitere Regeln enthält, bleiben diese wirksam. Wenn die Aktion hop ist und die Abfrage zu einer anderen Warteschlange geleitet wird, gelten die Regeln für die neue Warteschlange. Weitere Informationen zur Abfrageüberwachung und zur Nachverfolgung von Aktionen, die bei bestimmten Abfragen ergriffen wurden, finden Sie in der Beispielsammlung unter [Short Query Acceleration](wlm-short-query-acceleration.md).
Wenn alle Prädikate einer Regel erfüllt sind, schreibt WLM eine Zeile in die Systemtabelle [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md). Zusätzlich zeichnet Amazon Redshift Abfragemetriken für aktuell ausgeführte Abfragen in auf [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md). Metriken für abgeschlossene Abfragen werden in gespeichert [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md).
**Anmerkung**
Für Amazon Redshift Serverless können Sie Abfragewarteschlangen und Überwachungsregeln mithilfe des Parameters konfigurieren. `wlm_json_configuration` Auf diese Weise können Sie mehrere Warteschlangen mit unterschiedlichen Benutzerrollen, Abfragegruppen und Überwachungsregeln erstellen. Weitere Informationen zur Konfiguration serverloser Abfragewarteschlangen finden Sie unter [Einrichten von Abfragewarteschlangen](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html) im *Amazon Redshift* Management Guide.
## Definition einer Abfrageüberwachungsregel
Sie erstellen Abfrageüberwachungsregeln als Teil Ihrer WLM-Konfiguration, die Sie im Rahmen der Parametergruppendefinition für Ihren Cluster definieren.
Sie können Regeln mithilfe von AWS-Managementkonsole oder programmgesteuert mithilfe von JSON erstellen.
**Anmerkung**
Wenn Sie Regeln auf programmatischen Wege erstellen, empfehlen wir nachdrücklich, die Konsole zu verwenden, um die JSON-Elemente zu erstellen, die Sie in der Parametergruppendefinition verwenden. Weitere Informationen finden Sie unter [Erstellen einer Abfrageüberwachungsregel](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) und [Konfiguration von Parameterwerten mit der AWS CLI](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html#configure-parameters-using-the-cli) im *Managementleitfaden zu Amazon Redshift*.
Zur Definition einer Abfrageüberwachungsregel geben Sie die folgenden Elemente an:
+ Einen Regelnamen – Regelnamen müssen innerhalb der WLM-Konfiguration eindeutig sein. Regelnamen können aus bis zu 32 alphanumerischen Zeichen oder Unterstrichen bestehen und dürfen keine Leerzeichen oder Anführungszeichen enthalten. Sie können bis zu 25 Regeln pro Warteschlange und insgesamt 25 Regeln für alle Warteschlangen festlegen.
+ Ein oder mehrere Prädikat(e) – Sie können bis zu drei Prädikate pro Regel angeben. Wenn alle Prädikate für eine Regel erfüllt sind, wird die Aktion der Regel ausgelöst. Ein Prädikat wird durch einen Metriknamen, einen Operator ( =, <, or > ) und einen Wert definiert. Ein Beispiel ist `query_cpu_time > 100000`. Für eine Liste der Metriken und Beispiele für Werte bei unterschiedlichen Metriken vgl. [Abfrageüberwachungsmetriken für Amazon Redshift wurden bereitgestellt](#cm-c-wlm-query-monitoring-metrics) unten in diesem Abschnitt.
+ Eine Aktion – Wenn mehr als eine Regel ausgelöst wird, wählt WLM die Regel mit der schwerwiegendsten Aktion. Mögliche Aktionen, aufsteigend nach Schweregrad, sind:
+ Log – Aufzeichnung von Informationen zu der Abfrage in der Systemtabelle STL\$1WLM\$1RULE\$1ACTION. Verwenden Sie diese Aktion, wenn Sie lediglich einen Protokolleintrag schreiben möchten. WLM erstellt höchstens einen Protokolleintrag pro Abfrage und Regel. Nach einer Log-Aktion bleiben andere Regeln wirksam, und WLM überwacht die Abfrage weiter.
+ Hop (Nur bei manuellem WLM verfügbar) – Protokollieren der Aktion und Hopping der Abfrage zur nächsten übereinstimmenden Warteschlange. Wenn keine andere passende Warteschlange vorhanden ist, wird die Abfrage abgebrochen. QMR führt Hopping nur für [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html) (CTAS)-Anweisungen und schreibgeschützte Abfragen aus, beispielsweise SELECT-Anweisungen. Weitere Informationen finden Sie unter [WLM-Abfragewarteschlangen-Hopping](wlm-queue-hopping.md).
+ Abort – Protokollieren der Aktion und Abbrechen der Abfrage. QMR stoppt keine COPY-Anweisungen und Wartungsoperationen wie ALTER, ANALYZE und VACUUM.
+ Ändern der Priorität (nur bei automatischem WLM verfügbar) – Ändern der Priorität einer Warteschlange.
Zur Begrenzung der Laufzeit von Abfragen empfehlen wir das Erstellen einer Abfrageüberwachungsregel anstelle eines WLM-Timeouts. Sie können beispielsweise `max_execution_time` auf 50.000 Millisekunden festlegen, wie im folgenden JSON-Snippet gezeigt.
```
"max_execution_time": 50000
```
Wir empfehlen jedoch, stattdessen eine entsprechende Regel zur Abfrageüberwachung zu definieren. Das folgende Beispiel zeigt eine Abfrageüberwachungsregel, die `query_execution_time` auf 50 Sekunden festlegt:
```
"rules":
[
{
"rule_name": "rule_query_execution",
"predicate": [
{
"metric_name": "query_execution_time",
"operator": ">",
"value": 50
}
],
"action": "abort"
}
]
```
Informationen zu den Schritten zum Erstellen oder Ändern einer Abfrageüberwachungsregel finden Sie unter [Erstellen einer Abfrageüberwachungsregel](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) und [Eigenschaften im Parameter wlm\$1json\$1configuration](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html#wlm-json-config-properties) im *Managementleitfaden zu Amazon Redshift*.
Weitere Informationen zu Abfrageüberwachungsregeln finden Sie in den folgenden Themen:
+ [Abfrageüberwachungsmetriken für Amazon Redshift wurden bereitgestellt](#cm-c-wlm-query-monitoring-metrics)
+ [Vorlagen für Abfrageüberwachungsregeln](#cm-c-wlm-query-monitoring-templates)
+ [Erstellen einer Abfrageüberwachungsregel](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html)
+ [Workload-Management-Konfiguration](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)
+ [Systemtabellen und Ansichten für Abfrageüberwachungsregeln](#cm-c-wlm-qmr-tables-and-views)
## Abfrageüberwachungsmetriken für Amazon Redshift wurden bereitgestellt
Die folgende Tabelle beschreibt die Metriken für Abfrageüberwachungsregeln. (Diese Metriken unterscheiden sich von den in den Systemtabellen [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md) und [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md) gespeicherten Metriken.)
Für eine Metrik wird der Leistungsschwellenwert auf Abfrage- oder auf Segmentebene verfolgt. Für weitere Informationen zu Segmenten und Schritten vgl. [Workflow der Abfrageplanung und -ausführung](c-query-planning.md).
**Anmerkung**
Der Parameter [WLM-Timeout](cm-c-defining-query-queues.md#wlm-timeout) unterscheidet sich von Abfrageüberwachungsregeln.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)
**Anmerkung**
Die Hop-Aktion wird mit dem Prädikat `query_queue_time` nicht unterstützt. Das heißt, Regeln, die zum Durchführen von Hopping definiert werden, wenn ein `query_queue_time`-Prädikat erfüllt wird, werden ignoriert.
Kurze Segmentausführungszeiten können bei einigen Metriken zu Samplingfehlern führen, etwa bei `io_skew` und `query_cpu_usage_percent`. Nehmen Sie zur Vermeidung oder Reduzierung von Samplingfehlern die Segmentausführungszeit in Ihre Regeln auf. Ein guter Ausgangspunkt ist `segment_execution_time > 10`.
Die Ansicht [SVL\$1QUERY\$1METRICS](r_SVL_QUERY_METRICS.md) zeigt die Metriken für abgeschlossene Abfragen. Die Ansicht [SVL\$1QUERY\$1METRICS\$1SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) zeigt die maximalen Werte der Metriken für abgeschlossene Abfragen. Verwenden Sie die Werte in diesen Ansichten als Hilfe zur Bestimmung der Schwellenwerte für die Definition von Abfrageüberwachungsregeln.
## Abfrageüberwachungsmetriken für Amazon Redshift Serverless
Die folgende Tabelle beschreibt die Metriken, die in Abfrageüberwachungsregeln für Amazon Redshift Serverless verwendet werden.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)
**Anmerkung**
Die Hop-Aktion wird mit dem Prädikat `max_query_queue_time` nicht unterstützt. Das heißt, Regeln, die zum Durchführen von Hopping definiert werden, wenn ein `max_query_queue_time`-Prädikat erfüllt wird, werden ignoriert.
Kurze Segmentausführungszeiten können bei einigen Metriken zu Samplingfehlern führen, etwa bei `max_io_skew` und `max_query_cpu_usage_percent`.
Für Amazon Redshift Serverless können Sie Abfragewarteschlangen und Überwachungsregeln mithilfe des Parameters konfigurieren. `wlm_json_configuration` Auf diese Weise können Sie mithilfe der oben aufgeführten Metriken mehrere Warteschlangen mit unterschiedlichen Benutzerrollen, Abfragegruppen und Überwachungsregeln erstellen. Weitere Informationen zur Konfiguration serverloser Abfragewarteschlangen finden Sie unter [WLM-JSON-Konfigurationsstruktur](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html#serverless-wlm-json-configuration) im *Amazon Redshift* Management Guide.
## Vorlagen für Abfrageüberwachungsregeln
Beim Hinzufügen einer Regel mit der Amazon-Redshift-Konsole können Sie eine Regel aus einer vordefinierten Vorlage erstellen. Amazon Redshift erstellt eine neue Regel mit einem Satz von Prädikaten und füllt die Prädikate mit Standardwerten aus. Die Standardaktion ist log. Sie können die Prädikate und die Aktion an Ihren Anwendungsfall anpassen.
In der folgenden Tabelle werden die verfügbaren Vorlagen aufgeführt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)
## Systemtabellen und Ansichten für Abfrageüberwachungsregeln
Wenn alle Prädikate einer Regel erfüllt sind, schreibt WLM eine Zeile in die Systemtabelle [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md). Diese Zeile enthält Details zu der Abfrage, die die Regel ausgelöst hat, und die daraus resultierende Aktion.
Darüber hinaus zeichnet Amazon Redshift Abfragemetriken der folgenden Systemtabellen und Ansichten auf.
+ Die Tabelle [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md) zeigt die Metriken für aktuell ausgeführte Abfragen an.
+ Die Tabelle [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md) zeichnet die Metriken für abgeschlossene Abfragen auf.
+ Die Ansicht [SVL\$1QUERY\$1METRICS](r_SVL_QUERY_METRICS.md) zeigt die Metriken für abgeschlossene Abfragen.
+ Die Ansicht [SVL\$1QUERY\$1METRICS\$1SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) zeigt die maximalen Werte der Metriken für abgeschlossene Abfragen.