Das Aktualisieren auf mehreren Systemen, auch als "verteilte Arbeitseinheit" (DUOW - Distributed Unit of Work) und zweiphasige Festschreibung bezeichnet, ist eine Funktion, die es Ihren Anwendungen ermöglicht, Daten auf mehreren fernen Datenbank-Servern zu aktualisieren und gleichzeitig ihre Integrität zu wahren. Ein Beispiel hierfür ist eine Banktransaktion, bei der Geld von einem Konto auf ein anderes auf einem anderen Datenbank-Server übertragen wird.
Bei einer solchen Transaktion ist es wichtig, daß Aktualisierungen, die ein Konto belasten, erst festgeschrieben werden, nachdem die Aktualisierungen, die für die Verarbeitung der Gutschrift auf dem anderen Konto erforderlich sind, festgeschrieben wurden. Die Aktualisierung auf mehreren Systemen ist dann in Betracht zu ziehen, wenn die Daten für diese Konten auf zwei verschiedenen Datenbank-Servern verwaltet werden.
Die DB2-Produkte bieten eine umfassende Unterstützung für Aktualisierungen auf mehreren Systemen. Diese Unterstützung ist für Anwendungen verfügbar, die mit regulärem SQL entwickelt wurden, sowie für Anwendungen, die Produkte zur Transaktionsüberwachung (TP-Monitore) verwenden, die die X/Open XA-Schnittstellenspezifikation implementieren. TP-Monitore sind z. B. IBM TxSeries (CICS und Encina), IBM Message and Queuing Series, IBM Component Broker Series, IBM San Francisco Project sowie Microsoft Transaction Server (MTS), BEA Tuxedo und verschiedene andere. Je nachdem, ob für die Aktualisierung auf mehreren Systemen systemeigenes SQL oder ein TP-Monitor verwendet wird, variieren die Installationsanforderungen.
Sowohl die Verfahren, die für die Aktualisierung auf mehreren Systemen systemeigenes SQL verwenden, als auch die auf TP-Monitoren basierenden Programme müssen unter Angabe der Optionen CONNECT 2 SYNCPOINT TWOPHASE vorkompiliert werden. Beide Verfahren können über die SQL-Anweisung CONNECT angeben, welche Datenbank für die folgenden SQL-Anweisungen verwendet werden soll. Wenn kein TP-Monitor vorhanden ist, der DB2 mitteilt, daß er die Transaktion koordiniert (z. B., wenn DB2 die xa_open-Aufrufe des TP-Monitors zum Aufbau einer Datenbankverbindung empfängt), wird die Transaktion von der DB2-Software koordiniert.
Wenn Sie für die Aktualisierung auf mehreren Systemen einen TP-Monitor verwenden, muß von der Anwendung mit Hilfe der API des TP-Monitors, z. B. CICS SYNCPOINT, Encina Abort(), MTS SetAbort(), eine COMMIT- oder ROLLBACK-Operation angefordert werden.
Bei der Aktualisierung auf mehreren Systemen mit systemeigenem SQL müssen die normalen SQL-Anweisungen COMMIT und ROLLBACK verwendet werden.
Die Aktualisierung auf mehreren Systemen mit einem TP-Monitor kann eine Transaktion koordinieren, die sowohl auf DB2- als auch auf Nicht-DB2-Ressourcenmanager wie Oracle, Informix oder SQLServer zugreift. Die Aktualisierung auf mehreren Systemen mit systemeigenem SQL wird nur mit DB2-Servern verwendet.
Damit eine Aktualisierungstransaktion auf mehreren Systemen durchgeführt werden kann, müssen alle Datenbanken, die an einer verteilten Transaktion beteiligt sind, verteilte Arbeitseinheiten unterstützen. Zum Zeitpunkt der Erstellung dieses Handbuchs unterstützen folgende DB2-Server verteilte Arbeitseinheiten und können somit an verteilten Transaktionen beteiligt werden:
In einer verteilten Transaktion kann eine beliebige Zusammenstellung aus unterstützten Datenbank-Servern aktualisiert werden. So können von Ihrer Anwendung beispielsweise mit einer einzigen Transaktion verschiedene Tabellen in DB2 Universal Database unter Windows NT oder Windows 2000, eine Datenbank von DB2 für OS/390 und eine DB2/400-Datenbank aktualisiert werden.
Für Host- und AS/400-Datenbank-Server ist DB2 Connect zur Teilnahme an einer verteilten Transaktion erforderlich, die von PC-, UNIX- oder Web-Anwendungen ausgeht. Zusätzlich erfordern viele Szenarios für die Aktualisierung auf mehreren Systemen, an denen Host- und AS/400-Datenbank-Server beteiligt sind, die Konfiguration des Synchronisationspunktmanagers (SPM). Der DB2-SPM wird beim Erstellen eines DB2-Exemplars automatisch mit Standardeinstellungen konfiguriert.
Ob der Synchronisationspunktmanager (SPM) tatsächlich benötigt wird, hängt
von der Auswahl des Protokolls (SNA oder TCP/IP) und der Verwendung des
TP-Monitors ab. Eine Auflistung aller Szenarios, für die der SPM
erforderlich ist, finden Sie in der folgenden Tabelle. Aus der Tabelle
geht außerdem hervor, daß für den Zugriff auf den Host oder das System AS/400
durch Intel- oder UNIX-Maschinen DB2 Connect erforderlich ist. Darüber
hinaus ist der Synchronisationpunktmanager von DB2 Connect für eine
Aktualisierung auf mehreren Systemen erforderlich, wenn der Zugriff über SNA
oder einen TP-Monitor erfolgt.
Wird TP-Monitor verwendet? | Protokoll | SPM erforderlich? | Erforderliches Produkt (wählen Sie eines aus) | Unterstützte Host- und AS/400-Daten-banken | ||
---|---|---|---|---|---|---|
Ja | TCP/IP | Ja |
|
| ||
Ja | SNA | Ja |
|
| ||
Nein | TCP/IP | Nein |
|
| ||
Nein | SNA | Ja |
|
|
Anmerkung: | In einer verteilten Transaktion kann eine beliebige Zusammenstellung aus
unterstützten Datenbank-Servern aktualisiert werden. So können von
Ihrer Anwendung zum Beispiel mit einer einzigen Transaktion verschiedene
Tabellen in DB2 UDB-Datenbanken unter Windows NT, eine Datenbank von DB2 für
OS/390 und eine DB2/400-Datenbank aktualisiert werden.
Weitere Informationen zur zweiphasigen Festschreibung sowie Anweisungen zum Definieren für mehrere gängige TP-Monitore finden Sie im Handbuch Systemverwaltung. Sie können auch die DB2 Product and Service Technical Library im World Wide Web abrufen:
|
DRDA definiert zwar Datenbank-Kommunikationsprotokolle, nicht jedoch die Programmierschnittstellen (APIs), die von den Anwendungsprogrammierern verwendet werden sollen. Im allgemeinen kann DRDA von einem Anwendungsprogramm verwendet werden, um Anforderungen zu übergeben, die ein Ziel-DRDA-Server ausführen kann. Alle heutzutage verfügbaren DRDA-Server können SQL-Anforderungen ausführen, die von einem Anwendungsprogramm über DB2 Connect weitergeleitet wurden.
IBM bietet Anwendungsprogrammierern Tools zum Generieren von SQL-Anforderungen für Windows, OS/2 und diverse UNIX-Plattformen. Diese Tools sind Bestandteil von DB2 Application Development Client. Das DB2 Application Development Client unterstützt unterschiedliche API-Typen: eingebettetes SQL, JDBC, SQLJ und den DB2 Call Level Interface (CLI). Diese APIs können von Programmierern zum Erstellen von Anwendungen in einer Vielzahl von Programmiersprachen verwendet werden. Weitere Informationen zu diesen APIs finden Sie im Handbuch Application Building Guide.
Anwendungsentwickler können auch APIs anderer Hersteller verwenden. Microsoft ODBC und ADO werden beispielsweise von Windows-Anwendungsprogrammierern zur Entwicklung von Datenbankanwendungen eingesetzt. DB2 Connect verfügt über einen ODBC-Treiber und einen OLE-DB-Provider, die Anwendungen unterstützen, die unter Verwendung der APIs ODBC und ADO entwickelt wurden. IBM bietet keine Tools zur Entwicklung von ODBC-Anwendungen. Diese Tools werden von Microsoft Corporation zur Verfügung gestellt.
Sie können Aktualisierungen auf mehreren Systemen über die Steuerzentrale durchführen. Die Prozedur ist einfach und wird nachfolgend kurz beschrieben. Weitere Informationen zum Konfigurationsprozeß für Aktualisierungen auf mehreren Systemen, einschließlich einer Anleitung für die manuelle Konfiguration Ihres Systems, finden Sie im Online-Handbuch Konnektivität Ergänzung.
Klicken Sie in der Steuerzentrale das Zeichen [+] an, um die Baumstruktursicht zu erweitern. Klicken Sie nun mit Maustaste 2 das Exemplar an, das Sie konfigurieren wollen. Daraufhin wird ein Kontextmenü geöffnet. Wählen Sie den Menüpunkt Aktualisierung auf mehreren Systemen --> Konfigurieren aus.
Die Schnittstelle des Assistenten ähnelt einem Notizbuch. Auf jeder Seite des Assistenten werden Sie aufgefordert, bestimmte Konfigurationsdaten anzugeben. Nachfolgend sind die Seiten in der Reihenfolge angezeigt, in der sie während der Sitzung angezeigt werden.
Schritt 1. | Geben Sie einen TP-Monitor (Transaktionsprogrammonitor) an. Dieses Feld enthält die von Ihnen aktivierten Standardwerte für den TP-Monitor. Wenn Sie keinen TP-Monitor verwenden möchten, wählen Sie Keinen TP-Monitor verwenden aus. |
Schritt 2. | Geben Sie die zu verwendenden Kommunikationsprotokolle an. |
Schritt 3. | Geben Sie eine TMD (Transaktionsmanagerdatenbank) an. In dieser Anzeige wird standardmäßig der Wert der ersten Datenbank angenommen, zu der Sie eine Verbindung herstellen (1ST_CONN). Sie können diesen Standardwert übernehmen oder eine andere Datenbank aus dem Katalog auswählen. |
Schritt 4. | Geben Sie die Arten der Datenbank-Server an, die an der Aktualisierung auf mehreren Systemen beteiligt sind, und legen Sie fest, ob ausschließlich TCP/IP verwendet werden soll. |
Schritt 5. | Geben Sie die Einstellungen für den Synchronisationspunktmanager (SPM) an. Diese Seite wird nur angezeigt, wenn die Verwendung des DB2-Synchronisationspunktmanagers im Szenario einer Aktualisierung auf mehreren Systemen aufgrund der Einstellungen auf der vorherigen Seite erforderlich ist.
|
Schritt 1. | Klicken Sie das Exemplar mit Maustaste 2 an, und wählen Sie anschließend im Kontextmenü die Menüoption Aktualisierung auf mehreren Systemen --> Test aus. Das Fenster Aktualisierung auf mehreren Systemen testen wird geöffnet. |
Schritt 2. | Wählen Sie die zu testenden Datenbanken aus den verfügbaren Datenbanken aus, die im Listenfenster Verfügbare Datenbanken angezeigt werden. Mit Hilfe der in der Mitte angezeigten Pfeilknöpfe können Sie Ihre Auswahl aus dem bzw. in das Listenfenster Ausgewählte Datenbanken bewegen. Darüber hinaus können Sie die ausgewählte Benutzer-ID und das ausgewählte Kennwort ändern, indem Sie sie direkt im Listenfenster Ausgewählte Datenbanken editieren. |
Schritt 3. | Wenn Sie Ihre endgültige Auswahl getroffen haben, klicken Sie unten im Fenster OK an. Das Fenster Testergebnis für Aktualisierung auf mehreren Systemen wird geöffnet. |
Schritt 4. | Das Fenster Testergebnis für Aktualisierung auf mehreren Systemen zeigt an, für welche der ausgewählten Datenbanken der Aktualisierungstest erfolgreich war, und für welche er fehlschlug. Das Fenster zeigt für die fehlgeschlagenen Tests SQL-Codes und Fehlernachrichten an.
|