Transaktionen

Mit dem Begriff Transaktion wird eine Folge von SQL-Kommandos verstanden, die direkt hintereinander bearbeitet werden. Diese Anweisungen sind in einen Block eingeschlossen, der Beginn und Ende der Anweisungsfolge kennzeichnet. Die Abarbeitung einer Transaktion kann nicht von einerm anderen Prozess unterbrochen werden. Wenn alle Kommandos aus dem Block ausgeführt sind, werden die Änderungen in die Datenbank geschrieben. Dieser Schreibvorgang heisst COMMIT. Erst jetzt sind die Änderungen allen anderen Benutzern zugänglich. Bricht die Verarbeitung eines Transaktionsblocks wegen eines Fehlers ab, dann werden alle Modifikationen dieser Transaktion verworfen und es findet kein Schreibvorgang statt. Die Datenbank behält somit den ursprünglichen Zustand. In diesem Fall spricht man von einem ROLLBACK, weil die Änderungen der Transaktion wieder zurückgesetzt oder zurückgerollt werden.

Transaktionen arbeiten nach dem Alles-oder-Nichts-Prinzip, sie werden entweder vollständig und fehlerfrei oder gar nicht ausgeführt.

Allgemein lassen sich die Forderungen, denen eine Transaktion genügen muss, durch das ACID-Prinzip beschreiben. Dies ist eine Abkürzung für die Begriffe:

• Atomicity, Unteilbarkeit: Eine Transaktion ist eine unteilbare Verarbeitungseinheit. Sie wird entweder ganz oder gar nicht ausgeführt.
• Consistency, Konsistenz: Eine Transaktion muss eine Datenbank von einem konsistenten Zustand wieder in einen konsistenten Zustand überführen.
• Isolation, Isolierung: Eine Transaktion muss so ablaufen, als sei sie die einzige im System. Zwischenzustände von Transaktionen dürfen für andere Transaktionen nicht sichtbar sein.
• Durability, Dauerhaftigkeit: Änderungen einer erfolgreich beendeten Transaktion sind dauerhaft gespeichert und überleben den nächsten Fehler.

PostgreSQL verwendet MVCC (Multi-Version Concurrency Control) als Strategie für das Transaktionsmanagement. Das bedeutet, dass jeder Transaktion eine eigene Kopie des Momentanzustands der Datenbank zur Verfügung gestellt wird. Auf diesem Schnappschuss kann sie ihre Modifikationen durchführen und muss dabei nie auf Zugriffe von andern Transaktionen warten. Am Ende der Transaktion werden die Änderungen mit einem COMMIT in die Datenbank geschrieben. Erst zum Zeitpunkt des Schreibens können Kollisionen mit anderen Transaktionen auftreten, wenn zwei Transaktionen konkurrierend denselben Datensatz beschreiben wollen. In diesem Fall werden, in Abhänngigkeit von der eingestellten Isolationsstufe fuer Transaktionen, entweder Wartezeiten erzwungen oder Transaktionen abgebrochen.