Design and Implementation of a Distributed DBMS: consisting of an IDBM DB2/MVS as Server and several IBM DB2/2 Clients with replicated data

Autor
Ch. Fischer
Masterarbeit
MTE9301 (1993)
Zitat
Diplomarbeit, Betreuung: o. Univ.-Prof. Dr. Michael Schrefl, ausgeführt an der Technischen Universität Wien, Institut für Informationssysteme, Abt. Datenbanken und Expertensysteme, February 1995.

Kurzfassung (Englisch)

This master thesis describes the design and implementation of a Distributed Database Management System (DBMS) consisting of an IBM DATABASE2 MVS/ESA (DB2/MVS) as server and several IBM DATABASE 2 OS/2 (DB2/2) clients with replicated data. The different systems can be connected by Advanced program to Program Communication (APC), which is based on IBM Systems Network Architecture (SNA) logical unit type 6.2 (LU 6.2).

IBM Distributed Relational Database Architecture (DRDA) defines 3 levels of Units of Work (Remote Unit of Work, Distributed Unit of Work and Distributed Request). In one of these levels, distribution of data in a replicated way is available. At the highest level (Distributed Request) data are distributed by partitioning. At the moment, IBM offers DDCS/2 (Distributed Database Connection Services for OS/2) for accessing different DBMSs (e.g. DB2/MVS, DB2/6000) in a transparent way. For the client as well as for the user, it is not visible if the database is located at the DB2/2-Server or at another system, as DB2/MVS or DB2/6000. DDCS/2 does not allow the distribution of data from one database in a transparent and partitioned way.

The new distributed DBMS has to assure that all data are stored in the server (DB2/MVS). Fragments of the primary copy can be replicated into the clients (DB2/2) with the highest possible transparency. The data replication into DB2/2 systems helps to reduce response time for data requests, network traffic, and moreover, the local resources (e.g., disk space) will be better used. Above all, data availability will be improved.

The following components and their alternatives for a strategy are stated: Fragmentation Alternatives, Replication Alternative, Replica Update Alternatives, and Concurrency Control Protocol Alternatives. Five strategies are chosen out of the many possible strategies. These solutions are characterized by their potential advantages and disadvantages. The solution, consisting of static replication with horizontal fragmentation and asynchronous replica updates based on locking, is specified and implemented towards a Distributed DBMS consisting of a IBM DB2/MVS as Server and several IBM DB2/2 Clients with Replicated Data.

Kurzfassung (Deutsch)

Diese Diplomarbeit beschreibt das Design und die Implementierung eines verteilten Datenbankmanagementsystems (DBMS), das aus einem IBM DATABASE 2 MVS/ESA System (DB2/MVS) als Server und mehreren IBM DATABASE 2 OS/2 Systemen (DB2/2) als Clients mit replizierten Daten besteht. Für die Verbindung der Systeme stehen Advanced Program to Program Communication (APPC) Schnittstellen zur Verfügung. APPC basiert auf IBM Systems Network Architecture (SNA) logical unit type 6.2 (LU 6.2).

IBM Distributed Relational Database Architecture (DRDA) definiert drei Stufen von Units of Work (Remote Unit of Work, Distributed Unit of Work und Distributed Request). In keiner dieser dreiStufen ist die Verteilung der Daten durch Replikation vorgesehen. Auf der höchsten Ebene (Distributed Request) erfolgt die Verteilung der Daten durch Partionierung. IBM bietet derzeit das Produkt DDCS/2 (IBM SAA Distributed Database Connection Services/2) für den transparenten Zugriff auf Daten, die sich auf anderen DBMS (z.B. DB2/MVS, DB2/6000) befinden, an. Für den Client bzw. Benutzer ist nicht erkennbar, ob sich die Datenbank auf einem DB2/2-Server oder auf einem anderen System (z.B. DB2/MVS, DB2/6000) befindet. DDCS/2 erlaubt derzeit noch keine Partionierung der Daten einer Datenbank und damit eine transparente Verteilung dieser Daten auf mehrere Server.

Das zu entwerfende verteilte DBMS soll sicherstellen, daß alle Daten auf dem Server (DB2/MVS) einmal existieren (primary copy). Von diesem zentralen Datenbestand können Fragment auf die einzelnen Clients (DB2/2) möglichst transparent repliziert werden. Die Replikation von Daten in den DB2/2 Systemen trägt dazu bei, daß die antwortzeiten bei Abfragen verkürzt, die Netzwerkauslastung gesenkt und die lokalen Ressource (z.B. Plattenspeicher) besser genutzt werden. Außerdem wird dadurch die Verfügbarkeit der Daten erhöht. In Hinblick auf die Aufgabenstellung werden die neuesten Entwicklungen im Bereich von häufig verwendeten kommerziellen Systemen (ORACLE, INGRES, SYBASE) dargestellt.

Die möglichen Lösungsalternativen werden durch die Varianten folgender Komponenten beschrieben: Fragmentierungsart, Replizierungsart, Replizierungskontrolle und Art des Transaktionsmanagements. Aus den zahlreichen Möglichkeiten für Lösungsalternativen werden fünf Lösungsalternativen dargestellt. Diese fünf Strategien werden aufgrund ihrer potentiellen Vor- und Nachteile vergliechen. Die Lösungsstrategie auf Basis von statischer Replikation, horizontaler Fragmentierung und asynchroner Replizierungskontrolle mit einem Sperrprotokoll wird, in Hinblick auf ein verteiltes DBMS bestehend aus einem IBM DB2/MVS System als Server und mehreren IBM DB2/2 Clients mit replizierten Daten, spezifiziert. Die implementierten Module werden kurz beschrieben.