Aktualizacja wielostanowiskowa, znana również jako rozproszona jednostka pracy (distributed unit of work - DUOW) i zatwierdzanie dwufazowe, to funkcja umożliwiająca aplikacji aktualizację danych na wielu zdalnych serwerach baz danych z zagwarantowaniem integralności danych. Na przykład może to być transakcja bankowa, dotycząca transferu pieniędzy z jednego konta na inne, znajdujące się na innym serwerze baz danych.
W przypadku takiej transakcji najważniejszą sprawą jest to, aby aktualizacje, które polegają na zaimplementowaniu operacji debetowania jednego konta nie zostały zatwierdzone, jeśli jednocześnie nie zostaną zatwierdzone aktualizacje operacji kredytowania drugiego konta. Aktualizacja wielostanowiskowa odnosi się do sytuacji, gdy dane reprezentujące konta są zarządzane przez dwa różne serwery baz danych.
Produkty DB2 udostępniają pełną obsługę aktualizacji wielostanowiskowej. Obsługa ta jest dostępna dla aplikacji zaprojektowanych za pomocą zwykłego języka SQL, jak również dla aplikacji korzystających z produktów typu monitory transakcji (monitory TP), w których została zaimplementowana specyfikacja interfejsu X/Open XA. Przykładami takich monitorów TP są produkty IBM TxSeries (CICS i Encina), IBM Message i Queuing Series, IBM Component Broker Series, IBM San Francisco Project, a także Microsoft Transaction Server (MTS), BEA Tuxedo i kilka innych. W zależności od tego, czy wykorzystywane są aktualizacje wielostanowiskowe w rodzimym języku SQL, czy aktualizacje wielostanowiskowe za pomocą monitora TP, to istnieją różne wymagania dotyczące konfiguracji.
Zarówno programy aktualizacji wielostanowiskowej napisane w rodzimym języku SQL, jak i korzystające z monitora TP muszą być prekompilowane z opcjami CONNECT 2 SYNCPOINT TWOPHASE. Oba programy mogą też używać instrukcji SQL Connect do wskazywania bazy danych, której dotyczyć mają kolejne instrukcje SQL. Jeśli nie ma monitora TP, który poinformowałby DB2, że będzie koordynował transakcję (na co wskazuje otrzymanie przez DB2 wywołania xa_open z monitora TP, gdy monitor ustanawia połączenie z bazą danych), koordynacją transakcji zajmie się oprogramowanie DB2.
Jeśli w aktualizacji wielostanowiskowej wykorzystuje się monitor TP, aplikacja musi zażądać zatwierdzenia transakcji lub jej wycofania za pomocą funkcji API monitora TP, na przykład CICS SYNCPOINT, Encina Abort(), MTS SetAbort().
Jeśli aktualizację wielostanowiskową przeprowadza się za pomocą SQL, używa się zwykłych komend SQL COMMIT i ROLLBACK.
Aktualizacja wielostanowiskowa może koordynować transakcje, w których następuje dostęp zarówno do menedżerów zasobów DB2, jak i menedżerów zasobów spoza DB2, na przykład menedżerów Oracle, Informix i SQLServer. Aktualizacja wielostanowiskowa w rodzimym języku SQL używana jest tylko dla serwerów DB2.
Aby można było wykonać aktualizację wielostanowiskową, każda z baz danych uczestniczących w rozproszonej transakcji musi być zdolna do obsługi rozproszonej jednostki pracy. W czasie pisania tego tekstu rozproszoną jednostkę pracy (DUOW), która umożliwia uczestniczenie w transakcjach rozproszonych, obsługiwały następujące serwery DB2:
Rozproszona transakcja może zaktualizować dowolną kombinację serwerów baz danych, które są obsługiwane. Na przykład aplikacja w ramach jednej transakcji może zaktualizować kilka tabel w bazie DB2 Universal Database w systemie Windows NT lub Windows 2000, w bazie DB2 for OS/390 i bazie DB2/400.
Aby serwery baz danych hosta i AS/400 mogły uczestniczyć w rozproszonej transakcji uruchomionej z aplikacji PC, UNIX lub aplikacji WWW, wymagają oprogramowania DB2 Connect. Ponadto w przypadku wielu aktualizacji wielostanowiskowych z udziałem serwerów baz danych hosta lub AS/400 konieczne jest skonfigurowanie komponentu Syncpoint Manager (SPM). Po utworzeniu instancji DB2 menedżer DB2 SPM jest automatycznie konfigurowany z domyślnymi ustawieniami.
Potrzeba użycia SPM wynika z wybranego protokołu (SNA lub TCP/IP) i
wykorzystania monitora TP. Następująca tabela zawiera podsumowanie
scenariuszy, które wymagają użycia programu. Z tabeli wynika, że
oprogramowanie DB2 Connect jest zawsze konieczne, gdy z hostem lub systemem
AS/400 chcą się połączyć komputery z procesorami Intela lub komputery z
systemem operacyjnym UNIX. Ponadto, jeśli w aktualizacji
wielostanowiskowej wykorzystuje się protokół SNA lub korzysta się z monitora
transakcji, konieczny jest komponent SPM oprogramowania DB2 Connect.
Tabela 1. Scenariusze aktualizacji wielostanowiskowej w systemie hosta i AS/400, wymagające SPM.
Czy monitor transakcji jest wykorzystywany | Protokół | Czy komponent SPM jest potrzebny | Wymagany produkt (wybierz jeden) | Obsługiwana baza danych hosta i AS/400 | ||
---|---|---|---|---|---|---|
Tak | TCP/IP | Tak |
|
| ||
Tak | SNA | Tak |
|
| ||
Nie | TCP/IP | Nie |
|
| ||
Nie | SNA | Tak |
|
|
Uwaga: | Rozproszona transakcja może zaktualizować dowolną kombinację
serwerów baz danych, które są obsługiwane. Na przykład aplikacja w
ramach jednej transakcji może zaktualizować kilka tabel w bazie DB2 UDB w
systemie Windows NT, w bazie DB2 for OS/390 i bazie DB2/400.
Aby uzyskać więcej informacji na temat zatwierdzania dwufazowego oraz instrukcje konfigurowania znanych monitorów TP, należy zapoznać się z podręcznikiem Administration Guide. Można także skorzystać z DB2 Product and Service Technical Library w sieci WWW:
|
DRDA definiuje wprawdzie protokoły komunikacji z bazami danych, ale nie definiuje interfejsów programistycznych (interfejsów API), z których mogliby korzystać programiści aplikacji. Aplikacja może używać architektury DRDA do przesyłania żądań, które docelowy serwer DRDA będzie mógł wykonać. Wszystkie dostępne dziś serwery DRDA mogą wykonywać instrukcje SQL przekazane przez aplikację za pośrednictwem DB2 Connect.
Firma IBM dostarcza programistom aplikacji, narzędzi do generowania żądań SQL przeznaczonych dla systemów Windows, OS/2 i kilku platform systemu UNIX. Narzędzia te są częścią zestawu DB2 Application Development Client. Zestaw DB2 Application Development Client obsługuje kilka typów API: wbudowanego SQL, JDBC, SQLJ i Interfejs poziomu wywołania DB2 (interfejs DB2 CLI). Programiści mogą korzystać z tych funkcji API do budowania aplikacji w wielu różnych językach programowania. Więcej informacji na temat tych interfejsów API można znaleźć w podręczniku Application Building Guide.
Programiści aplikacji mogą także używać interfejsów API dostarczanych przez inne firmy. Na przykład wielu programistów aplikacji Windows korzysta przy tworzeniu aplikacji baz danych z Microsoft ODBC i ADO. DB2 Connect udostępnia sterownik ODBC i dostawcę OLE DB, które wspomagają projektowanie aplikacji za pomocą interfejsów API ODBC i ADO. Firma IBM nie udostępnia narzędzi do tworzenia aplikacji ODBC; są one dostarczane przez firmę Microsoft Corporation.
Aby udostępnić aktualizacje wielostanowiskowe, można skorzystać z Centrum sterowania. Proces ten jest prosty i został naszkicowany poniżej. Aby uzyskać więcej informacji na temat procesu konfiguracji aktualizacji wielostanowiskowych, włącznie z ręczną konfiguracją systemu, należy zapoznać się z podręcznikiem w wersji elektronicznej Połączenia z DB2 - suplement.
W Centrum sterowania kliknij znak [+], aby rozwinąć widok drzewa. Za pomocą prawego klawisza myszy wybierz instancję, którą chcesz konfigurować. Zostanie otwarte menu podręczne. Wybierz element menu Konfiguracja aktualizacji wielostanowiskowej -->.
Kreator udostępnia interfejs typu notatnik. Na każdej stronie kreatora należy wprowadzić informacje dotyczące konfiguracji. Strony są wyświetlane w takiej kolejności, w jakiej występują w programie.
Krok 1. | Określ monitor transakcji. Pole to pokazuje wartości domyślne dla aktywnego monitora transakcji. Jeśli nie chcesz używać monitora TP, wybierz Nie używaj monitora TP. |
Krok 2. | Podaj protokoły komunikacyjne, których będziesz używał. |
Krok 3. | Określ bazę danych menedżera transakcji. Panel ten domyślnie zawiera pierwszą dołączoną bazę danych (1ST_CONN). Można pozostawić tę wartość lub wybrać inną skatalogowaną bazę. |
Krok 4. | Określ typy serwerów baz danych biorących udział w aktualizacji i zdecyduj, czy ma być używane wyłącznie TCP/IP. |
Krok 5. | Określ ustawienia programu Syncpoint Manager. Strona ta zostanie wyświetlona tylko wtedy, gdy ustawienia na poprzedniej stronie wskazują, że w aktualizacji wielostanowiskowej będzie używany program DB2 Syncpoint Manager.
|
Krok 1. | Wybierz instancję prawym przyciskiem myszy, a następnie z menu podręcznego wybierz opcję menu Testowanie aktualizacji wielostanowiskowej-->. Zostanie otwarte okno Testowanie aktualizacji wielostanowiskowej. |
Krok 2. | Wybierz bazy danych do testowania z okna listy Dostępne bazy danych. Można skorzystać z przycisków strzałki umieszczonych na środku, aby przesuwać wybory z i do okna listy Wybrane bazy danych. Można także zmienić wybrane ID użytkownika i hasło, bezpośrednio edytując je w oknie listy Wybrane bazy danych. |
Krok 3. | Po dokonaniu wyboru kliknij przycisk OK znajdujący się u dołu strony. Zostanie otwarte okno Multisite Update Test Result (Rezultaty testu aktualizacji wielostanowiskowej). |
Krok 4. | Okno Multisite Update Test Result (Rezultaty testu aktualizacji wielostanowiskowej) wyświetli informacje o tym, dla których z wybranych baz danych test aktualizacji się powiódł, a dla których się nie powiódł. Okno zawiera kody SQL i komunikaty o błędach dla baz, dla których test się nie powiódł.
|