Amazon Redshift unterstützt ab dem 1. November 2025 nicht mehr die Erstellung neuer Python-UDFs. Wenn Sie Python-UDFs verwenden möchten, erstellen Sie die UDFs vor diesem Datum. Bestehende Python-UDFs funktionieren weiterhin wie gewohnt. Weitere Informationen finden Sie im Blog-Posting.

Schreib- und Lese-Schreib-Operationen

Sie können das spezifische Verhalten gleichzeitiger Schreib- und Lese-Schreib-Operationen verwalten, indem Sie entscheiden, wann und wie verschiedene Arten von Befehlen ausgeführt werden. Die folgenden Befehle sind für dieses Thema relevant:

COPY- und INSERT-Operationen sind reine Schreiboperationen. DELETE- und UPDATE-Operationen sind Lese-Schreib-Operationen (damit Zeilen gelöscht oder aktualisiert werden können, müssen sie zunächst gelesen werden). Die Ergebnisse gleichzeitiger Schreibvorgänge sind von den spezifischen Befehlen abhängig, die gleichzeitig ausgeführt werden.

UPDATE- und DELETE-Operationen verhalten sich anders, da sie von einem anfänglichen Tabellenlesevorgang abhängig sind, bevor Schreibvorgänge ausgeführt werden können. Da sich gleichzeitige Transaktionen gegenseitig nicht erkennen können, müssen UPDATE- und DELETE-Operationen einen Snapshot der Daten aus dem letzten Commit lesen. Wenn die erste UPDATE- oder DELETE-Operation die Sperre aufhebt, muss die zweite UPDATE- oder DELETE-Operation feststellen, ob die Daten, mit denen sie arbeitet, möglicherweise veraltet sind. Sie sind nicht veraltet, da die zweite Transaktion den Daten-Snapshot erst erhält, nachdem die erste Transaktion die Sperre aufgehoben hat.

Potenzielle Deadlock-Situation für gleichzeitige Schreibtransaktionen, an denen mehrere Tabellen beteiligt sind

Wenn Transaktionen Aktualisierungen von mehr als einer Tabelle umfassen, besteht stets die Möglichkeit, dass gleichzeitig ausgeführte Transaktionen in eine Deadlock-Situation geraten, wenn beide versuchen, zum gleichen Satz von Tabellen zu schreiben. Transaktionen heben alle ihre Tabellensperren auf einmal auf, wenn sie einen Commit oder ein Rollback ausführen. Sie heben Sperren nicht einzeln auf.

Angenommen, die Transaktionen T1 und T2 werden ungefähr zur gleichen Zeit gestartet. Wenn T1 mit dem Schreiben zu Tabelle A beginnt und T2 mit dem Schreiben zu Tabelle B beginnt, können beide Transaktionen ohne Konflikt fortgesetzt werden. Wenn jedoch T1 die Schreiboperation für Tabelle A beendet hat und eine Schreiboperation für Tabelle B starten muss, kann die Transaktion nicht fortgesetzt werden, da T2 die Tabelle B noch nicht freigegeben hat. Wenn umgekehrt T2 die Schreiboperation für Tabelle B beendet hat und eine Schreiboperation für Tabelle A starten muss, kann die Transaktion ebenfalls nicht fortgesetzt werden, da T1 die Tabelle A noch nicht freigegeben hat. Da keine der beiden Transaktionen ihre Sperren aufheben kann, solange nicht für alle ihre Schreiboperationen ein Commit ausgeführt wurde, kann keine der beiden Transaktionen fortgesetzt werden. Um diese Art von Deadlock zu vermeiden, müssen Sie gleichzeitige Schreiboperationen sorgfältig planen. Beispielsweise sollten Sie in Transaktionen Tabellen stets in derselben Reihenfolge aktualisieren und bei Angabe von Sperren Tabellen auch in derselben Reihenfolge sperren, bevor Sie DML-Operationen ausführen.

Potenzielle Deadlock-Situation für gleichzeitige Schreibtransaktionen, an denen eine einzelne Tabelle beteiligt ist

In einer Umgebung mit Snapshot-Isolierung können Deadlocks auftreten, wenn gleichzeitige Schreibtransaktionen für dieselbe Tabelle ausgeführt werden. Der Snapshot-Isolation-Deadlock tritt auf, wenn gleichzeitige INSERT- oder COPY-Anweisungen eine Sperre gemeinsam anwenden und fortgesetzt werden und eine weitere Anweisung eine Operation (UPDATE, DELETE, MERGE oder DDL) ausführen muss, die eine exklusive Sperre für dieselbe Tabelle erfordert.

Betrachten Sie das folgenden Szenario:

Transaktion 1 (T1):

INSERT/COPY INTO table_A;

Transaktion 2 (T2):

INSERT/COPY INTO table_A; 
            <UPDATE/DELETE/MERGE/DDL statement> table_A

Ein Deadlock kann auftreten, wenn mehrere Transaktionen mit INSERT- oder COPY-Operationen gleichzeitig für dieselbe Tabelle mit einer gemeinsamen Sperre ausgeführt werden und eine dieser Transaktionen nach der reinen Schreiboperation eine Operation ausführt, die eine exklusive Sperre erfordert, z. B. eine UPDATE-, MERGE-, DELETE- oder DDL-Anweisung.

Um den Deadlock in diesen Situationen zu vermeiden, können Sie Anweisungen, die eine exklusive Sperre erfordern (UPDATE-, MERGE-, DELETE- oder DDL-Anweisungen) als andere Transaktionen abtrennen, sodass INSERT- oder COPY-Anweisungen gleichzeitig ausgeführt werden können und die Anweisungen, die exklusive Sperren erfordern, anschließend ausgeführt werden können. Alternativ können Sie für Transaktionen mit INSERT- oder COPY-Anweisungen sowie MERGE-, UPDATE- oder MERGE-Anweisungen für dieselbe Tabelle Wiederholungslogik in die Anwendungen integrieren, um mögliche Deadlocks zu umgehen.