Auswirkungen des Zustands PTC

Bei Ablauf des Zwei-Phasen-Ende-Protokolls wird in der RLOG-Datei der jeweiligen Teiltransaktion protokolliert:

• „Transaktion im Zustand PTC“, wenn eine Teiltransaktion dieser Transaktion im Zustand PTC ist

• „Transaktion mit FINISH beendet“ oder „Transaktion mit FINISH WITH CANCEL beendet“, wenn die primäre Teiltransaktion mit FINISH oder mit FINISH WITH CANCEL beendet wurde.

Siehe Abschnitt „Konfigurationsübergreifende Konsistenz mit dem Zwei-Phasen-Ende-Protokoll sichern“.

Da die RLOG-Datei sessionspezifisch geführt wird, ist es möglich, dass nach normalem DBH-Ende in der Konfiguration der primären Teiltransaktion nicht mehr abgefragt werden kann, wie die primäre Teiltransaktion beendet wurde. Deshalb wird die Information, wie die Transaktion beendet wurde, auch in der DB-Status-Datei hinterlegt, die konfigurationsbezogen geführt wird.

Eine kritische Phase des Zwei-Phasen-Ende-Protokolls ist der Zustand PTC. Die Behandlung einer Teiltransaktion im Zustand PTC steuern Sie über den DBH-Ladeparameter
PP PTCSYNCH.

Der DBH-Ladeparameter PP PTCSYNCH sollte immer auf (WAIT,WAIT) stehen. Nur dann ist die konfigurationsübergreifende Konsistenz bzw. die UDS/SQL-/openUTM-Konsistenz sicher! Der Datenbankadministrator sollte den PTCSYNCH-Wert nur dann auf ABORT oder COMMIT ändern, wenn er in der Lage ist, über die konfigurationsübergreifende Konsistenz zu entscheiden (siehe Abschnitt „Zustand PTC beenden“).

Der Zustand PTC kann sich auswirken:

• während der Session

• bei einem Warmstart

• bei DBH-Ende

• auf das Anwenderprogramm bei logischem Verbindungsverlust

Auswirkungen des Zustands PTC während der Session

Während der Session kann sich der Zustand PTC auswirken

• wenn der UDS-D-Betrieb nach normaler oder abnormaler Beendigung erneut gestartet wird.

• beim Ändern der Datenbank-Konfiguration (siehe Abschnitt „DB-Konfiguration ändern- Hinweise für UDS-D“).
  Wenn sich Teiltransaktionen im Zustand PTC befinden, können Sie die betroffenen Datenbanken nicht konsistent aus der DB-Konfiguration ausschließen.

• beim Festschreiben eines Konsistenzpunkts (siehe Abschnitt „Konsistenzpunkte festschreiben (CHECKPOINT)“).
  Wenn Konsistenzpunkte festgeschrieben werden sollen, muss sichergestellt sein, dass die Verbindung zur Konfiguration der primären Teiltransaktion bzw. zu openUTM vorhanden ist. Denn UDS/SQL schreibt nur Konsistenzpunkte für eine Datenbank, wenn alle Transaktionen, die auf dieser Datenbank geändert haben, beendet sind.

Falls das Festschreiben von Konsistenzpunkten oder das Aus- bzw. Anschließen von Datenbanken bereits eingeleitet ist, aber nicht durchführbar ist wegen Teiltransaktionen im Zustand PTC, dann kann der Datenbankadministrator:

• mit &SYNCHRONIZE DISTRIBUTION bei sekundären Teiltransaktionen die Nachfrage veranlassen, wie die primäre Teiltransaktion beendet wurde. Falls UDS/SQL das Ende der primären Teiltransaktion nicht ermitteln kann, bleibt die sekundäre Teiltransaktion im Zustand PTC.

• mit DISPLAY USERS die Transaktionskennungen der Teiltransaktionen ermitteln, die im Zustand PTC sind, und mit den folgenden DAL-Kommandos diese Teiltransaktion beenden:

  ABORT transaktionskennung,OPTION=PTC
  oder
  COMMIT transaktionskennung
  

  Wenn der Datenbankadministrator mit ABORT,OPTION=PTC oder COMMIT eingreift, ist die konfigurationsübergreifende Konsistenz bzw. die UDS/SQL-openUTM-Konsistenz gefährdet (siehe Abschnitt „Zustand PTC beenden“).

• mit %TERM

  die Session abbrechen und sie anschließend ohne die betroffene Datenbank starten.

Auswirkungen des Zustands PTC bei einem Warmstart 

