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:

• COPYBefehle, die Ladevorgänge (initiale oder inkrementelle) ausführen

• INSERTBefehle, die eine oder mehrere Zeilen gleichzeitig anhängen

• UPDATEBefehle, die bestehende Zeilen ändern

• DELETEBefehle, die Zeilen entfernen

COPYund INSERT Operationen sind reine Schreiboperationen, aber DELETE und UPDATE Operationen sind Lese-/Schreiboperationen. (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. COPYund INSERT Operationen an derselben Tabelle werden in einem Wartezustand gehalten, bis die Sperre aufgehoben wird. Dann werden sie wie gewohnt fortgesetzt.

UPDATEund DELETE Operationen verhalten sich anders, weil sie darauf angewiesen sind, dass die Tabelle zuerst gelesen wird, bevor sie irgendwelche Schreibvorgänge ausführen. Angesichts der Tatsache, dass gleichzeitige Transaktionen für beide Seiten unsichtbar sind UPDATEs und DELETEs eine Momentaufnahme der Daten aus dem letzten Commit lesen müssen. Wenn die erste UPDATE oder ihre DELETE Sperre aufhebt, DELETE muss die zweite UPDATE oder feststellen, ob die Daten, mit denen sie arbeiten soll, potenziell 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

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 ein 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 einen Schreibvorgang für Tabelle A startet und T2 einen Schreibvorgang für Tabelle B startet, können beide Transaktionen konfliktfrei ausgeführt werden. Wenn T1 jedoch den Schreibvorgang für Tabelle A beendet und einen Schreibvorgang für Tabelle V starten muss, kann die Transaktion nicht fortgesetzt werden, da T2 Tabelle B noch nicht freigegeben hat. Wenn umgekehrt T2 den Schreibvorgang für Tabelle B beendet und einen Schreibvorgang für Tabelle A starten muss, kann die Transaktion auch nicht fortgesetzt werden, da T1 Tabelle A noch nicht freigegeben hat. Da keine der beiden Transaktionen ihre Sperren aufheben kann, solange nicht für alle ihre Schreibvorgänge ein Commit ausgeführt wurde, kann keine der beiden Transaktionen fortgesetzt werden.

Um diese Art von Deadlock zu vermeiden, müssen Sie gleichzeitige Schreibvorgänge sorgfältig planen. Beispielsweise sollten Sie Tabellen in Transaktionen immer in derselben Reihenfolge aktualisieren und, falls Sie Sperren angeben, die Tabellen in derselben Reihenfolge sperren, bevor Sie irgendwelche DML Operationen ausführen.