Transaktionen
CONZEPT 16-Server - Transaktionen Beschreibung der Transaktionsverarbeitung
Transaktionen sind eine zusammengehörige Menge von Datenbankoperationen. Diese werden zunächst im Datenbankcache verarbeitet. Den Transaktionen werden die Inhalte des ACID-Prinzips zugrunde gelegt.
- A tomicity: Atomizität Eine Transaktion wird vollständig in der Datenbank gespeichert oder gar nicht.
- C onsistency: Konsistenz Nach der Transaktion ist der Datenbestand widerspruchsfrei.
- I solation: Isolation Mehrere Transaktionen beeinflussen sich nicht gegenseitig.
- D urability: Dauerhaftigkeit Eine beendete Transaktion bleibt in der Datenbank bestehen.
Transaktionsressourcen
Der Datenbank-Prozess nutzt eine Reihe von Ressourcen, um den Datenbankbetrieb und damit auch das Transaktionsmanagement korrekt durchführen zu können. Zunächst fordert jeder Datenbank-Prozess die konfigurierte Menge an Datenbankcache an. Der Cache wird verwendet, um Datenbanksegmente zwischenzuspeichern und die Zugriffszeiten darauf zu verkürzen. Zudem verarbeitet der Cache die Datenbanktransaktionen. Dabei werden laufende und abgeschlossene Transaktionen im Cache vorgehalten. Sollte der Cache für die Transaktionen nicht ausreichen, lagert der Datenbank-Prozess Informationen in einer temporären Transaktionsdatei mit dem Namen <Datenbankname>.trs aus.
Transaktionsverklemmungen
Wenn der Inhalt einer Datenbank verändert wird, findet dies immer auf Segment-Ebene statt. Eine Transaktion setzt sich aus einer zusammengehörigen Menge von geänderten Segmenten zusammen. Falls zwei Benutzer verschiedene Segmente durch ihre Transaktion sperren und jeweils auf die Freigabe der Segmente des anderen warten, entsteht eine Verklemmung. Diese Verklemmungen erkennt der CONZEPT 16-Server automatisch und löst sie auf. Dazu wird eine Transaktion durchgeführt und die andere abgebrochen. Abgebrochen wird dabei immer die kleinere Transaktion. Entsteht keine Verklemmung, sondern nur ein Wartezustand (Sperrkonflikt), zeigt dies der CONZEPT 16-Client dem Anwender an.
Ablauf von Transaktionen
Offene Transaktionen befinden sich immer im Datenbankcache oder in der ausgelagerten temporären Transaktionsdatei. Abgeschlossene Transaktionen werden mindestens alle 30 Sekunden in die Datenbank übertragen. Falls der Datenbankcache zu 80% mit abgeschlossenen Transaktionen gefüllt ist, bevor die 30 Sekunden vergangen sind, wird das Übertragen der abgeschlossenen Transaktionen vorgezogen.
Das Schreiben von abgeschlossenen Transaktionen in die Datenbank wird Update-Ereignis genannt. Ein Update-Ereignis wird in mehrere zeitlich versetzte Schritte untergliedert, um zu jeder Zeit die Konsistenz der Datenbank zu gewährleisten. Beim Ausführen des Update-Ereignisses dürfen die abgeschlossenen Transaktionen nicht einfach in die Datenbank übertragen werden, da ein Ausfall des Servers während der Übertragung die Datenbank in einen inkonsistenten Zustand bringen würde. Abgeschlossene Transaktionen könnten in diesem Fall nur teilweise und damit fehlerhaft in die Datenbank gelangt sein.
Um dies zu verhindern, werden alle Segmente eines Update-Ereignisses zunächst extern in eine Transaktionslog-Datei geschrieben (<Datenbankname>.tl1). Dies ist notwendig, damit alle abgeschlossenen Transaktionen auf der Festplatte gesichert sind. Erst danach findet das Übertragen der Transaktionen in die Datenbank statt. Fällt dabei der Server aus, kann aus den Segmenten in der externen Transaktionslog-Datei die Konsistenz der Datenbank nachträglich wiederhergestellt werden und die Daten sind nicht verloren. Der CONZEPT 16-Server sichert dabei zyklisch die letzten drei Transaktionslog-Dateien (*.tl1, *.tl2, *.tl3).
Rollback
Falls der Datenbankserver im laufenden Datenbankbetrieb ausfällt, kann dieser die Datenbank nicht mehr korrekt schließen. Das bedeutet, dass die abgeschlossenen Transaktionen des letzten Update-Ereignisses möglicherweise noch nicht oder nicht komplett in die Datenbank übertragen wurden.
Nun muss vom Datenbankserver sichergestellt werden, dass die Datenbank in einem konsistenten Zustand ist. Dazu wird beim nächsten Öffnen der Datenbank die letzte Transaktionslog-Datei in die Datenbank übertragen. Dadurch werden alle abgeschlossenen Transaktionen des letzten Update-Ereignisses nochmals korrekt in die Datenbank übernommen. Alle Daten des letzten Update-Ereignisses werden so wiederhergestellt und die Datenbank ist wieder in einem konsistenten Zustand.
Falls der Datenbankserver ausfällt, während die Transaktionslog-Datei geschrieben wird, liest der CONZEPT 16-Server diese nicht ein, da sie möglicherweise unvollständige Transaktionen enthält. Alle Daten des vorherigen Update-Ereignisses befinden sich bereits in der Datenbank, da dies vom Datenbankserver sichergestellt wird, bevor das nächste Update-Ereignis ausgelöst wird.
Generell muss beachtet werden, dass alle offenen und auch alle abgeschlossenen Transaktionen verloren gehen, die sich zum Zeitpunkt des Serverausfalls im Datenbankcache und der ausgelagerten, temporären Transaktionsdatei befinden.
Ein Rollback kann nur vorgenommen werden, wenn die Transaktionslog-Dateien in der Konfiguration der Datenbank aktiviert sind. Nach dem Rollback wird automatisch eine Diagnose mit Recover gestartet.
Werden nach einem Serverabsturz Fehler im Dateisystem festgestellt, müssen diese vor einem erneuten Öffnen der Datenbank beseitigt werden, damit Probleme beim Rollback durch äußere Einwirkungen minimiert werden können. Beim Betrieb von Festplatten, bzw. RAID-Controllern mit verzögertem Schreiben, also eigenem Schreib-Cache, muss sichergestellt werden, dass keine Datenverluste an den jeweiligen Stellen entstehen können (zum Beispiel über Batteriebackups oder eine unterbrechungsfreie Stromversorgung (USV)).
Transaktionen während Sicherungsereignissen
Der CONZEPT 16-Server kann Datenbanken in einen Sicherungszustand versetzen. (Siehe Sicherungsereignisse ) Dazu wird die Datenbank im Read-Only Modus betrieben. Alle in dieser Zeit abgeschlossenen Transaktionen können dann natürlich nicht direkt in die Datenbank übertragen werden.
Während eines Backup-Ereignisses werden keine Update-Ereignisse durchgeführt. Alle abgeschlossenen Transaktionen werden im Datenbankcache und der temporären Transaktionsdatei gesichert. Während eines Backup-Ereignisses werden trotzdem wie bei einem Update-Ereignis alle abgeschlossenen Transaktionen in eine Transaktionslog-Datei geschrieben, damit bei einem Serverausfall die Daten wiederhergestellt werden können. Hierbei wird aber fortlaufend nur in die aktuelle Transaktionslog-Datei geschrieben. Ein zyklischer Wechsel findet nicht statt, da sonst nach einem Zyklus Transaktionslog-Dateien überschrieben werden.
Zu Beachten ist daher natürlich auch, dass die aktuelle Transaktionslog-Datei und die temporäre Transaktionsdatei bei längeren Backup-Ereignissen sehr groß werden können.
Nach dem Backup-Ereignis werden alle abgeschlossenen Transaktionen aus dem Cache und der temporären Transaktionsdatei in die Datenbank geschrieben. Falls der Server nun während des Sicherungsereignisses abstürzt, würde unter normalen Umständen kein Rollback durchgeführt werden, da die Datenbank in einem korrekt geschlossenen Zustand vorliegt. Die Transaktionslog-Dateien enthalten den Updatezähler und Zeitstempel der Datenbank, sowie eine Seriennummer. Stimmen der Zeitstempel und der Updatezähler der Datenbank mit denen der Transaktionslog-Datei überein und hat diese die Seriennummer 1, muss diese noch in die Datenbank eingelesen werden. Wird beim Öffnen der Datenbank eine solche Datei vorgefunden, erkennt der Datenbankserver, dass ein Backup-Ereignis nicht korrekt beendet wurde und noch abgeschlossene Transaktionen aus der letzten Transaktionslog-Datei in die Datenbank eingefügt werden müssen.
Alle temporären Dateien werden standardmäßig im Transaktionsverzeichnis der Datenbank abgelegt. In der Datenbankkonfiguration kann dieses Verzeichnis angegeben werden. Wird dieses Verzeichnis nicht angegeben, ist das Verzeichnis der Datenbank auch zugleich das Transaktionsverzeichnis.