Bei einem Warmstart werden alle offenen Transaktionen mit Rollback zurückgesetzt. Wenn sich bei einem Warmstart Teiltransaktionen im Zustand PTC befinden, werden sie gemäß dem DBH-Ladeparameter PP PTCSYNCH für Warmstart behandelt.

Wenn dieser bei einer primären Teiltransaktion auf WAIT steht, wird die betroffene Datenbank bei einem Warmstart so lange nicht zugeschaltet, bis openUTM das Transaktionsende fordert.

Wenn dieser bei einer sekundären Teiltransaktion auf WAIT steht, versucht UDS/SQL, die zugehörige primäre Teiltransaktion zu erreichen. Dafür müssen folgende Voraussetzungen erfüllt sein:

• Der UDS-D-Betrieb muss gestartet sein in der Konfiguration der primären und der sekundären Teiltransaktion.

• Die Verteiltabellen müssen den Gegebenheiten im Netz entsprechen.

• Es muss eine Konfiguration mit dem Konfigurationsnamen existieren, unter dem vor dem Session-Abbruch die primäre Teiltransaktion lief.
  Die Konfiguration darf aber anders zusammengesetzt sein und auf einem anderen Verarbeitungsrechner liegen, wenn die Verteiltabellen angepasst sind.

• Die DB-Status-Datei muss in der Konfiguration der primären und in der Konfiguration der sekundären Teiltransaktion vohanden sein.

Wenn der Zustand der zugehörigen primären Teiltransaktion nicht ermittelbar ist, bleibt die sekundäre Teiltransaktion im Zustand PTC, und die betroffene Datenbank wird nicht zugeschaltet.

In Bild 26 ist dargestellt, wie der Warmstart abläuft, wenn sich sekundäre Teiltransaktionen im Zustand PTC befinden.

Bild 26: Warmstart mit sekundären Teiltransaktionen im Zustand PTC

Nach einem Session-Abbruch sollen in der Konfiguration CONF-A die Datenbanken DB-A1, DB-A2 und DB-A3 gestartet werden.
Die Datenbanken DB-A2 und DB-A3 müssen warmgestartet werden, da sich noch die sekundäre Teiltransaktion STT-C im Zustand PTC befindet, die das Anwenderprogramm AP-C der Konfiguration CONF-C ausgelöst hat. In der RLOG- und in der DB-Status-Datei von CONF-C ist eingetragen, ob die primäre Teiltransaktion PTT-C mit FINISH oder mit FINISH WITH CANCEL abgeschlossen hat.

1.	Beim Warmstart der Konfiguration CONF-A wird in der RLOG-Datei eine Transaktion im Zustand PTC gefunden.
2.	Die Mastertask übergibt die in der RLOG-Datei hinterlegte Warmstart-Information an die UDS-D-Task.
3.	Die UDS-D-Task ermittelt aus der Warmstart-Information den Verarbeitungsrechner und die Konfiguration der zur STT-C gehörenden primären Teiltransaktion. Er sendet eine Nachricht an die entfernte UDS-D-Task mit der Aufforderung, festzustellen, wie die primäre Teiltransaktion beendet wurde.
4.	Diese Nachricht übergibt die entfernte UDS-D-Task an ihre Mastertask.
5.	Die Mastertask informiert sich in der DB-Status-Datei, wie die primäre Teiltransaktion beendet wurde. Falls diese nicht aktuell ist, schaut sie in die RLOG-Datei.
6. und 7.
	Das Ergebnis wird an die UDS-D-Task weitergereicht und von dort an die UDS-D-Task der sekundären Teiltransaktion.
8.	Die UDS-D-Task übergibt das Ergebnis an die Mastertask.
9.	Je nach Ende der primären Teiltransaktion wird die sekundäre Teiltransaktion STT-C beendet.
10.	Die UDS-D-Task von CONF-A meldet sich bei allen Konfigurationen, die in ihrer Verteiltabelle aufgeführt sind, um mitzuteilen, dass die Konfiguration CONF-A wieder ansprechbar ist.
11.	Da in der Konfiguration CONF-B noch die sekundäre Teiltransaktion STT-A im Zustand PTC ist, sendet die UDS-D-Task von CONF-B eine Nachricht an die UDS-D-Task der primären Teiltransaktion, um den Zustand der primären Teiltransaktion zu ermitteln.
12. und 13.
	siehe 4. und 5.
14. und 15.
	siehe 6. und 7.
16.	Abhängig vom Ergebnis sendet die UDS-D-Task den FINISH- oder FINISH WITH CANCEL-Auftrag an eine Servertask.
17.	Das Transaktionsende wird in der RLOG-Datei protokolliert.

