19 Existierende Mehrrechner-Datenbanksysteme

19.4 ASK/Ingres

In den siebziger Jahren entstand an der Univ. Berkeley unter M. Stonebraker mit "University Ingres" ein erster Prototyp eines relationalen DBS (neben System R von IBM). Eine kommerzielle Ingres-Version für den Unix-Bereich wurde von der 1980 gegründeten Firma Relational Technology Inc. vertrieben, die 1989 in Ingres Corp. umfirmierte. Seit Oktober 1990 gehört Ingres zur ASK-Gruppe.

Ingres unterstützte als eines der ersten kommerziellen DBS eine verteilte DB-Verarbeitung. Mit der bereits 1983 eingeführten Kommunikationskomponente Ingres/Net können Anwendungen auf Client-Rechnern SQL-Operationen an entfernte Server-Datenbanken stellen. Das föderative Mehrrechner-DBS Ingres/Star wurde 1986 eingeführt. Der Zugriff auf Fremd-DBS kann über eine Reihe von Gateways erfolgen, welche unter der Bezeichnung Enterprise Access zusammengefaßt werden. Daneben gibt es seit kurzem eine Komponente (Replicator) zur Realisierung einer Schnappschuß-Replikation. Das neuerdings als OpenIngres bezeichnete DBS unterstützt die XA-Schnittstelle und arbeitet darüber mit mehreren TP-Monitoren zur verteilten Transaktionsverarbeitung zusammen. Schließlich bietet Ingres eine Unterstützung des Shared-Disk-Ansatzes für Vax-Cluster.

Ingres/Net ermöglicht den Zugriff auf Ingres-Datenbanken sowie - über Gateways - auf Fremd-DBS und Dateisysteme an entfernten Rechnern. Seit Ingres-Version 6.3 kann dabei in einer Transaktion auf mehrere Datenbanken zugegriffen werden. Das dann benötigte verteilte Zwei-Phasen-Commit-Protokoll mußte zunächst in der Anwendung ausprogrammiert werden, wodurch die Konsistenz der beteiligten Datenbanken von der Korrektheit der Anwendungsprogramme abhing! Dieses Manko wurde zwischenzeitlich durch ein "transparentes" Commit-Protokoll behoben.

Für den Zugriff auf heterogene Datenbanken bietet Ingres die Anfragesprache "Open SQL" an, welche aus einer Untermenge der gebräuchlichsten SQL-Dialekte gebildet wurde. Weiterhin wurde eine Menge generischer Fehler-Codes festgelegt, um den Anwendungen eine einheitliche Fehlerbehandlung auch beim Zugriff auf heterogene Datenbanken zu ermöglichen. Diese Festlegungen werden vom Ingres-DBS sowie den Ingres-Gateways beachtet. Gateways existieren nicht nur für SQL-DBS (z.B. DB2, Rdb), sondern auch für nicht-relationale DBS (IMS, HP Allbase) sowie Dateisysteme (RMS). In letzterem Fall sind die SQL-Operationen durch ein vorgesetztes Ingres-DBS zu verarbeiten, welches das Fremd-DBS nur für elementare Satzoperationen verwendet.

Ingres/Star ist eine zentralisierte Systemkomponente, über die SQL-Anweisungen an mehrere unabhängige DBS gestellt werden können (Abb. 19-5). Die Datenbanken werden in einer Föderation zusammengefaßt, wobei dem Benutzer mit einem gemeinsamen föderativen Schema eine weitgehende Verteilungstransparenz geboten wird. Darüber ist es auch möglich, in einer SQL-Operation auf mehrere Datenbanken zuzugreifen (z.B. verteilte Joins). Die Optimierung globaler Anfragen erfolgt durch Ingres/Star, ebenso die Zerlegung in lokal ausführbare Teilanfragen und das Mischen und Nachbearbeiten der Teilergebnisse. Weiterhin ist Ingres/Star für die Erkennung globaler Deadlocks sowie die Durchführung des verteilten Commit-Protokolls verantwortlich. Wie in Abb. 19-5 skizziert, kann auch Ingres/Star über Gateways auf relationale und nicht-relationale Fremd-DBS bzw. Dateisysteme zugreifen. Nicht gezeigt sind in der Abbildung die Ingres/Net-Komponenten, die in jedem der beteiligten Rechner zur Kommunikationsunterstützung vorliegen müssen.

Abb. 19-5: Einsatz von Ingres/Star

Ingres/Star erlaubt die Definition mehrerer DB-Föderationen mit jeweils einem eigenen föderativen Schema. Das föderative Schema legt im wesentlichen nur für jede Datenbank die Relationen fest, die an der Föderation beteiligt sein sollen. Eine Schemaintegration zur Auflösung semantischer Konflikte erfolgt jedoch nicht. Nachteilig ist daneben die Zentralisierung von Ingres/Star, wodurch Verfügbarkeit und Knotenautonomie stark eingeschränkt werden. Ferner wird diese Komponente leicht zum Flaschenhals des Systems, da sie sämtliche globalen Anfragen bearbeiten muß.

Die Zusatzkomponente Ingres/Replicator dient zur Erstellung und Wartung von Schnappschuß-Replikaten, die aus Ingres-Datenbanken oder aus über Gateways erreichbaren Fremd-Datenbanken abgeleitet werden [Zi93]. Bei der Aktualisierung der Kopien werden nur die seit der letzten Aktualisierung angefallenen Änderungen erfolgreich beendeter Transaktionen propagiert, so daß die Kopie stets transaktionskonsistent bleibt. Neben dem Datenaustausch zwischen zwei Datenbanken werden auch Mehrfach-Replikation (mehrere, verteilte Kopien einer Quelle) sowie kaskadierende Replikationen unterstützt. Als problematisch ist die Möglichkeit wechselseitiger Replikationen einzustufen, bei der Änderungen in der Quell- und Zieldatenbank möglich sind. Denn da die Replikate außerhalb der DBS verwaltet werden, können Änderungskonflikte (wenn also dasselbe Objekt unkoordiniert in beiden Kopien geändert wird) zwar erkannt, müssen jedoch manuell behoben werden!