Das Beheben von Fehlerbedingungen ist eine normale Aufgabe bei der Anwendungsprogrammierung, Systemverwaltung, Datenbankverwaltung sowie beim Systembetrieb. Durch die Verteilung von Datenbanken über mehrere ferne Server erhöht sich das Potential von Fehlerbedingungen, die aus Netzwerk- oder Übertragungsstörungen resultieren können. Um die Datenintegrität zu gewährleisten, stellt der Datenbankmanager den Prozeß der zweiphasigen Festschreibung zur Verfügung. Eine Darstellung dieses Prozesses finden Sie in Prozeß der zweiphasigen Festschreibung (siehe Punkte (10), (11) und (12)). Im folgenden wird erläutert, wie Datenbankmanager Fehler während des Prozesses der zweiphasigen Festschreibung behandelt:
Wenn eine Datenbank mitteilt, daß sie die Festschreibung der Arbeitseinheit nicht vorbereiten (und kein "PREPARED" in die Protokolldatei eintragen) konnte, macht der Datenbank-Client die Arbeitseinheit in der zweiten Phase des Festschreibungsprozesses rückgängig. In diesem Fall wird keine PREPARE-Nachricht an die Transaktionsmanagerdatenbank gesendet.
Während der zweiten Phase der Festschreibung weist der Client alle beteiligten Datenbanken, die während der ersten Phase die Festschreibung erfolgreich vorbereitet haben, an, die Arbeitseinheit rückgängig (ROLLBACK) zu machen. Jede Datenbank schreibt daraufhin einen Satz "ABORT" in ihre Protokolldatei und gibt die Sperren frei, die für diese Arbeitseinheit aktiv waren.
Die Fehlerbehandlung ist in diesem Fall davon abhängig, ob die Transaktion in der zweiten Phase festgeschrieben oder rückgängig gemacht wird. Die zweite Phase macht die Transaktion nur dann rückgängig, wenn in der ersten Phase ein Fehler auftrat.
Wenn eine der beteiligten Datenbanken die Arbeitseinheit nicht festschreiben kann (u. U. aufgrund eines Übertragungsfehlers), versucht die Transaktionsmanagerdatenbank erneut, für die fehlgeschlagene Datenbank eine Festschreibung auszuführen. Die Anwendung wird jedoch über den SQL-Kommunikationsbereich (SQLCA) darüber informiert, daß die Festschreibung erfolgreich war. DB2 stellt sicher, daß die nicht festgeschriebene Transaktion im Datenbank-Server festgeschrieben wird. Mit Hilfe des Konfigurationsparameters resync_interval des Datenbankmanagers (siehe Kapitel 32, Konfigurieren von DB2) wird das Intervall festgelegt, das die Transaktionsmanagerdatenbank zwischen den einzelnen Versuchen, die Arbeitseinheit festzuschreiben, verstreichen läßt. Alle Sperren bleiben auf dem Datenbank-Server aktiv, bis die Arbeitseinheit festgeschrieben wird.
Fällt Transaktionsmanagerdatenbank aus, resynchronisiert sie die Arbeitseinheit, wenn sie erneut gestartet wird. Der Resynchronisationsprozeß versucht, alle unbestätigten Transaktionen zu beenden, d. h. die Transaktionen, die die erste Phase der Festschreibung beendet haben, deren zweite Phase jedoch nicht abgeschlossen wurde. Der Datenbankmanager, unter dem die Transaktionsmanagerdatenbank aktiv ist, führt zur Resynchronisation folgende Schritte aus:
Wenn bei einer der beteiligten Datenbanken ein Fehler auftritt und die Datenbank erneut gestartet wird, fragt der Datenbankmanager für diese Datenbank die Transaktionsmanagerdatenbank nach dem Status dieser Transaktion ab, um festzustellen, ob die Transaktion rückgängig gemacht werden sollte. Wenn die Transaktion im Protokoll nicht gefunden wird, nimmt der Datenbankmanager an, daß die betreffende Transaktion rückgängig gemacht wurde, und macht die unbestätigte Transaktion in dieser Datenbank rückgängig. Andernfalls wartet die Datenbank auf eine Festschreibungsanforderung der Transaktionsmanagerdatenbank.
Wenn die Transaktion von einem Transaktionsverarbeitungsmonitor (XA-konformem Transaktionsmanager) koordiniert wurde, ist die Datenbank immer davon abhängig, daß die Resynchronisation vom TP-Monitor eingeleitet wird.
Wenn Sie aus einem bestimmten Grund nicht darauf warten können, daß der Transaktionsmanager unbestätigte Transaktionen automatisch auflöst, haben Sie die Möglichkeit, Maßnahmen zur manuellen Auflösung unbestätigter Transaktionen zu ergreifen. Dieser manuelle Prozeß wird manchmal als das "Treffen einer heuristischen Entscheidung" bezeichnet. Weitere Informationen zur manuellen Wiederherstellung unbestätigter Transaktionen finden Sie in Treffen einer heuristischen Entscheidung.
Hinweise zur Konfiguration in einer Umgebung von DB2 Universal Database mit zweiphasiger Festschreibung finden Sie in Weitere Überlegungen zur Konfiguration.
Insbesondere ist zu beachten, daß, wenn der Konfigurationsparameter autorestart der Datenbank den Wert OFF hat und unbestätigte Transaktionen in der Transaktionsmanagerdatenbank oder den Ressourcenmanagerdatenbanken vorhanden sind, der Befehl RESTART DATABASE ausgeführt werden muß, um den Resynchronisationsprozeß zu starten. Wenn der Befehl RESTART DATABASE über den Befehlszeilenprozessor ausgeführt wird, verwenden Sie verschiedene Sitzungen. Wenn Sie eine andere Datenbank aus derselben Sitzung erneut starten, wird die Verbindung, die durch die vorherige Ausführung des Befehls RESTART DATABASE hergestellt wurde, beendet und muß erneut gestartet werden. Setzen Sie den Befehl TERMINATE ab, um die Verbindung zu beenden, wenn der Befehl LIST INDOUBT TRANSACTIONS keine weiteren unbestätigten Transaktionen mehr liefert.