Eine UTM-Anwendung kommuniziert mit Oracle Real Application Clusters über die XA-Schnittstelle. Kann in einem Failover-Fall ein XA-Aufruf von Oracle nicht mehr ordnungsgemäß durchgeführt werden, quittiert dies Oracle mit dem Rückgabewert „XAER_RMFAIL“.
Im Normalfall, d.h. wenn die Failover-Unterstützung nicht eingeschaltet ist, schließt openUTM aus dieser Meldung, dass eine weitere Zusammenarbeit mit dieser Datenbank nicht mehr möglich ist und bricht den Anwendungslauf ab.
Um diesen Abbruch zu verhindern, geben Sie bei den Startparametern unter .RMXA zusätzlich den Wert RAC=Y an und steuern das Failover-Verhalten mit den optionalen Parametern RAC_retry und RAC_recover_down:
.RMXA RM="Oracle_XA",OS=" openstring " ,RAC=Y
[,RAC_retry= nnn ] [,RAC_recover_down={Y|N}]
RAC=Y
schaltet die Failover-Unterstützung bei der Kopplung der UTM-Anwendung mit Oracle® Real Application Clusters ein.
RAC=N
schaltet die Failover-Unterstützung aus.
Standard: N
RAC_retry=nnn
nnn gibt die Anzahl der Versuche an, die openUTM unternehmen soll, um sich erneut mit der Datenbank zu verbinden und einen Recover-Auftrag auszuführen.
Konnte für eine Transaktion im Zustand „Prepare-to-Commit“ der Commit-Auftrag wegen eines Failover nicht ausgeführt werden, verbindet sich openUTM erneut mit der Datenbank und führt einen Recover-Auftrag aus. Ist die aktuelle XID in der Liste der gelieferten XIDs enthalten, wird von openUTM ein Commit-Auftrag für die XID, also für die aktuelle Transaktion, ausgeführt. Ist die XID nicht in der Liste enthalten, wird von openUTM ein xa_close durchgeführt. Anschließend versucht openUTM erneut, sich mit der Datenbank zu verbinden und einen Recover-Auftrag auszuführen.
Standard: 1
RAC_recover_down=
Legt fest, wie sich openUTM verhält, wenn die Transaktion nach der mit RAC_retry= festgelegten Anzahl von Versuchen nicht endgültig abgeschlossen werden konnte, d.h. nicht in den Zustand „Commit“ versetzt werden konnte.
| N | N openUTM geht davon aus, dass die Transaktion bei Oracle Real Application Clusters nicht mehr bekannt. ist. Die Transaktion wird als „Commit“ angenommen und openUTM setzt den Anwendungslauf fort. Standard: N |
| Y | openUTM beendet den Anwendungslauf abnormal und erzwingt damit einen Warmstart, um für Datenkonsistenz zu sorgen. |
Verhalten von openUTM im Failover-Fall
Wenn Sie Failover-Unterstützung eingeschaltet haben, dann verhalten sich openUTM und das Datenbanksystem wie folgt:
Der Anwendungsabbruch wird vermieden, wenn ein Failover zu einem noch aktiven Knoten des Oracle® Real Application Clusters möglich ist.
Bei Verbindungsverlust am Transaktionsende zwischen „Prepare“ und „Commit“ wird ein „Reconnect“ mit Recovery durchgeführt und im Erfolgsfall der „Commit“ über diese neue Verbindung wiederholt.
- Wenn zum Failover-Zeitpunkt noch Transaktionen offen sind, dann kann dies trotz eingeschalteter Failover-Unterstützung zu Problemsituationen und entsprechenden Fehlermeldungen führen (z.B. den Returncode ORA-25402 - transaction must rollback). Dies liegt daran, dass Oracle® Real Application Clusters beim Failover-Fall keine offenen Transaktionen migrieren kann. Diese Transaktionen müssen vom UTM-Anwendungsprogramm zurückgesetzt werden, siehe auch „UnterbrocheneTransaktionen".
Offene Mehrschritt-Transaktionen (d.h. nach PEND KP) werden im Failover-Fall durch das Datenbank-System zurückgesetzt, ohne dass openUTM dies beeinflussen kann.
Das Datenbank-System wird nach dem Rollback automatisch neu verbunden; anschließend können wieder neue Transaktionen gestartet werden. Wenn der Failover-Fall während des Warmstarts der Anwendung oder der Beendigung eines UTM-Prozesses eintritt, wird die Fehlerbehandlung wie gewohnt durchgeführt, es wird dann kein „Reconnect“ versucht.
Die Datenbank-Funktionalität „prepared Statements“ kann im Failover-Fall zu Fehlern führen.
Der „Reconnect“ zum Datenbank-System kann durch Meldungen verfolgt werden.
xa_close im Reconnect-Fall:
In der Meldung K202 wird im Insert &RMSTAT anstelle von „closed“ für die Instanz von Oracle® Real Application Clusters der String „RAC closed“ ausgegeben.
xa_open im Reconnect-Fall:
In der Meldung K224 wird im Insert &XACALL der String „RAC: xa_open“ ausgegeben.
Debug-Meldungen
In den Debug-Meldungen wird vermerkt, ob sich die Meldung auf eine Instanz von Oracle® Real Application Clusters bezieht. Wie Sie XA-DEBUG-Informationen für den Anschluss an die Datenbank bekommen, ist in Abschnitt „Debug-Parameter" beschrieben.
Unterbrochene Transaktionen
Unterbrochene Transaktionen können nur von dem Knoten fortgesetzt werden, der die Transaktion gestartet hat. Daher müssen alle UTM-Prozesse stets mit dem gleichen Knoten des Oracle® Real Application Clusters verbunden sein. Deshalb ist es am einfachsten,
die UTM-Anwendung nach dem Failover des Oracle® Real Application Clusters zu beenden, bevor der ausgefallene Knoten neu gestartet wird,
nach dem Neustart des ausgefallenen Knotens die UTM-Anwendung neu zu starten.
Dadurch ist sichergestellt, dass alle UTM-Prozesse mit dem gleichen Knoten des Oracle® Real Application Clusters verbunden sind und alle Transaktionen der Anwendung vom neu gestarteten Knoten des Oracle® Real Application Clusters bearbeitet werden.
Falls ein Beenden und Neustart der UTM-Anwendung nicht möglich ist, d.h. falls Knoten des Oracle® Real Application Clusters bei laufender openUTM-Anwendung umgeschaltet werden, dann kann sich folgende Situation ergeben, in der nicht mehr alle UTM-Prozesse mit demselben Knoten verbunden sind:
Eine Transaktion wird durch das Failover unterbrochen, zu diesem Zeitpunkt ist der UTM-Prozess noch mit dem alten Knoten verbunden.
Durch Nachstarten des Prozesses oder nach einem PEND ER im UTM-Anwendungsprogramm wird die unterbrochene Transaktion von einem anderen UTM-Prozess weitergeführt. Dieser Prozess ist jetzt mit dem neuen Knoten verbunden.
Die Datenbank-Instanz lehnt die Wiederaufnahme der unterbrochenen Transaktion ab (xa-start mit RESUME) und meldet, dass die Transaktion nicht bekannt ist.
openUTM führt einen „Reconnect“ zur Datenbank-Instanz aus. Auf der neuen Verbindung (d.h. mit dem neuen Knoten) versucht openUTM, die Transaktion wieder aufzunehmen.
Das Datenbank-System lehnt dies erneut ab, da die Datenbank-Transaktion auf dem alten Knoten des Oracle® Real Application Clusters begonnen wurde und auf dem neuen nicht fortgesetzt werden kann.
openUTM setzt die globale Transaktion zurück und gibt eine K160-Meldung aus, im Insert des internen Returncodes KCRCDC wird „NOTA“ ausgegeben.
Eine solche Situation lässt sich wie folgt mit Hilfe eines MSGTAC-Programms behandeln.
Steuerung über ein MSGTAC-Programm
Für die K160-Meldung wird als Meldungsziel der Event-Service MSGTAC definiert. MSGTAC reagiert auf den Insert der Meldung und stößt über die Programmschnittstelle zur Administration (KC_CHANGE_APPLICATION) ein Neustarten an. Damit werden alle Prozesse ausgetauscht, neu gestartet und sind anschließend mit dem neuen Knoten verbunden.
Durch dieses Verfahren wird die Zeitspanne minimiert, in der die UTM-Prozesse mit unterschiedlichen Knoten verbunden sind. Die Zahl der zurückgesetzten Transaktionen beschränkt sich auf diejenigen, die auf dem alten Knoten begonnen wurden und auf dem neuen nicht fortgesetzt werden konnten. Die Transaktionen, die auf dem neuen Knoten vor dem Neustarten begonnen wurden, können weitergeführt werden.