Jede Datenbank wird als ein separater Ressourcenmanager (RM) beim Transaktionsmanager (TM) definiert, und die Datenbank muß durch eine XA-Zeichenfolge zum Öffnen identifiziert werden. Eine Beschreibung des DB2-Formats der XA-Zeichenfolge zum Öffnen finden Sie unter Verwenden der XA-Zeichenfolgen zum Öffnen und Schließen.
Die XA-Zeichenfolge (xa_open) des Datenbankmanagers zum Öffnen besitzt zwei akzeptierte Formate. Ein Format wird in DB2 Version 7 neu eingeführt. Das zweite Format wird von früheren Versionen von DB2 verwendet und bleibt aus Gründen der Kompatibilität mit früheren Versionen erhalten. Neue Implementierungen sollten mit dem neuen Format arbeiten, und ältere Implementierungen sollten nach Möglichkeit auf das neue Format umgestellt werden. Zukünftige Versionen von DB2 werden möglicherweise das ältere Format für die XA-Zeichenfolge zum Öffnen nicht unterstützen. Informationen zum ursprünglichen Format der XA-Zeichenfolge zum Öffnen finden Sie in Format der XA-Zeichenfolge zum Öffnen für frühere Versionen von DB2.
Bei der Einrichtung einer Datenbank als Ressourcenmanager ist keine XA-Zeichenfolge zum Schließen (xa_close) erforderlich. Falls eine solche Zeichenfolge angegeben wird, wird sie vom Datenbankmanager ignoriert.
Das folgende XA-Zeichenfolgenformat wird mit DB2 Version 7 neu eingeführt:
parm_id1 = <parm-wert>,parm_id2 = <parm-wert>, ...
Es spielt keine Rolle, in welcher Reihenfolge diese Parameter angegeben
werden. Die gültigen Werte für parm_id werden in der
folgenden Tabelle beschrieben.
Tabelle 22. Gültige Werte für parm_id
Parametername | Wert | Verbindlich? | Groß-/Kleinschreibung beachtet? | Standardwert |
---|---|---|---|---|
DB | Aliasname der Datenbank | Ja | Nein | Kein |
Der Aliasname der Datenbank, der von der Anwendung für den Zugriff auf die Datenbank verwendet wird. | ||||
UID | Benutzer-ID | Nein | Ja | Kein |
Eine Benutzer-ID mit Berechtigung zur Verbindung mit der Datenbank. Erforderlich, wenn ein Kennwort angegeben wird. | ||||
PWD | Kennwort | Nein | Ja | Kein |
Ein zur Benutzer-ID gehöriges Kennwort. Erforderlich, wenn eine Benutzer-ID angegeben wird. | ||||
TPM | Name des TP-Monitors | Nein | Nein | Kein |
Name des verwendeten TP-Monitors. Unterstützte Werte siehe Werte für TPM und TP_MON_NAME. Dieser Parameter kann angegeben werden, um mehreren TP-Monitoren die Verwendung eines einzigen DB2-Exemplars zu ermöglichen. Der angegebene Wert überschreibt den im Konfigurationsparameter tp_mon_name des Datenbankmanagers definierten Wert. | ||||
AXLIB | Bibliothek, die die Funktionen ax_reg und ax_unreg des TP-Monitors enthält | Nein | Ja | Kein |
Dieser Wert wird von DB2 zum Abrufen der Adressen der erforderlichen Funktionen ax_reg und ax_unreg verwendet. Er kann genutzt werden, um aufgrund des Parameters TPM angenommene Werte zu überschreiben, oder er kann von TP-Monitoren genutzt werden, die nicht in der Liste für TPM aufgeführt sind. | ||||
CHAIN_END | xa_end-Kettungsmarkierung. Gültige Werte sind T, F oder kein Wert. | Nein | Nein | F |
Die XA_END-Kettung ist eine Optimierungsmaßnahme, die von DB2 zur Verringerung von Netzwerkübertragungen genutzt werden kann. Wenn die TP-Monitorumgebung so eingerichtet ist, daß gewährleistet werden kann, daß xa_prepare innerhalb desselben Thread oder Prozesses unmittelbar nach einem Aufruf von xa_end aufgerufen wird und CHAIN_END aktiviert ist, wird die xa_end-Markierung mit dem Befehl xa_prepare verkettet, um so eine Netzwerkübertragung einzusparen. Der Wert T bedeutet, daß CHAIN_END aktiviert ist. Der Wert F bedeutet, daß CHAIN_END inaktiv ist. Kein Wert bedeutet, daß CHAIN_END aktiviert ist. Dieser Parameter kann dazu dienen, die aus einem angegebenen TPM-Wert abgeleitete Einstellung zu überschreiben. | ||||
SUSPEND_ CURSOR | Gibt an, ob Cursor beizubehalten sind, wenn ein Transaktions-Thread der Steuerung angehalten wird. Gültige Werte sind T, F oder kein Wert. | Nein | Nein | F |
TP-Monitore, die eine Transaktionsverzweigung anhalten, können den angehaltenen Thread oder Prozeß für andere Transaktionen wiederverwenden. In diesen Fällen müssen Cursor geschlossen werden, so daß die neue Transaktion diese nicht übernimmt. Wenn eine angehaltene Transaktion wieder aufgenommen wird, muß die Anwendung den Cursor erneut abrufen. Wenn SUSPEND_CURSOR aktiv ist, werden keine geöffneten Cursor geschlossen, jedoch kann der Thread oder Prozeß nicht für andere Transaktionen wiederverwendet werden. Es ist nur die Wiederaufnahme der unterbrochenen Transaktion zulässig. Der Wert T bedeutet, daß SUSPEND_CURSOR aktiviert ist. Der Wert F bedeutet, daß SUSPEND_CURSOR inaktiv ist. Kein angegebener Wert bedeutet, daß SUSPEND_CURSOR aktiviert ist. Dieser Parameter kann dazu dienen, die aus einem angegebenen TPM-Wert abgeleitete Einstellung zu überschreiben. | ||||
HOLD_CURSOR | Gibt an, ob Cursor über Festschreibungen von Transaktionen hinweg beibehalten werden. Gültige Werte sind T, F oder kein Wert. | Nein | Nein | F |
TP-Monitore verwenden Threads oder Prozesse in der Regel für mehrere Anwendungen wieder. Um sicherzustellen, daß neu geladene Anwendungen keine von einer früheren Anwendung geöffneten Cursor übernehmen, werden Cursor nach einer Festschreibung (COMMIT) geschlossen. Wenn HOLD_CURSOR aktiviert ist, werden Cursor über Festschreibungen von Transaktionen hinweg beibehalten. Der Wert T bedeutet, daß HOLD_CURSOR aktiviert ist. Der Wert F bedeutet, daß HOLD_CURSOR inaktiv ist. Kein angegebener Wert bedeutet, daß HOLD_CURSOR aktiviert ist. Dieser Parameter kann dazu dienen, die aus einem angegebenen TPM-Wert abgeleitete Einstellung zu überschreiben. |
Der Parameter TPM für die XA-Zeichenfolge zum Öffnen (xa_open) und der
Konfigurationsparameter tp_mon_name des Datenbankmanagers
dienen dazu, für DB2 zu definieren, welcher TP-Monitor verwendet wird.
Der Wert für tp_mon_name gilt für das gesamte
DB2-Exemplar. Der Parameter TPM gilt nur für den speziellen
XA-Ressourcenmanager. Der Wert für TPM überschreibt den Parameter
tp_mon_name. Die folgenden Werte für die Parameter TPM
und tp_mon_name sind gültig:
Tabelle 23. Gültige Werte für TPM und tp_mon_name
TPM-Wert | TP-Monitor- produkt | Interne Einstellungen |
|
---|---|---|---|
CICS | IBM TxSeries CICS |
AXLIB=libEncServer (für Windows) =/usr/lpp/encina/lib/libEncServer (für auf UNIX basierende Systeme) HOLD_CURSOR=T CHAIN_END=T SUSPEND_CURSOR=F |
|
ENCINA | IBM TxSeries Encina Monitor |
AXLIB=libEncServer (für Windows) =/usr/lpp/encina/lib/libEncServer (für auf UNIX basierende Systeme) HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F |
|
MQ | IBM MQSeries |
AXLIB=mqmax (für Windows) =/usr/mqm/lib/libmqmax.a (für AIX) =/opt/mqm/lib/libmqmax.a (für Solaris) HOLD_CURSOR=F CHAIN_END=F SUSPEND_CURSOR=F |
|
CB | IBM Component Broker |
AXLIB=somtrx1i (für Windows) =libsomtrx1 (für auf UNIX basierende Systeme) HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F |
|
SF | IBM San Francisco |
AXLIB=ibmsfDB2 HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F |
|
TUXEDO | BEA Tuxedo |
AXLIB=libtux HOLD_CURSOR=F CHAIN_END=F SUSPEND_CURSOR=F |
|
MTS | Microsoft Transaction Server |
| Es ist nicht nötig, DB2 für MTS zu konfigurieren. MTS wird vom ODBC-Treiber von DB2 automatisch erkannt. |
JTA | Java Transaction API |
| Es ist nicht nötig, DB2 für Enterprise Java Servers (EJS) wie IBM WebSphere zu konfigurieren. Der JDBC-Treiber von DB2 erkennt diese Umgebung automatisch. |
db2 update dbm cfg using tp_mon_name CICSFür jede Datenbank, die in der Initialisierungszeichenfolge Region-> Resources-> Product-> XAD-> Resource manager für CICS definiert ist, geben Sie folgendes an:
db=dbalias,uid=benutzer-id,pwd=kennwort
db=dbalias,uid=benutzer-id,pwd=kennwort,tpm=cics
db2 update dbm cfg using tp_mon_name MQFür jede Datenbank, die in der Initialisierungszeichenfolge Region-> Resources-> Product-> XAD-> Resource manager für CICS definiert ist, geben Sie folgendes an:
uid=benutzer-id,db=dbalias,pwd=kennwort
uid=benutzer-id,db=dbalias,pwd=kennwort,tpm=mq
pwd=kennwort,uid=benutzer-id,tpm=cics,db=dbalias
db=dbalias,uid=benutzer-id,pwd=kennwort,tpm=mq
db2 update dbm cfg using tp_mon_name meinaxlibUnd für jede Datenbank, die für den XA TM definiert ist, Angeben einer XA-Zeichenfolge zum Öffnen:
db=dbalias,uid=benutzer-id,pwd=kennwort
db=dbalias,uid=benutzer-id,pwd=kennwort,axlib=meinaxlib
db=dbalias,uid=benutzer-id,pwd=kennwort,axlib=meinaxlib,chain_end=T
db=dbalias,uid=benutzer-id,pwd=kennwort,axlib=meinaxlib,chain_end
Frühere Versionen von DB2 arbeiten mit dem im folgenden beschriebenen Format der XA-Zeichenfolge zum Öffnen (xa_open). Dieses Format wird aus Gründen der Kompatibilität weiterhin unterstützt. Anwendungen sollten nach Möglichkeit auf das neue Format (siehe Neues Format der XA-Zeichenfolge zum Öffnen für DB2 Version 7) umgestellt werden.
Jede Datenbank wird als ein separater Ressourcenmanager (RM) beim Transaktionsmanager (TM) definiert, und die Datenbank muß durch eine XA-Zeichenfolge zum Öffnen mit der folgenden Syntax identifiziert werden:
"db_alias<,benutzer-id,kennwort>"
Der db_alias ist erforderlich, um den Aliasnamen der Datenbank anzugeben. Der Aliasname ist derselbe Name wie der Datenbankname, sofern Sie nicht explizit einen Aliasnamen nach der Erstellung der Datenbank katalogisiert haben. Der Benutzername und das Kennwort sind wahlfrei und werden je nach Methode zur Identifikationsüberprüfung verwendet, um Informationen zur Identifikationsüberprüfung an die Datenbank weiterzugeben.
Bei der Einrichtung einer Datenbank als Ressourcenmanager ist keine XA-Zeichenfolge zum Schließen (xa_close) erforderlich. Falls eine solche Zeichenfolge angegeben wird, wird sie vom Datenbankmanager ignoriert.
Host- und AS/400-Datenbank-Server können aktualisierbar sein, je nach Architektur des XA-Transaktionsmanagers. Zur Unterstützung von Festschreibungssequenzen aus verschiedenen Prozessen muß der DB2 Connect-Konzentrator aktiviert werden. Zur Aktivierung des DB2 Connect EE-Konzentrators setzen Sie den Konfigurationsparameter max_logicagents des Datenbankmanagers auf einen Wert, der größer ist als maxagents. Beachten Sie, daß für den DB2 Connect EE-Konzentrator ein Client mit DB2 Version 7.1 zur Unterstützung von XA-Festschreibungssequenzen aus verschiedenen Prozessen erforderlich ist. Informationen zu SQL-Anweisungen, die in dieser Umgebung zulässig sind, finden Sie im Handbuch Application Development Guide. Informationen zum Konzentrator finden Sie im DB2 Connect Benutzerhandbuch.
Wenn Sie die Host- oder AS/400-Datenbank-Server aktualisieren wollen, benötigen Sie DB2 Connect mit konfiguriertem DB2-Synchronisationspunktmanager (SPM). Anweisungen finden Sie in einem der Handbücher Einstieg.
Dieser Abschnitt behandelt die folgenden Themen:
Wenn die Anweisung RELEASE verwendet wurde, um die Verbindung zu einer Datenbank freizugeben, sollte die Anweisung CONNECT und nicht die Anweisung SET CONNECTION zur erneuten Herstellung der Verbindung zu dieser Datenbank verwendet werden.
In einer Umgebung mit partitionierten Datenbanken können Benutzerdaten auf mehrere Datenbankpartitionen verteilt werden. Eine Anwendung, die auf eine solche Datenbank zugreift, stellt die Verbindung her und sendet Anforderungen an eine der Partitionen der Datenbank (den Koordinatorknoten). Verschiedene Anwendungen können die Verbindung zu verschiedenen Datenbankpartitionen herstellen, und dieselbe Anwendung kann verschiedene Datenbankpartitionen für verschiedene Verbindungen auswählen.
Für Transaktionen, die an einer Datenbank in einer Umgebung mit partitionierten Datenbanken ausgeführt werden, muß der gesamte Zugriff über gleiche Datenbankpartition erfolgen. Das bedeutet, daß die gleiche Datenbankpartition vom Beginn der Transaktion bis zu dem Zeitpunkt (einschließlich) verwendet werden muß, zu dem die Transaktion festgeschrieben wird.
Jede Transaktion für die partitionierte Datenbank muß festgeschrieben werden, bevor die Verbindung getrennt wird.
Ein dem XA-Standard entsprechender Transaktionsmanager arbeitet mit einem ähnlichen zweiphasigen Festschreibeprozeß wie der DB2-Transaktionsmanager, der in Prozeß der zweiphasigen Festschreibung beschrieben wird. Der Hauptunterschied zwischen diesen beiden Umgebungen besteht darin, daß hier der TP-Monitor die Funktionen zur Protokollierung und Steuerung zur Verfügung stellt, und nicht der DB2-Transaktionsmanager und die Transaktionsmanagerdatenbank.
Bei der Verwendung eines dem XA-Standard entsprechenden Transaktionsmanagers können Fehler auftreten, die den für den DB2-Transaktionsmanager beschriebenen Fehlern ähnlich sind (siehe Beheben von Problemen bei der zweiphasigen Festschreibung). Ähnlich wie der DB2-Transaktionsmanager versucht auch ein XA-Transaktionsmanager unbestätigte Transaktionen zu resynchronisieren.
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.
Der Befehl LIST INDOUBT TRANSACTIONS (mit der Option WITH PROMPTING) bzw. eine entsprechende Gruppe von APIs ermöglicht es, unbestätigte Transaktionen abzufragen, festzuschreiben (COMMIT) oder rückgängig zu machen (ROLLBACK). Darüber hinaus können mit diesem Befehl Transaktionen ignoriert werden ("FORGET"), die heuristisch festgeschrieben oder rückgängig gemacht wurden, indem die Protokollsätze entfernt und der Protokollspeicherbereich freigegeben werden. Zum Abfragen von Informationen über unbestätigte Transaktionen aus DB2 UDB auf UNIX-Systemen, auf dem Windows-Betriebssystem oder OS/2, stellen Sie eine Verbindung zu der Datenbank her und setzen den Befehl LIST INDOUBT TRANSACTIONS WITH PROMPTING ab bzw. verwenden die entsprechende API. Weitere Informationen zu diesem Befehl oder zu den entsprechenden administrativen APIs finden Sie im Handbuch Command Reference bzw. Administrative API Reference.
Zum Abrufen von Informationen zu unbestätigten Transaktionen in bezug auf Host- oder AS/400-Datenbank-Server stehen zwei Möglichkeiten zur Verfügung:
Zum Abrufen von Informationen zu unbestätigten Transaktionen direkt aus DB2 für OS/390 rufen Sie den Befehl DISPLAY THREAD TYPE(INDOUBT) auf. Mit Hilfe des Befehls RECOVER können Sie eine heuristische Entscheidung treffen. Zum direkten Abrufen von Informationen zu unbestätigten Transaktionen aus DB2 für OS/400 rufen Sie den Befehl wrkcmtdfn auf.
Zum Abrufen von Informationen zu unbestätigten Transaktionen vom DB2 Connect-Server stellen Sie zunächst eine Verbindung zum DB2-Synchronisationspunktmanager her, indem Sie eine Verbindung zu dem DB2-Exemplar herstellen, das durch den Wert des Konfigurationsparameters spm_name des Datenbankmanagers definiert ist. Anschließend setzen Sie den Befehl LIST DRDA INDOUBT TRANSACTIONS WITH PROMPTING ab, um unbestätigte Transaktionen anzuzeigen und heuristische Entscheidungen zu treffen.
Verwenden Sie diese Befehle (bzw. die entsprechenden APIs) nur mit äußerster Vorsicht und nur als allerletzte Möglichkeit. Die beste Strategie ist, zu warten, bis der Transaktionsmanager den Prozeß der Resynchronisation durchgeführt hat. Es kann zu Problemen mit der Datenintegrität kommen, wenn Sie eine Transaktion in einer der beteiligten Datenbanken manuell festschreiben oder rückgängig machen und die entgegengesetzte Maßnahme für eine andere beteiligte Datenbank durchgeführt wird. Die Behebung von Problemen der Datenintegrität setzt voraus, daß Sie die Logik der Anwendung und die geänderten oder rückgängig gemachten Daten kennen, und Sie dann eine Wiederherstellung bis zu einem bestimmten Zeitpunkt durchführen bzw. die Datenbankänderungen manuell rückgängig machen oder erneut anwenden.
Wenn Sie nicht darauf warten können, bis der Transaktionsmanager den Prozeß zur Resynchronisation initialisiert, und die Ressourcen, die von einer unbestätigten Transaktion blockiert werden, freigeben müssen, sind heuristische Maßnahmen erforderlich. Diese Situation kann auftreten, wenn der Transaktionsmanager für einen längeren Zeitraum zur Durchführung der Resynchronisation nicht verfügbar ist und die unbestätigte Transaktion Ressourcen sperrt, die dringend benötigt werden. Eine unbestätigte Transaktion blockiert Ressourcen, die dieser Transaktion zugeordnet wurden, als der Transaktionsmanager oder die Ressourcenmanager noch verfügbar waren. Im Fall des Datenbankmanagers gehören zu diesen Ressourcen zum Beispiel die Sperren für Tabellen und Indizes, der Protokollspeicherbereich und der Speicher, der von der Transaktion belegt wird. Jede unbestätigte Transaktion verringert außerdem die maximale Anzahl gleichzeitiger Transaktionen (um den Wert 1), die von der Datenbank verarbeitet werden können.
Obwohl es keine absolut sichere Methode zur Durchführung heuristischer Maßnahmen gibt, werden im folgenden einige allgemeine Richtlinien beschrieben:
Führen Sie die heuristische Funktion FORGET nicht aus, sofern nicht eine heuristisch festgeschriebene oder rückgängig gemachte Transaktion zu der Bedingung führt, daß das Protokoll voll ist, die in der Ausgabe des Befehls LIST INDOUBT TRANSACTIONS angezeigt wird. Die heuristische Funktion FORGET gibt den Protokollspeicherbereich frei, der durch eine unbestätigte Transaktion belegt wird. Dies könnte zur Folge haben, daß, wenn ein Transaktionsmanager schließlich einen Resynchronisationsprozeß für diese unbestätigte Transaktion durchführt, er eine falsche Entscheidung, andere Ressourcenmanager festzuschreiben oder rückgängig zu machen, treffen könnte, weil für die Transaktion in diesem Ressourcenmanager kein Protokollsatz mehr vorhanden wäre. Allgemein impliziert ein "fehlender" Protokollsatz, daß der Ressourcenmanager die Transaktion rückgängig gemacht hat.
Der TP-Monitor ordnet eine Gruppe von Server-Prozessen im voraus zu und führt die Transaktionen von verschiedenen Benutzern unter den IDs der Server-Prozesse aus. Für die Datenbank erscheint jeder Server-Prozeß wie eine große Anwendung, die viele Arbeitseinheiten vereinigt, die alle unter derselben, dem Server-Prozeß zugeordneten ID ausgeführt werden.
Wenn zum Beispiel in einer AIX-Umgebung mit CICS eine TXSeries CICS-Region gestartet wird, wird ihr der AIX-Benutzername zugeordnet, unter dem sie definiert ist. Alle CICS-Anwendungs-Server-Prozesse werden ebenfalls unter dieser TXSeries CICS-Haupt-ID ausgeführt, die in der Regel als "cics" definiert ist. CICS-Benutzer können CICS-Transaktionen unter ihrer DCE-Anmelde-ID aufrufen und, während sie in CICS arbeiten, ihre ID mit Hilfe der CESN-Anmeldetransaktion auch ändern. In beiden Fällen ist für den Ressourcenmanager die Endbenutzer-ID nicht verfügbar. Folglich kann ein CICS-Anwendungsprozeß Transaktionen für viele Benutzer ausführen, aber sie erscheinen dem Ressourcenmanager wie ein einziges Programm mit vielen Arbeitseinheiten von derselben ID "cics". Wahlfrei können Sie eine Benutzer-ID und ein Kennwort in der XA-Zeichenfolge zum Öffnen angeben, so daß diese Benutzer-ID anstelle der ID "cics" für die Verbindung mit der Datenbank verwendet wird.
Die Auswirkungen sind für statische SQL-Anweisungen nicht groß, da zum Zugriff auf die Datenbank die Zugriffsrechte der Person, die das Paket gebunden hat, und nicht die Zugriffsrechte des Endbenutzers verwendet werden. Das bedeutet aber, daß das Zugriffsrecht EXECUTE der Datenbankpakete der Server-ID, und nicht der Endbenutzer-ID erteilt werden muß.
Für dynamische Anweisungen, für deren Zugriff die Authentifizierung zur Laufzeit erfolgt, müssen die Zugriffsrechte der Datenbankobjekte der Server-ID, und nicht dem tatsächlichen Benutzer dieser Objekte erteilt werden. Anstatt sich bei der Steuerung des Zugriffs bestimmter Benutzer auf die Datenbank zu stützen, müssen Sie über das TP-Monitorsystem festlegen, welche Benutzer welche Programme ausführen können. Der Server-ID müssen alle Zugriffsrechte erteilt werden, die für die SQL-Benutzer erforderlich sind.
Um festzustellen, wer auf eine Datenbanktabelle oder -sicht zugegriffen hat, können Sie folgende Schritte unternehmen:
Bei der Einrichtung der TP-Monitorumgebung sollten die folgenden Konfigurationsparameter berücksichtigt werden:
Mit diesem Konfigurationsparameter des Datenbankmanagers wird der Name des verwendeten TP-Monitorprodukts (z. B. "CICS" oder "ENCINA") angegeben.
Mit diesem Konfigurationsparameter des Datenbankmanagers wird der Name des fernen Transaktionsprogramms angegeben, das der Datenbank-Client verwenden muß, wenn er eine Zuordnungsanforderung an den Datenbank-Server über das APPC-Übertragungsprotokoll absetzt. Der Wert wird in der Konfigurationsdatei auf dem Server definiert und muß mit dem im SNA-Transaktionsprogramm konfigurierten TP-Namen für den Transaktionsprozessor übereinstimmen. Weitere Informationen finden Sie in den Handbüchern Einstieg.
Da DB2 Transaktionen in der XA-Umgebung nicht koordiniert, wird dieser Konfigurationsparameter des Datenbankmanagers für XA-koordinierte Transaktionen nicht verwendet.
Mit diesem Konfigurationsparameter der Datenbank wird die zulässige maximale Anzahl aktiver Anwendungen angegeben. Der Wert dieses Parameters muß gleich oder größer sein als die Summe der verbundenen Anwendungen plus die Anzahl dieser Anwendungen, die sich gleichzeitig im Prozeß einer zweiphasigen Festschreibung bzw. einer ROLLBACK-Operation befinden können. Diese Summe sollte dann um die vorab geschätzte Anzahl unbestätigter Transaktionen erhöht werden, die zu einem beliebigen Zeitpunkt gleichzeitig vorhanden sein könnten. Weitere Informationen zu unbestätigten Transaktionen finden Sie in Beheben von Problemen bei der zweiphasigen Festschreibung.
Für eine TP-Monitorumgebung (z. B. TXSeries CICS) müssen Sie den Wert des Parameters maxappls erhöhen. Dies hilft bei der Sicherstellung, daß alle TP-Monitorprozesse verarbeitet werden können.
Mit diesem Konfigurationsparameter der Datenbank wird festgelegt, ob die Routine RESTART DATABASE bei Bedarf aufgerufen wird. Der Standardwert ist YES (d. h. aktiviert).
Für eine Datenbank, die unbestätigte Transaktionen enthält, ist eine RESTART DATABASE-Operation für den Neutstart erforderlich. Wenn autorestart nicht aktiviert ist und die letzte Verbindung zur Datenbank getrennt wurde, schlägt die nächste Verbindungsanforderung fehl, so daß ein explizites Aufrufen des Befehls RESTART DATABASE erforderlich wird. Diese Bedingung bleibt solange bestehen, bis die unbestätigten Transaktionen entweder durch die Resynchronisationsoperation des Transaktionsmanagers oder durch eine vom Administrator eingeleitete heuristische Operation beseitigt wird. Wenn der Befehl RESTART DATABASE abgesetzt wird, wird eine Nachricht zurückgegeben, wenn unbestätigte Transaktionen in der Datenbank vorhanden sind. Der Administrator kann dann mit Hilfe des Befehls LIST INDOUBT TRANSACTIONS und anderer Befehle des Befehlszeilenprozessors Informationen über diese unbestätigten Transaktionen erhalten.
DB2 Universal Database unterstützt die Spezifikation XA91, die in X/Open CAE Specification Distributed Transaction Processing: The XA Specification definiert ist, mit folgenden Ausnahmen:
Die XA-Spezifikation ermöglicht der Schnittstelle die Verwendung asynchroner Services, so daß das Ergebnis einer Anforderung zu einem späteren Zeitpunkt überprüft werden kann. Für den Datenbankmanager müssen die Anforderungen im synchronen Modus aufgerufen werden.
Die XA-Schnittstelle ermöglicht zwei Methoden zur Registrierung eines Ressourcenmanagers: statische und dynamische Registrierung. DB2 Universal Database unterstützt nur die dynamische Registrierung, die ausgereifter und effizienter ist. Weitere Informationen zu diesen beiden Methoden finden Sie in Ressourcenmanager (RM).
DB2 Universal Database unterstützt die Transaktionsmigration zwischen Threads der Steuerung nicht.
Informationen zur Verwendung der XA-Zeichenfolgen zum Öffnen und zum Schließen (xa_open und xa_close) finden Sie in Verwenden der XA-Zeichenfolgen zum Öffnen und Schließen.
Wie für die XA-Schnittstelle erforderlich stellt der Datenbankmanager eine externe C-Variable db2xa_switch des Typs xa_switch_t bereit, um die XA-Schalterstruktur an den Transaktionsmanager zurückzugeben. Neben den Adressen verschiedener XA-Funktionen werden folgende Felder zurückgegeben:
Gibt explizit an, daß DB2 Universal Database die dynamische Registrierung verwendet und daß der TM keine Migration von Zuordnungen verwenden soll. Gibt implizit an, daß ein asynchroner Betrieb nicht unterstützt wird.
Die XA-Architektur verlangt, daß ein Ressourcenmanager (RM) einen Schalter bereitstellt, der dem XA-Transaktionsmanager (TM) Zugriff auf die xa_-Routinen des Ressourcenmanagers gibt. Ein RM-Schalter verwendet eine Struktur, die als xa_switch_t bezeichnet wird. Der Schalter enthält den Namen des RMs, Nicht-NULL-Zeiger auf die XA-Eingangspunkte des RMs, eine Markierung (Flag) und eine Versionsnummer.
Der DB2 UDB-Schalter kann durch eine der folgenden Methoden abgerufen werden:
#define db2xa_switch (*db2xa_switch)
vor Verwendung von db2xa_switch erreicht werden.
DB2 UDB stellt diese API zur Verfügung, die die Adresse der db2xa_switch-Struktur liefert. Der Prototyp dieser Funktion lautet:
struct xa_switch_t * SQL_API_FN db2xacic( )
Bei beiden Methoden müssen Sie die Anwendung mit libdb2 (bei auf UNIX basierenden Systemen) oder db2api.lib (unter OS/2) verbinden ("linken").
Der Zeiger auf die xa_switch-Struktur, db2xa_switch, wird in Form von DLL-Daten exportiert (d. h. bereitgestellt). Dies heißt für eine Anwendung unter Windows NT, die diese Struktur verwendet, daß sie auf die Struktur mit Hilfe einer von drei Methoden zugreifen muß:
#define db2xa_switch (*db2xa_switch)vor Verwendung von db2xa_switch erreicht werden.
extern __declspec(dllimport) struct xa_switch_t db2xa_switch
DB2 UDB stellt diese API zur Verfügung, die die Adresse der db2xa_switch-Struktur liefert. Der Prototyp dieser Funktion lautet:
struct xa_switch_t * SQL_API_FN db2xacic( )
Bei jeder dieser Methoden müssen Sie die Anwendung mit db2api.lib verbinden ("linken").
Der folgende Code veranschaulicht die verschiedenen Methoden des Zugriffs auf db2xa_switch über ein C-Programm auf einer beliebigen DB2 UDB-Plattform. Stellen Sie sicher, daß die Anwendung mit der entsprechenden Bibliothek verbunden wird.
#include <stdio.h> #include <xa.h> struct xa_switch_t * SQL_API_FN db2xacic( ); #ifdef DECLSPEC_DEFN extern __declspec(dllimport) struct xa_switch_t db2xa_switch; #else #define db2xa_switch (*db2xa_switch) extern struct xa_switch_t db2xa_switch; #endif
main( ) { struct xa_switch_t *foo; printf ( "%s \n", db2xa_switch.name ); foo = db2xacic(); printf ( "%s \n", foo->name ); return ; }
Wenn ein Fehler während einer XA-Anforderung vom Transaktionsmanager festgestellt wird, ist das Anwendungsprogramm eventuell nicht in der Lage, den Fehlercode vom Transaktionsmanager zu ermitteln. Wenn Ihr Programm abnormal beendet wird oder einen unklaren Rückkehrcode vom TP-Monitor oder Transaktionsmanager empfängt, sollten Sie das Serviceprotokoll des DB2-Diagnoseprogramms überprüfen, in dem XA-Fehlerinformationen aufgezeichnet werden, wenn Diagnosestufe 3 oder höher in Kraft ist. Weitere Informationen zum Serviceprotokoll des DB2-Diagnoseprogramms finden Sie im Handbuch Troubleshooting Guide.
Sie sollten auch die Informationen der Konsolnachricht, der Fehlerdatei des Transaktionsmanagers oder andere produktspezifische Informationen über die verwendete externe Software zur Verarbeitung von Transaktionen berücksichtigen.
Der Datenbankmanager schreibt alle XA-spezifischen Fehler mit dem SLQCODE -998 (Fehler bei Transaktion oder heuristischer Maßnahme) und den entsprechenden Ursachencodes in das Serviceprotokoll des DB2-Diagnoseprogramms. Es folgen einige der häufigeren Fehlerursachen:
Das folgende Beispiel zeigt ein Fehlerprotokoll für einen xa_open-Fehler (wegen einer fehlender XA-Zeichenfolge zum Öffnen), das unter AIX generiert wurde:
Tue Apr 4 15:59:08 1995 toop pid(83378) process (xatest) XA DTP Support sqlxa_open Probe:101 DIA4701E Datenbank "" konnte nicht für verteilte Transaktionsverarbeitung geöffnet werden. String Title : XA Interface SQLCA pid(83378) SQLCODE = -998 REASON CODE: 4 SUBCODE: 1 Dump File : /u/toop/diagnostics/83378.dmp Data : SQLCA