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. # Dynamische und statische WLM-Konfigurationseigenschaften Die WLM-Konfigurationseigenschaften sind dynamisch oder statisch. Sie können dynamische Eigenschaften ohne Neustart des Clusters auf die Datenbank anwenden. Statische Eigenschaften erfordern jedoch einen Neustart des Clusters, damit die Änderungen wirksam werden. Wenn Sie jedoch dynamische und statische Eigenschaften gleichzeitig ändern, müssen Sie das Cluster neu starten, damit alle Eigenschaftsänderungen wirksam werden. Dies gilt unabhängig davon, ob die geänderten Eigenschaften dynamisch oder statisch sind. Während der Anwendung dynamischer Eigenschaften ist der Status des Clusters `modifying`. Das Umschalten zwischen automatischem und manuellem WLM ist eine statische Änderung und macht einen Cluster-Neustart erforderlich. Die folgende Tabelle zeigt, welche WLM-Eigenschaften dynamisch bzw. statisch sind, wenn automatisches bzw. manuelles WLM verwendet werden. **** | WLM-Eigenschaft | Automatisches WLM | Manuelles WLM | | --- | --- | --- | | Abfragegruppen | Dynamisch | Statisch | | Abfragegruppenplatzhalter | Dynamisch | Statisch | | Benutzergruppen | Dynamisch | Statisch | | Benutzergruppenplatzhalter | Dynamisch | Statisch | | Benutzerrollen | Dynamisch | Statisch | | Platzhalter für die Benutzerrolle | Dynamisch | Statisch | | Nebenläufigkeit auf dem Haupt-Cluster | Nicht zutreffend | Dynamisch | | Nebenläufigkeitsskalierungsmodus | Dynamisch | Dynamisch | | Aktivieren von Short Query Acceleration | Nicht zutreffend | Dynamisch | | Maximale Ausführungszeit für kurze Abfragen | Dynamisch | Dynamisch | | Prozentsatz des Arbeitsspeichers, der verwendet werden soll | Nicht zutreffend | Dynamisch | | Timeout (Zeitüberschreitung) | Nicht zutreffend | Dynamisch | | Priorität | Dynamisch | Nicht zutreffend | | Hinzufügen oder Entfernen von Warteschlangen | Dynamisch | Statisch | Wenn Sie eine Abfrageüberwachungsregel (Query Monitoring Rule, QMR) hinzufügen, erfolgt die Änderung automatisch, ohne dass der Cluster neu gestartet werden muss. **Anmerkung** Wenn bei Verwendung von manuellem WLM der Timeout-Wert geändert wird, wird der neue Wert auf alle Abfragen angewendet, deren Ausführung nach Änderung des Werts beginnt. Bei Änderung der Nebenläufigkeit oder des Prozentsatzes des Arbeitsspeichers, der verwendet werden soll, wird Amazon Redshift dynamisch in die neue Konfiguration geändert. Somit sind derzeit laufende Abfragen von der Änderung nicht betroffen. Weitere Informationen finden Sie unter [Dynamische WLM-Speicherzuweisung](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-dynamic-memory-allocation.html). **Topics** + [ # Dynamische WLM-Speicherzuweisung ](cm-c-wlm-dynamic-memory-allocation.md) + [ # Beispiel für dynamische WLM-Eigenschaften ](cm-c-wlm-dynamic-example.md) # Dynamische WLM-Speicherzuweisung In jeder Warteschlange erstellt WLM eine Anzahl von Abfrageslots, die der Nebenläufigkeitsstufe der Warteschlange entspricht. Die Menge des einem Abfrageslot zugewiesenen Speichers entspricht dem Prozentsatz des der Warteschlange zugewiesenen Speichers, dividiert durch die Anzahl der Slots. Ändern Sie die Speicherzuweisung oder Nebenläufigkeit, verwaltet Amazon Redshift den Übergang zu der neuen WLM-Konfiguration dynamisch. Somit können aktive Abfragen abgeschlossen werden unter Verwendung der derzeit zugewiesenen Speichermenge. Gleichzeitig stellt Amazon Redshift sicher, dass der Gesamtspeicherverbrauch 100 Prozent des verfügbaren Speichers nicht überschreitet. Der Workload Manager geht bei der Verwaltung des Übergangs wie folgt vor. 1. WLM berechnet die Speicherzuweisung für jeden neuen Abfrageslot neu. 1. Wenn ein Abfrageslot nicht aktiv von einer Abfrage verwendet wird, entfernt WLM den Slot und gibt so Speicher für neue Slots frei. 1. Wenn ein Abfrageslot aktiv verwendet wird, warten WLM auf den Abschluss der Abfrage. 1. Wenn aktive Abfragen abgeschlossen werden, werden leere Slots entfernt, und der entsprechende Speicherplatz wird freigegeben. 1. Wenn ausreichend Speicherplatz verfügbar ist, um einen oder mehrere Slots hinzuzufügen, werden neue Slots hinzugefügt. 1. Wenn alle zum Zeitpunkt der Änderung aktiven Abfragen abgeschlossen sind, entspricht die Zahl der Slots der neuen Nebenläufigkeitsstufe, und der Übergang zu der neuen WLM-Konfiguration ist abgeschlossen. Tatsächlich verwenden Abfragen, die zum Zeitpunkt der Änderung ausgeführt werden, weiterhin die ursprüngliche Speicherzuweisung. Abfragen, die sich zum Zeitpunkt der Änderung in einer Warteschlange befinden, werden an neue Slots weitergeleitet, sobald diese verfügbar sind. Wenn die dynamischen WLM-Eigenschaften während des Übergangsvorgangs geändert werden, beginnt WLM sofort mit dem Übergang zu der neuen Konfiguration, beginnend mit dem aktuellen Zustand. Um den Status des Übergangs anzuzeigen, fragen Sie die Systemtabelle [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md) ab. # Beispiel für dynamische WLM-Eigenschaften Mit Amazon Redshift können Sie mithilfe von Dynamic WLM (Workload Management) automatisch die Verteilung des Workloads und die Ressourcenzuweisung in Ihren Amazon-Redshift-Clustern verwalten. Dynamic WLM ist ein Beispiel für eine Workload Management (WLM)-Konfiguration, die Speicherzuweisungen dynamisch an die Workload-Anforderungen anpasst und so optimale Parallelität und Leistung ermöglicht. Der folgende Abschnitt enthält Einzelheiten zur Implementierung und Konfiguration von Dynamic WLM für Ihre Amazon-Redshift-Cluster. Angenommen, Ihr Cluster-WLM ist mit zwei Warteschlangen konfiguriert, die die folgenden dynamischen Eigenschaften verwenden. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/cm-c-wlm-dynamic-example.html) Nehmen Sie weiter an, in Ihrem Cluster sind 200 GB Speicher für die Abfrageverarbeitung verfügbar. (Diese Zahl ist willkürlich und dient hier lediglich Demonstrationszwecken.) Wie die folgende Gleichung zeigt, werden jedem Slot 25 GB zugewiesen. ``` (200 GB * 50% ) / 4 slots = 25 GB ``` Dann ändern Sie Ihr WLM zur Verwendung der folgenden dynamischen Eigenschaften. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/cm-c-wlm-dynamic-example.html) Wie die folgende Gleichung zeigt, beträgt die neue Speicherzuweisung für jeden Slot in Warteschlange 1 50 GB. ``` (200 GB * 75% ) / 3 slots = 50 GB ``` Nehmen wir an, die Abfragen A1, A2, A3 und A4 werden ausgeführt, während die neue Konfiguration angewendet wird, und die Abfragen B1, B2, B3 und B4 befinden sich in einer Warteschlange. WLM konfiguriert die Abfrageslots dynamisch wie folgt neu. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/cm-c-wlm-dynamic-example.html) 1. WLM berechnet die Speicherzuweisung für jeden Abfrageslot neu. Ursprünglich waren Warteschlange 1 100 GB zugewiesen. Die neue Warteschlange hat eine Gesamtzuweisung von 150 GB, der neuen Warteschlange stehen also sofort 50 GB zur Verfügung. Warteschlange 1 verwendet jetzt vier Slots und die neue Nebenläufigkeitsstufe beträgt drei Slots. Es werden also keine neuen Slots hinzugefügt. 1. Wenn eine Abfrage abgeschlossen wird, wird der Slot entfernt, und 25 GB werden freigegeben. Abfrage 1 hat jetzt drei Slots und 75 GB verfügbaren Speicherplatz. Die neue Konfiguration benötigt 50 GB für jeden neuen Slot, die neue Nebenläufigkeitsstufe liegt aber bei drei Slots, es werden daher neue Slots hinzugefügt 1. Wenn eine zweite Abfrage abgeschlossen wird, wird der Slot entfernt, und 25 GB werden freigegeben. Abfrage 1 hat jetzt zwei Slots und 100 GB freien Speicherplatz. 1. Ein neuer Slot mit 50 GB freiem Speicherplatz wird hinzugefügt. Abfrage 1 hat jetzt drei Slots und 50 GB freien Speicherplatz. In einer Warteschlange befindliche Abfragen können jetzt zu dem neuen Slot geleitet werden. 1. Wenn eine dritte Abfrage abgeschlossen wird, wird der Slot entfernt, und 25 GB werden freigegeben. Abfrage 1 hat jetzt zwei Slots und 75 GB freien Speicherplatz. 1. Ein neuer Slot mit 50 GB freiem Speicherplatz wird hinzugefügt. Abfrage 1 hat jetzt drei Slots und 25 GB freien Speicherplatz. In einer Warteschlange befindliche Abfragen können jetzt zu dem neuen Slot geleitet werden. 1. Wenn die vierte Abfrage abgeschlossen wird, wird der Slot entfernt, und 25 GB werden freigegeben. Abfrage 1 hat jetzt zwei Slots und 50 GB freien Speicherplatz. 1. Ein neuer Slot mit 50 GB freiem Speicherplatz wird hinzugefügt. Abfrage q hat jetzt drei Slots mit jeweils 50 GB, und der gesamte verfügbare Speicherplatz wurde zugewiesen. Der Übergang ist abgeschlossen, und alle Abfrageslots sind für Abfragen aus Warteschlangen verfügbar.