Wenn es bei einem Warmstart nicht gelingt, eine sekundäre Teiltransaktion im Zustand PTC genauso wie ihre primäre Teiltransaktion zu beenden, bleibt die sekundäre Teiltransaktion im Zustand PTC und die betroffene Datenbank wird beim Warmstart nicht zugeschaltet. Eine Nachricht informiert den Datenbankadministrator über andere beteiligte Teiltransaktionen.

Wenn Datenbanken bei einem Warmstart nicht zuschaltbar sind, weil sich eine Teiltransaktion im Zustand PTC befindet, müssen Sie warten, bis die Konfiguration der primären Teiltransaktion wieder ansprechbar ist bzw. bis openUTM das Transaktionsende fordert oder müssen Sie mit dem DAL-Kommando MODIFY den PTCSYNCH-Wert für Warmstart auf ABORT oder COMMIT setzen.

Wenn der DBH-Ladeparameter PP PTCSYNCH nicht auf (WAIT,WAIT) steht, ist die konfigurationsübergreifende Konsistenz bzw. die UDS/SQL-/openUTM-Konsistenz gefährdet (siehe Abschnitt „Zustand PTC beenden“).

Auswirkungen des Zustands PTC bei DBH-Ende

• DBH-Ende mit CLOSE RUN-UNITS oder CLOSE CALLS

  UDS-D wartet, bis sich alle sekundären Teiltransaktionen im Zustand PTC automatisch beenden bzw. bis openUTM das Transaktionsende fordert.
  Wenn sich die Transaktionen nicht automatisch beenden, kann der Datenbankadministrator:

  • Mit &SYNCHRONIZE DISTRIBUTION bei sekundären Teiltransaktionen die Nachfrage veranlassen, wie die primäre Teiltransaktion beendet wurde. Falls UDS-D das Ende der primären Teiltransaktion nicht ermitteln kann, bleibt die sekundäre Teiltransaktion im Zustand PTC.

  • Mit DISPLAY USERS die Transaktionskennungen der Teiltransaktionen ermitteln, die im Zustand PTC sind, und mit den folgenden DAL-Kommandos die Teiltransaktionen im Zustand PTC beenden:

    ABORT transaktionskennung,OPTION=PTC
    oder
    COMMIT transaktionskennung

    Wenn keine Teiltransaktionen mehr offen sind, wird der DBH beendet.

    Wenn der Datenbankadministrator Teiltransaktionen mit ABORT,OPTION=PTC oder COMMIT beendet, ist die konfigurationsübergreifende Konsistenz bzw. die UDS/SQL-openUTM-Konsistenz gefährdet (siehe Abschnitt „Zustand PTC beenden“).

• Session-Abbruch mit %TERM

  Teiltransaktionen im Zustand PTC bleiben im Zustand PTC. Was Sie in diesem Fall bei einem Warmstart beachten müssen, finden Sie im Abschnitt „Auswirkungen des Zustands PTC bei einem Warmstart“.

  Datenbanken, die während einer Session inkonsistent wurden, sollten Sie nach einem Session-Abbruch möglichst schnell warmstarten, um eine möglichst problemlose Kommunikation zwischen den UDS/SQL-Konfigurationen zu gewährleisten.

Auswirkungen des Zustands PTC auf das Anwenderprogramm bei logischem Verbindungsverlust

Wenn in der Beendigungsphase einer verteilten Transaktion die logische Verbindung zu einer entfernten Konfiguration abbricht und nicht wieder neu aufgebaut werden kann, hängen die Auswirkungen auf das Anwenderprogramm davon ab, in welcher Phase des Zwei-Phasen-Ende-Protokolls sich die primäre Teiltransaktion befindet.

• Die Anwendertask hat die PETA-Anweisung an die sekundären Teiltransaktionen gesendet, die primäre Teiltransaktion wurde aber selbst noch nicht beendet.
  Das Anwenderprogramm bekommt vom Verbindungsmodul den Statuscode 122: „Transaktion wurde inzwischen zurückgesetzt“.

• Das Anwenderprogramm hat FINISH eingeleitet und er wurde fehlerfrei durchgeführt. Das Anwenderprogramm bekommt vom Verbindungsmodul den Statuscode 000: „DML-Anweisung erfolgreich durchgeführt“.

  In der Konfiguration der primären Teiltransaktion gilt die Transaktion als beendet, unabhängig davon, ob in einer entfernten Konfiguration noch eine sekundäre Teiltransaktion im Zustand PTC ist oder nicht.

• Falls der FINISH der primären Teiltransaktion fehlerhaft abläuft, bekommt das Anwenderprogramm den Statuscode des fehlerhaften FINISH.