Amazon Redshift wird UDFs ab dem 1. November 2025 die Erstellung von neuem Python nicht mehr unterstützen. Wenn Sie Python verwenden möchten UDFs, erstellen Sie das UDFs vor diesem Datum liegende. Bestehendes Python UDFs wird weiterhin wie gewohnt funktionieren. Weitere Informationen finden Sie im Blog-Posting.

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.

Schreiben und read/write 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 read/write UPDATE-Operationen sind Operationen (damit Zeilen gelöscht oder aktualisiert werden können, müssen sie zuerst 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 gleichzeitige Transaktionen füreinander unsichtbar sind, DELETEs müssen beide UPDATEs Transaktionen eine Momentaufnahme 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 trennen, die eine exklusive Sperre erfordern (UPDATE/MERGE/DELETE/DDL statements) to a different transaction so that any INSERT/COPY statements can progress simultaneously, and the statements requiring exclusive locks can execute after them. Alternatively, for transactions with INSERT/COPY statements and MERGE/UPDATE/MERGEAnweisungen in derselben Tabelle), Sie können Wiederholungslogik in Ihre Anwendungen integrieren, um potenzielle Deadlocks zu umgehen.