Der Umgang mit Remote beziehungsweise Distributed Unit of Work

Unterschiedliche Wege fuehren zu einem verteilten DB2-Design

05.03.1993

Abgesehen von den heutigen Einschraenkungen in den DB2-Versionen 2.2 und 2.3 unterscheiden sich die Arten verteilter Daten insbesondere durch ihre spezifischen Merkmale hinsichtlich Komplexitaet, Recovery, Integritaet und Performance. Im allgemeinen werden verteilte Daten durch eines der folgenden Verfahren implementiert:

- extrahierte Tabellen,

- verteilte Tabellen,

- Snapshot-Tabellen,

- Replikations-Tabellen sowie

- Spalten- beziehungsweise Zeilenfragmentierung.

Extrahierte Tabellen entstehen durch vom Benutzer ausgeloeste Datentransfers und eignen sich speziell fuer Ad-hoc-Abfragen in einem Informations-Center sowie zur Unterstuetzung bei der Entscheidungsfindung. Die Aktualitaet des letzen Extrakts bestimmt die Guete der Daten und ist der Schluessel fuer den richtigen Umgang mit diesem Verfahren.

Verteilte Tabellen enthalten typischerweise geerbte Daten, die bereits auf den verschiedenen Systemen im Netz verteilt und gespeichert waren und nun zusammengefasst in die Naehe der Anwendungen gebracht werden sollen, die am meisten auf diese Daten zugreifen. Die DB2-Funktion Distributed Unit of Work erlaubt anderen, entfernten Anwendungen - durch Zugriff auf ihr eigenes lokales DB2 - einen einfachen Lesezugriff auf diese verteilten Daten und ist damit insbesondere fuer solche Nutzer interessant, die kein eigenes Multi-System-Logon besitzen oder eine Konsolidierung beziehungsweise Integration verteilter Daten nicht vornehmen koennen. Die Remote-Update-Beschraenkungen unter IMS und CICS mag die breite Nutzung dieser Tabellen in verteilten Anwendungen verhindern.

Snapshot-Tabellen enthalten vom System initialisierte und kontrollierte Daten, die als Read-only-Kopie einer Quelltabelle in regelmaessigen Abstaenden - taeglich, woechentlich oder monatlich - aufgefrischt werden. Obwohl keine DB2-gesteuerte Snapshot-Funktion existiert, ist diese Art von Tabelle relativ einfach durch einen Batch-Job oder eine zeitaktivierte Transaktion zu realisieren.

Replikations-Tabellen sind Kopien einer Quelltabelle, die im Netz mehrfach vorkommen und durch Update-Propagation des Systems synchronisiert werden. Die Nutzung dieser Tabellenart ist mit den DB2-Versionen 2.2 und 2.3 erheblich eingeschraenkt, da Updates lediglich auf einem einzigen DB2-System pro Commit moeglich sind und keine von DB2 koordinierte Unit of Recovery ueber mehrere Systeme existiert (kein systemuebergreifender Zweiphasen-Commit).

Ein anderes Datenbankdesign arbeitet mit Spalten- oder Zeilenfragmentierung. Dabei werden die verteilen Daten nach Spalten beziehungsweise Zeilen auf mehrere Tabellen in verschiedenen Systemen verteilt, wo sie sich dann schwerpunktmaessig von der jeweiligen Anwendung verarbeiten lassen.

Aus Integritaetsgruenden mag ein gemeinsamer Schluessel (Referential Constraint) fuer diese individuellen Tabellen erforderlich sein. Diese Moeglichkeit unterstuetzt DB2 jedoch nicht. Praktikabel erscheint die Methode der Zeilenfragmentierung heute lediglich dort, wo die Remote-Zugriffe als Read-only-Operationen gehandhabt werden und die referentielle Integritaet jeweils lokal geloest ist. Das DB2-Recovery und die Synchronisation von verteilten Daten erfolgen in jedem Fall lokal.

Das Design verteilter Datenbanken und Anwendungen verlangt vom Anwender, dass er eine genaue Vorstellung von dem gewuenschten Grad der verteilten Verarbeitung hat. Die mit der DB2-Version 2.2 eingefuehrte Distributed Unit of Work erlaubt Zugriffe auf mehrere DB2-Systeme innerhalb eines Commit, wobei zu beachten ist, dass lediglich die Data Manipulation Language (SELECT, INSERTS, UPDATES und DELETE) unterstuetzt wird, die dynamisch gebunden und auf einem entfernten DB2-System ausgefuehrt wird.

