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. # Verwalten gleichzeitiger Schreiboperationen Einige Anwendungen erfordern nicht nur gleichzeitiges Abfragen und Laden, sondern auch die Fähigkeit, gleichzeitig zu mehreren Tabellen oder zur selben Tabelle zu schreiben. In diesem Zusammenhang bedeutet *gleichzeitig* überlappend, nicht die Ausführung zu exakt demselben Zeitpunkt. Zwei Transaktionen werden als gleichzeitig betrachtet, wenn die zweite Transaktion gestartet wird, bevor für die erste Transaktion ein Commit ausgeführt wird. Gleichzeitige Operationen können ihren Ursprung in verschiedenen Sitzungen haben, die vom selben Benutzer oder von verschiedenen Benutzern gesteuert werden. Amazon Redshift unterstützt diese Arten von Anwendungen, da Tabellen gelesen werden können, während sie inkrementell geladen oder geändert werden. Abfragen steht einfach die letzte übergegebene Version bzw. der letzte *Snapshot* der Daten bereit. Sie müssen nicht darauf warten, dass für die nächste Version ein Commit ausgeführt wird. Wenn Sie möchten, dass eine bestimmte Abfrage auf einen Commit aus einer anderen Schreiboperation wartet, müssen Sie dies entsprechend planen. **Anmerkung** Amazon Redshift unterstützt standardmäßig *automatische Commits*, bei denen für jeden getrennt ausgeführten SQL-Befehl ein einzelnes Commit ausgeführt wird. Wenn Sie in einem Transaktionsblock einen Satz von Befehlen einschließen (definiert durch die Anweisungen [BEGIN](r_BEGIN.md) und [END](r_END.md)), wird der Block als eine einzige Transaktion übergeben, sodass Sie ein Rollback für ihn ausführen können, wenn notwendig. Ausnahmen von diesem Verhalten sind die Befehle TRUNCATE und VACUUM, die automatische alle ausstehenden Änderungen, die in der aktuellen Transaktion vorgenommen wurden, übergeben. Einige SQL-Clients geben automatisch BEGIN- und COMMIT-Befehle aus, sodass der Client steuert, ob eine Gruppe von Anweisungen als Transaktion oder jede einzelne Anweisung als eigene Transaktion ausgeführt wird. Konsultieren Sie die Dokumentation zu der von Ihnen verwendeten Schnittstelle. Wenn Sie zum Beispiel den JDBC-Treiber von Amazon Redshift verwenden, führt ein JDBC `PreparedStatement` mit einer Abfragezeichenfolge, die mehrere (durch Semikolon getrennte) SQL-Befehle enthält, alle Anweisungen als eine einzige Transaktion aus. Wenn Sie dagegen SQL verwenden Workbench/J und AUTO COMMIT ON setzen, wird bei der Ausführung mehrerer Anweisungen jede Anweisung als eigene Transaktion ausgeführt. In den folgenden Themen werden einige der wesentlichen Konzepte und Anwendungsfälle beschrieben, die Transaktionen, Datenbank-Snapshots, Updates und Gleichzeitigkeitsverhalten umfassen. **Topics** + [Isolierungsstufen in Amazon Redshift](c_serial_isolation.md) + [Schreiben und read/write Operationen](c_write_readwrite.md) + [Beispiele für gleichzeitige Schreibvorgänge](r_Serializable_isolation_example.md) + [Beheben von Fehlern für die serialisierbare Isolierung](c_serial_isolation-serializable-isolation-troubleshooting.md) # Isolierungsstufen in Amazon Redshift Gleichzeitige Schreiboperationen werden in Amazon Redshift auf geschützte Art unterstützt, indem Schreibsperren für Tabellen und der Grundsatz der *serialisierbaren Isolierung* angewendet werden. Die serialisierbare Isolierung bewahrt die Illusion, dass eine Transaktion, die für eine Tabelle ausgeführt wird, die einzige Transaktion ist, die für diese Tabelle ausgeführt wird. Amazon-Redshift-Datenbanken unterstützen gleichzeitige Schreiboperationen, indem jede Operation die neueste übergebene Version bzw. den neuesten übergebenen Snapshot ihrer Daten zu Beginn der Transaktion verwendet. Innerhalb der Transaktion wird beim ersten Auftreten der meisten SELECT-Anweisungen, von DML-Befehlen wie COPY, DELETE, INSERT, UPDATE und TRUNCATE und der folgenden DDL-Befehle ein Datenbank-Snapshot erstellt: + ALTER TABLE (Hinzufügen oder Entfernen von Spalten) + CREATE TABLE + DROP TABLE + TRUNCATE TABLE Keine andere Transaktion kann diesen Snapshot ändern. Das bedeutet, dass Transaktionen voneinander isoliert sind. Gleichzeitige Transaktionen können sich gegenseitig nicht sehen, d. h., sie können die Änderungen der jeweils anderen Transaktionen nicht erkennen. Eine gleichzeitige Ausführung von Transaktionen muss zu denselben Ergebnissen führen wie die serielle Ausführung dieser Transaktionen. Wenn keine serielle Ausführung dieser Transaktionen dieselben Ergebnisse produziert, wird die Transaktion abgebrochen, die eine Anweisung ausführt, die die Serialisierbarkeit verhindern würde. Für diese Transaktion wird ein Rollback ausgeführt. Angenommen, ein Benutzer versucht, zwei gleichzeitige Transaktionen auszuführen, T1 und T2. Die Ausführung von T1 und T2 muss zu denselben Ergebnissen führen wie in mindestens einem der folgenden Szenarien: + T1 und T2 werden seriell in dieser Reihenfolge ausgeführt. + T2 und T1 werden seriell in dieser Reihenfolge ausgeführt. Isolierungsstufen in Amazon Redshift verhindern die folgenden Probleme: + Fehlerhafte Leseoperationen: Eine fehlerhafte Leseoperation tritt auf, wenn eine Transaktion Daten liest, die noch nicht übergeben wurden. Angenommen, Transaktion 1 aktualisiert eine Zeile. Transaktion 2 liest die aktualisierte Zeile, bevor T1 die Aktualisierung übergibt. Wenn T1 die Änderung rückgängig macht, hat T2 Daten in nicht übergebenen Zeilen gelesen, für die Amazon Redshift jetzt annimmt, dass sie nie existiert haben. + Nicht wiederholbare Leseoperationen: Eine nicht wiederholbare Leseoperation tritt auf, wenn eine einzelne Transaktion dieselbe Zeile zweimal liest, aber jedes Mal andere Daten erhält. Angenommen, Transaktion 1 liest eine Zeile. Transaktion 2 aktualisiert oder löscht diese Zeile und übergibt die Aktualisierung oder Löschung. Wenn T1 die Zeile erneut liest, ruft sie andere Zeilenwerte ab oder stellt fest, dass die Zeile gelöscht wurde. + Phantome: Ein Phantom ist eine Zeile, die den Suchkriterien entspricht, aber zunächst nicht sichtbar ist. Angenommen, Transaktion 1 liest eine Reihe von Zeilen, die ihren Suchkriterien entsprechen. Transaktion 2 generiert eine neue Zeile in einer UPDATE- oder INSERT-Anweisung, die den Suchkriterien für T1 entspricht. Wenn T1 ihre Suchanweisung erneut ausführt, erhält sie einen anderen Satz von Zeilen. ## SNAPSHOT- und SERIALIZABLE-Isolierung SNAPSHOT und SERIALIZABLE sind die beiden serialisierbaren Isolierungsstufen, die in Amazon Redshift verfügbar sind. Die SNAPSHOT-Isolierung ist die Standard-Isolierungsstufe bei der Erstellung von bereitgestellten Clustern und Serverless-Arbeitsgruppen, sodass Sie größere Datenmengen als bei der SERIALIZABLE-Isolierung in kürzerer Zeit verarbeiten können. Die SERIALIZABLE-Isolierung nimmt mehr Zeit in Anspruch, implementiert jedoch strengere Einschränkungen für gleichzeitige Transaktionen. Diese Isolierungsstufe verhindert Probleme wie Schreibverzerrungsanomalien, da nur jeweils eine Transaktion übergeben werden kann, während alle anderen gleichzeitigen Transaktionen mit einem Fehler wegen Verletzung der serialisierbaren Isolierung abgebrochen werden. Im Folgenden finden Sie ein Timeline-Beispiel dafür, wie zwei gleichzeitige Schreiboperationen bei Verwendung der SNAPSHOT-Isolierung behandelt würden. Die UPDATE-Anweisung jedes Benutzers darf einen Commit ausführen, da es nicht zu Konflikten kommt, wenn versucht wird, dieselben Zeilen zu aktualisieren. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/c_serial_isolation.html) Wenn dasselbe Szenario mit serialisierbarer Isolation ausgeführt wird, beendet Amazon Redshift Benutzer 2 aufgrund einer serialisierbaren Verletzung und gibt den Fehler `1023` zurück. Weitere Informationen finden Sie unter [Beheben von Fehlern für die serialisierbare Isolierung](c_serial_isolation-serializable-isolation-troubleshooting.md). In diesem Fall kann nur Benutzer 1 einen erfolgreichen Commit ausführen. ## Überlegungen Berücksichtigen Sie bei der Verwendung von Isolierungsstufen in Amazon Redshift Folgendes: + Fragen Sie die Katalogansicht STV\$1DB\$1ISOLATION\$1LEVEL ab, um zu sehen, welche Isolierungsstufe Ihre Datenbank verwendet. Weitere Informationen finden Sie unter [STV\$1DB\$1ISOLATION\$1LEVEL](r_STV_DB_ISOLATION_LEVEL.md). + Fragen Sie die Ansicht PG\$1DATABASE\$1INFO ab, um zu sehen, wie viele gleichzeitige Transaktionen für Ihre Datenbank unterstützt werden. Weitere Informationen finden Sie unter [PG\$1DATABASE\$1INFO](r_PG_DATABASE_INFO.md). + Systemkatalogtabellen (PG) und andere Amazon-Redshift-Systemtabellen sind in einer Transaktion nicht gesperrt. Daher sind Änderungen an Datenbankobjekten, die aufgrund von DDL- und TRUNCATE-Transaktionen entstanden sind, beim Commit für alle gleichzeitigen Transaktionen erkennbar. Angenommen, Tabelle A ist in der Datenbank vorhanden, wenn zwei gleichzeitige Transaktionen, T1 und T2, gestartet werden. Angenommen, T2 gibt eine Liste von Tabellen zurück, indem Sie aus der Katalogtabelle PG\$1TABLES auswählen. Dann löscht T1 Tabelle A und Commits, und dann listet T2 die Tabellen erneut auf. Tabelle A ist jetzt nicht mehr aufgeführt. Wenn T2 versucht, eine Abfrage für die entfernte Tabelle auszuführen, gibt Amazon Redshift den Fehler „Beziehung nicht vorhanden“ zurück. Die Katalogabfrage, die die Liste von Tabellen an T2 zurückgibt oder überprüft, ob Tabelle A vorhanden ist, unterliegt nicht denselben Isolierungsregeln wie Operationen in Benutzertabellen. Transaktionen für Aktualisierungen dieser Tabellen werden im Isolierungsmodus read committed ausgeführt. + PG-prefix-Katalogtabellen unterstützen die SNAPSHOT-Isolierung nicht. # 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-Befehle, die Ladevorgänge ausführen (anfänglich oder inkrementell) + INSERT-Befehle, die jeweils mindestens eine Zeile anfügen + UPDATE-Befehle, die vorhandene Zeilen ändern + DELETE-Befehle, die vorhandene Zeilen entfernen 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; 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. # Beispiele für gleichzeitige Schreibvorgänge In den folgenden Pseudocode-Beispielen wird gezeigt, wie Transaktionen entweder fortgesetzt werden oder warten, wenn sie gleichzeitig ausgeführt werden. ## Beispiele für gleichzeitige Schreiboperationen ### Gleichzeitige COPY-Operationen für dieselbe Tabelle mit serialisierbarer Isolierung Transaktion 1 kopiert Zeilen in die Tabelle LISTING: ``` begin; copy listing from ...; end; ``` Transaktion 2 wird gleichzeitig in einer getrennten Sitzung gestartet und versucht, mehr Zeilen in die Tabelle LISTING zu kopieren. Transaktion 2 muss warten, bis Transaktion 1 die Schreibsperre für die Tabelle LISTING aufhebt. Anschließend kann sie fortgesetzt werden. ``` begin; [waits] copy listing from ; end; ``` Dasselbe Verhalten würde auftreten, wenn eine oder beide Transaktionen anstelle eines COPY-Befehls einen INSERT-Befehl enthalten. ### Gleichzeitige DELETE-Operationen aus derselben Tabelle mit serialisierbarer Isolierung Transaktion 1 löscht Zeilen aus einer Tabelle: ``` begin; delete from listing where ...; end; ``` Transaktion 2 wird gleichzeitig gestartet und versucht, in derselben Tabelle Zeilen zu löschen. Die Transaktion ist erfolgreich, da sie auf den Abschluss von Transaktion 1 wartet, bevor sie versucht, Zeilen zu löschen. ``` begin [waits] delete from listing where ; end; ``` Dasselbe Verhalten würde auftreten, wenn eine oder beide Transaktionen anstelle eines DELETE-Befehls einen UPDATE-Befehl für dieselbe Tabelle enthalten. ### Gleichzeitige Transaktionen mit einer Mischung aus Lese- und Schreiboperationen mit serialisierbarer Isolierung In diesem Beispiel löscht Transaktion 1 Zeilen aus der Tabelle USERS, lädt die Tabelle neu und führt eine COUNT(\$1)-Abfrage und anschließend ANALYZE aus, bevor sie einen Commit ausführt: ``` begin; delete one row from USERS table; copy ; select count(*) from users; analyze ; end; ``` In der Zwischenzeit wird Transaktion 2 gestartet. Diese Transaktion versucht, zusätzliche Zeilen in die Tabelle USERS zu kopieren, die Tabelle zu analysieren und anschließend dieselbe COUNT(\$1)-Abfrage wie die erste Transaktion auszuführen: ``` begin; [waits] copy users from ...; select count(*) from users; analyze; end; ``` Die zweite Transaktion ist erfolgreich, da sie auf den Abschluss der ersten Transaktion warten muss. Die COUNT-Abfrage gibt die Zahl basierend auf dem abgeschlossenen Ladevorgang zurück. ## Beispiele für gleichzeitige Schreiboperationen mit Snapshot-Isolierung ### Gleichzeitige COPY-Operationen für dieselbe Tabelle mit Snapshot-Isolierung Transaktion 1 kopiert Zeilen in die Tabelle LISTING: ``` begin; copy listing from ...; end; ``` Transaktion 2 wird gleichzeitig in einer getrennten Sitzung gestartet und versucht, mehr Zeilen in die Tabelle LISTING zu kopieren. Transaktion 2 kann gleichzeitig ausgeführt werden, bis eine der Transaktionen Daten in die Zieltabelle `listing` schreiben muss. Danach werden sie sequenziell ausgeführt. ``` begin; //When the COPY statement from T1 needs to write data to the table, the COPY statement from T2 waits. copy listing from ...; end; ``` Dasselbe Verhalten würde auftreten, wenn eine oder beide Transaktionen anstelle eines COPY-Befehls einen INSERT-Befehl enthalten. ### Gleichzeitige DELETE-Operationen für dieselbe Tabelle mit Snapshot-Isolierung Gleichzeitige DELETE- oder UPDATE-Operationen aus derselben Tabelle mit Snapshot-Isolierung werden wie Operationen mit serialisierbarer Isolierung ausgeführt. ### Gleichzeitige Transaktionen mit einer Mischung aus Lese- und Schreiboperationen mit Snapshot-Isolierung Gleichzeitige Transaktionen, die mit gemischten Operationen mit Snapshot-Isolierung ausgeführt werden, werden wie Transaktionen mit gemischten Operationen ausgeführt, die mit serialisierbarer Isolierung ausgeführt werden. # Beheben von Fehlern für die serialisierbare Isolierung ## FEHLER: 1023 DETAIL: Serialisierbare Isolationsverletzung für eine Tabelle in Redshift Wenn Amazon Redshift einen Fehler für die serialisierbare Isolierung erkennt, wird Ihnen eine Fehlermeldung ähnlich der folgenden Fehlermeldung angezeigt. ``` ERROR:1023 DETAIL: Serializable isolation violation on table in Redshift ``` Um einen Fehler für die serialisierbare Isolierung zu beheben, können Sie die folgenden Methoden anwenden: + Wiederholen der abgebrochenen Transaktion. Amazon Redshift hat festgestellt, dass ein gleichzeitiger Workload nicht serialisierbar ist. Dies weist auf Lücken in der Anwendungslogik hin, die normalerweise bearbeitet werden können, indem die Transaktion erneut versucht wird, bei der der Fehler aufgetreten ist. Wenn das Problem weiterhin besteht, wenden Sie eine der anderen Methoden an. + Verschieben Sie alle Operationen, die sich nicht in derselben atomaren Transaktion befinden müssen, aus der Transaktion. Diese Methode kann angewendet werden, wenn sich einzelne Operationen innerhalb von zwei Transaktion gegenseitig so referenzieren, dass das Ergebnis der jeweils anderen Transaktion beeinflusst werden kann. Die folgenden beiden Sitzungen starten beispielsweise jeweils eine Transaktion. ``` Session1_Redshift=# begin; ``` ``` Session2_Redshift=# begin; ``` Das Ergebnis einer SELECT-Anweisung in einer der beiden Transaktionen könnte durch eine INSERT-Anweisung in der jeweils anderen Transaktion beeinflusst werden. Angenommen, Sie führen die folgenden Anweisungen seriell in beliebiger Reihenfolge aus. In jedem Fall besteht das Ergebnis darin, dass eine der SELECT-Anweisungen eine Zeile mehr zurückgibt, als dies bei einer gleichzeitigen Ausführung der Transaktionen der Fall wäre. Es gibt keine Reihenfolge, in der die Operationen seriell ausgeführt werden können und zum gleichen Ergebnis wie bei einer gleichzeitigen Ausführung führen. Daher führt die zuletzt ausgeführte Operation zu einem Fehler für die serialisierbare Isolierung. ``` Session1_Redshift=# select * from tab1; Session1_Redshift=# insert into tab2 values (1); ``` ``` Session2_Redshift=# insert into tab1 values (1); Session2_Redshift=# select * from tab2; ``` In vielen Fällen ist das Ergebnis der SELECT-Anweisungen nicht wichtig. Mitanderen Worten: Die Atomizität der Operationen in den Transaktionen ist nicht wichtig. In diesen Fällen verschieben Sie die SELECT-Anweisungen aus den Transaktionen wie in den folgenden Beispielen gezeigt. ``` Session1_Redshift=# begin; Session1_Redshift=# insert into tab1 values (1) Session1_Redshift=# end; Session1_Redshift=# select * from tab2; ``` ``` Session2_Redshift # select * from tab1; Session2_Redshift=# begin; Session2_Redshift=# insert into tab2 values (1) Session2_Redshift=# end; ``` In diesen Beispielen gibt es keine Querbezüge in den Transaktionen. Die beiden INSERT-Anweisungen beeinflussen sich nicht gegenseitig. In diesen Beispielen gibt es mindestens eine Reihenfolge, in der die Transaktionen seriell ausgeführt werden können und zum gleichen Ergebnis wie bei einer gleichzeitigen Ausführung führen. Das bedeutet, dass die Transaktionen serialisierbar sind. + Sie können die Serialisierung erzwingen, indem Sie alle Tabellen in jeder Sitzung sperren. Der Befehl [LOCK](r_LOCK.md) blockiert Operationen, die zu Fehlern für die serialisierbare Isolierung führen können. Wenn Sie den Befehl LOCK verwenden, müssen Sie Folgendes ausführen: + Sperren Sie alle Tabellen, die von der Transaktion betroffen sind, einschließlich Tabellen, die von schreibgeschützten SELECT-Anweisungen innerhalb der Transaktion betroffen sind. + Sperren Sie die Tabellen in derselben Reihenfolge, unabhängig von der Reihenfolge, in der die Operationen ausgeführt werden. + Sperren Sie alle Tabellen zu Beginn der Transaktion, bevor Operationen ausgeführt werden. + Verwenden Sie die Snapshot-Isolation für gleichzeitige Transaktionen Verwenden Sie einen ALTER DATABASE-Befehl mit Snapshot-Isolation. Weitere Informationen zum SNAPSHOT-Parameter für ALTER DATABASE finden Sie unter [Parameters](r_ALTER_DATABASE.md#r_ALTER_DATABASE-parameters). ## FEHLER: 1018 DETAIL: Beziehung existiert nicht Wenn Sie Amazon-Redshift-Vorgänge in verschiedenen Sitzungen ausführen, wird Ihnen eine Fehlermeldung ähnlich der folgenden Fehlermeldung angezeigt. ``` ERROR: 1018 DETAIL: Relation does not exist. ``` Transaktionen in Amazon Redshift folgen der Snapshot-Isolation. Nachdem eine Transaktion gestartet wurde, erstellt Amazon Redshift einen Snapshot der Datenbank. Während des gesamten Lebenszyklus der Transaktion arbeitet die Transaktion mit dem Status der Datenbank, wie sie im Snapshot wiedergegeben wird. Wenn die Transaktion aus einer Tabelle liest, die nicht im Snapshot vorhanden ist, wird die zuvor angezeigte Fehlermeldung 1018 ausgelöst. Selbst wenn eine andere gleichzeitige Transaktion eine Tabelle erstellt, nachdem die Transaktion den Snapshot erstellt hat, kann die Transaktion nicht aus der neu erstellten Tabelle lesen. Um diesen Serialisierungsisolationsfehler zu beheben, können Sie versuchen, den Start der Transaktion an einen Punkt zu verschieben, an dem Sie wissen, dass die Tabelle existiert. Wenn die Tabelle von einer anderen Transaktion erstellt wird, liegt dieser Punkt nach dem Commit dieser Transaktion. Stellen Sie außerdem sicher, dass gleichzeitig für keine Transaktion ein Commit durchgeführt wurde, das die Tabelle möglicherweise gelöscht hat. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session2 = # BEGIN; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # SELECT * FROM A; ``` Daher führt die zuletzt von session2 als Lesevorgang ausgeführte Operation zu einem serialisierbaren Isolierungsfehler. Dieser Fehler tritt auf, wenn session2 einen Snapshot erstellt und die Tabelle bereits von einer festgeschriebenen session1 gelöscht wurde. Mit anderen Worten, obwohl eine gleichzeitige session3 die Tabelle erstellt hat, sieht session2 die Tabelle nicht, da sie sich nicht im Snapshot befindet. Um diesen Fehler zu beheben, können Sie die Sitzungen wie folgt neu anordnen. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # BEGIN; session2 = # SELECT * FROM A; ``` Wenn nun session2 seinen Snapshot erstellt, wurde für session3 bereits ein Commit ausgeführt, und die Tabelle befindet sich in der Datenbank. Session2 kann fehlerfrei aus der Tabelle lesen.