Transaktionssystem

Ziel eines transaktionsbasierten Systems ist die Bewahrung vollständiger Transaktionssicherheit, d.h. jede Transaktion soll ein korrektes Ergebnis liefern und die Datenbank in einem konsistenten Zustand belassen. Um dies zu gewährleisten, müssen Transaktionen die sogenannten ACID-Prinzipien erfüllen:

• Atomarität (Atomicity): Eine Transaktion wird entweder ganz oder gar nicht ausgeführt. Transaktionen sind also „unteilbar“. Wenn eine atomare Transaktion abgebrochen wird, ist das System unverändert.
• Konsistenz (Consistency): Eine Transaktion überführt den Datenbestand aus einem konsistenten Zustand in den anderen.
• Isolation (Isolation): Bei gleichzeitiger Ausführung mehrerer Transaktionen dürfen sich diese nicht gegenseitig beeinflussen.
• Dauerhaftigkeit (Durability): Die Auswirkungen einer Transaktion müssen im Datenbestand dauerhaft bestehen bleiben. Die Effekte von Transaktionen dürfen also nicht „mit der Zeit verblassen“ oder „aus Versehen verloren gehen“.

Um das Einhalten der ACID-Prinzipien zu gewährleisten, unterliegt jede Transaktion einer Überprüfung durch das TMS. Das TMS greift - falls erforderlich - selbsttätig ein und behebt Konflikte durch das Erzwingen von Wartezeiten oder durch das Zurückrollen (Rollback) von kollidierenden Transaktionen.

Einige andere Datenbanksysteme haben das Transaktionsmodell nur partiell implementiert und verbergen teilweise Transaktionen vor dem Nutzer. So werden z.B. Schema-Statements ( “CREATE SCHEMA”, “CREATE TABLE”, ...) unmittelbar vom System persistent in der Datenbank gespeichert. Dies verringert bei gleichzeitiger Ausführung von Transaktionen mit Schema-Statements die Kollisionsgefahr, hat aber den Nachteil, dass z.B. ein “ROLLBACK” die durchgeführten Schema-Statements nicht wieder rückgängig machen kann.

Einige Transaktionen können dadurch in einen inkonsistenten Zustand geraten, z.B. kann einem Ladeskript eine Tabelle durch eine andere Transaktion "entzogen" werden.

Das TMS in EXASolution verbirgt keine Transaktionen vor dem Nutzer und speichert keine Statements automatisch persistent in der Datenbank. Alle Operationen unterliegen somit dem ACID-Prinzip

• Database definition: create/alter schema, table, view
• User management: create/alter user, role
• Data manipulation: insert/update/delete
• Data query: select

Pro:

• Während eine Transaktion läuft, bleibt ihre Sicht auf die Datenbank konstant
• Alle Änderungen (auch Statements wie CREATE TABLE, DROP TABLE oder TRUNCATE TABLE) können zurückgerollt werden

Con:

• Es können mehr Konflikte entstehen

Um die Anzahl der kollidierenden Transaktionen so gering wie möglich zu halten, unterstützt EXASolution das sog. "MultiCopy-Format". Dies bedeutet, dass von jedem Datenbankobjekt (temporär) mehrere Versionen existieren können. Auf diese Weise kann der Systemdurchsatz (Anzahl der vollständig ausgeführten Transaktionen pro Zeiteinheit) gegenüber von Datenbanken im SingleCopy-Format erheblich gesteigert werden.

Die einzelnen Transaktionen werden vom TMS durch ein Sperrverfahren voneinander isoliert. Die Granularität bei diesem Sperrverfahren umfasst dabei immer ein ganzes Datenbankobjekt wie z.B. ein Schema oder eine Tabelle. Dies bedeutet insbesondere, dass zwei Transaktionen nicht gleichzeitig verschiedene Zeilen derselben Tabelle aktualisieren können.

EXASolution unterstützt nur den Isolation Level "SERIALIZABLE".

Ein Transaktionssystem muss sicher stellen, dass möglichst viele Transaktionen in möglichst kurzer Zeit abgewickelt werden. Die serielle Ausführung von Transaktionen – also die Ausführung der Transaktionen nacheinander – ist zwar einfach zu realisieren, führt aber oft nicht zu einer optimalen Erfüllung dieses Leistungskriteriums. Transaktionssysteme spalten daher Transaktionen in ihre Operationen auf und setzen diese zu Historien zusammen, wobei selbstverständlich die ACID-Eigenschaften bewahrt bleiben müssen. Durch diesen Vorgang ergeben sich zwei Möglichkeiten, eine Transaktion zu beenden:

Commit: Die Transaktion wurde erfolgreich und ohne Probleme beendet, die Auswirkungen der Transaktion auf den Datenbestand werden dauerhaft gespeichert.

Abort: Bei der Ausführung der Transaktion sind Probleme aufgetreten, ihre Ausführung wird nicht fortgesetzt. Die Bedingung der Atomarität fordert zusätzlich, dass sämtliche Auswirkungen der Transaktion auf den Datenbestand rückgängig gemacht werden müssen. Das Rückgängigmachen der Effekte einer Transaktion wird als Rollback (Zurücksetzen) bezeichnet.

Wenn eine Transaktion aufgrund einer anderen Transaktion nicht ausgeführt werden kann, spricht man von einer Blockierung.

Es gibt 2 Arten von Kollisionen:

• Read/write-Konflikt:
  Zwei Transaktionen haben ein Objekt zuerst gelesen und wollen es nun verändern. Da sich diese Operationen nicht atomar in eine feste Reihenfolge bringen lassen (eine der beiden Leseoperationen wäre ungültig), muss eine der beteiligten Transaktionen zurückgerollt werden.

• Write/write-Konflikt:
  Ist im Gegensatz zu obigem Beispiel kein Lesevorgang vorausgegangen, können die Schreiboperationen in eine (beliebige) Reihenfolge gebracht werden. Allerdings muss eine der Transaktionen warten, bis die andere zu Ende ist (WAIT FOR COMMIT). Dies stellt die Konsistenz der Änderungen sicher.

Das TMS löst solche Konflikte durch zurückrollen einer der beteiligten Transaktionen. Gegenwärtig führen auch lokale Fehler bei DML-Statements zu einem Rollback, um die Konsistenz der paralellen Verarbeitung zu gewährleisten.