Zusaetzlich zu dieser Art der verteilten Verarbeitung wurde mit der Version 2.3 die Remote Unit of Work (Ruow) vorgestellt. Mit ihrer Hilfe laesst sich eine statisch vorgebundene SQL (DML, DDL, DCL sowie BIND) in sogenannten Packages auf entfernten DB2- Systemen speichern und ausfuehren. Allerdings ist nur ein einziges DB2-System pro SQL-Package ansprechbar. Weiter erlaubt Ruow beidseitige Lese- und Schreibzugriffe zwischen DB2 und dem SQL/DS- Release 2.3 sowie OS/2 Database Manager 2.1.1 oder auch einem anderen Datenbanksystem, fuer das die Distributed Relational Data Architecture der IBM implementiert ist.

Remote beziehungsweise Distributed Unit of Work haben zweierlei gemeinsam: Zum einen koennen Updates nur auf einem einzigen DB2- System ausgefuehrt werden; zum anderen sind Remote-Updates nur unter TSO und Call Attachment Facility (CAF) moeglich, nicht aber unter CICS und IMS.

Die mit der Remote Unit of Work verbundenen Einschraenkungen sind der Preis, der fuer das statische Remote-SQL mit seinen Performance-Verbesserungen bezahlt werden muss. Bei der Auswahl einer Methode fuer eine zu realisierende verteilte DB2-Anwendung ist zu beachten, dass sich Remote und Distributed Unit of Work innerhalb einer einzigen Anwendung nicht kombinieren lassen.

Da eine verteilte Verarbeitung beliebiger SQL-Statements mit Zweiphasen-Commit ueber mehrere DB2-Systeme heute noch nicht vollstaendig unterstuetzt wird, hat der Entwickler beim Design einer verteilten Anwendung zwischen zwei Ansaetzen zu waehlen: Zum einen kann er solche Applikationen zunaechst auf der Basis der momentan verfuegbaren Remote und Distributed Unit of Work entwickeln. Kuenftige, signifikante Verbesserungen verteilter Verarbeitung unter DB2 lassen sich damit nur ueber eine Umcodierung bestehender Anwendungen nutzen.

Konsolidierung und Integration

Der zweite, eher langfristig angelegte Ansatz ist der, als erstes die Verteilung der Daten nach betrieblichen Gesichtspunkten zu planen, ohne auf die heutige Restriktionen verteilter Verarbeitung unter DB2 zu achten. In einem zweiten Schritt kann dann beim Anwendungsdesign nach technologischen und wirtschaftlichen Gesichtpunkten festgelegt werden, welche Funktionalitaet wann und wie realisiert wird.

Die Staerken verteilter Verarbeitung unter DB2, Version 2.3, liegen zum einen im einfachen Lesezugriff auf entfernte Daten und zum anderen in der Konsolidierung und Integration solcher Daten, die in verschiedenen DB2-Systemen existieren.

Wichtige Faktoren fuer das Design

Unabhaengig von der jeweiligen Anwendung gibt es eine Reihe weiterer Einflussfaktoren, die in der Entwurfsphase vor dem eigentlichen Design verteilter Verarbeitung zu betrachten sind. Jeder dieser Faktoren hat je nach Gegebenheit im jeweiligen Unternehmen ein bestimmtes Gewicht und praegt vorab als positives oder negatives Merkmal die verteilte Anwendung (siehe Abbildung).

Wichtig ist beim Design verteilter Anwendungen vor allem, die Kommunikation zwischen DB2-Systemen und anderen Anwendungen zu reduzieren, um Antwortzeiten, VTAM und Netz nicht mehr als noetig zu beeintraechtigen. Um sicherzustellen, dass VTAM und Netz das geplante Datenaufkommen optimal unterstuetzen, sollte die VTAM- Gruppe in die Planung und Implementierung der verteilten Anwendungen einbezogen werden.

Ein besonderes Augenmerk hat dabei dem "32K Block Fetch" zu gelten, das die Anzahl von Messages im Netzwerk reduzieren und damit Antwortzeiten fuer Remote-SQL drastisch verbessern kann. 32K Block Fetch ist fuer Ruow allerdings nur eingeschraenkt moeglich. Auf der anderen Seite besitzt diese Methode gegenueber der Distributed Unit of Work den Vorteil, dass sie - unter anderem durch die statisch vorgebunde SWL - das Netz mit erheblich weniger Kontrollinformationen belastet.

Zusammenfassed ist zu sagen, dass das DB2-Release 2.3 trotz der heutigen Einschraenkungen die Grundlage einer kuenftigen verteilten Verarbeitung darstellen kann, in deren Rahmen sich beliebige SQL- Statements auf mehreren lokalen und entfernten Systemen ausfuehren lassen. Wer sich auf diese Zukunft vorbereiten will, sollte an ausgewaehlten Applikationen erste Erfahrungen sammeln.

*Dirk Hoefer ist DB2-Systemberater bei der Candle GmbH in Muenchen.