Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.11.1989 - 

Die Verteilung muß technisch zu bewältigen sein

Ein zentrales Problem stellt die Synchronisation dar

Verteile Unternehmensstrukturen verlangen nach einer verteilten Datenhaltung. Einsicht ist da. Doch noch gibt es, so Kambis Ebrahimi*, kein Datenbanksystem, das den Anforderungen einer verteilten Umgebung wirklich gerecht wird. Allerdings wird bei Sybase, Oracle und anderen Herstellern fieberhaft daran gearbeitet.

- Die Organisation vieler Unternehmen ist in Form von Profitcentern, selbständigen Geschäftseinheiten und Projektteams dezentralisiert. Dennoch fallen in den meisten Betrieben die unternehmensweit benötigten Daten noch immer in die systemtechnische Zuständigkeit und Verantwortung der Zentrale, wohingegen die tatsächliche Zuständigkeit bei den dezentralen Organisationseinheiten liegt.

Häufig führt diese Zuständigkeitsteilung zu redundanter Datenhaltung, da es oft keine Verbindungen zwischen Abteilungsrechnern und Zentralrechnern gibt. Selbst bei den Fällen, in denen ein lokales Rechenzentrum einer Zweigniederlassung durch ein Kommunikationssystem mit dem Zentralrechner der Hauptverwaltung verbunden ist, existiert keine Software die das Problem der Redundanz beseitigt.

Die angesprochene Problematik kann mit Netzwerken und verteilten Datenbank-Managementsystemen (DDBMS) gelöst werden. Durch ein verteiltes System ist also eine Anpassung der Applikationen an die Organisationsstruktur möglich. Hierbei ist zu fragen:

- Läßt das verteilte Datenbanksystem eine beliebige Verteilung der Daten auch auf Organisationseinheiten zu, die selbst wiederum untergliedert sind?

- Gewährleistet es eine transparente Sicht an der Programmierschnittstelle?

Wenn die Daten einer Relation auf mehrere Knoten aufgeteilt sind, so dürfen Details wie der Speicherungsort und die Replikation nach außen nicht sichtbar sein.

Das Antwortzeitverhalten von datenintensiven Applikationen läßt sich durch eine entsprechende Fragmentierung oder Replikation entscheidend verbessern. Hochverfügbare Anwendungen können auch durch replizierte Datenhaltung erreicht werden. Zwei Kriterien hierzu:

- Unterstützt das DDBMS die replizierte Datenhaltung?

- Wenn es zu einem Knotenausfall kommt, nimmt es dann die Wiedereingliederung inklusive Aktualisierung vor?

In einem Wide Area Network (WAN) läßt sich möglicherweise auch die Belastung des Kommunikationssystems verringern, wenn die Zugriffslokalität hoch und die Anzahl der Änderungstransaktionen gering sind. Voraussetzung ist, daß das verteilte Datenbanksystem die replizierte Datenhaltung unterstützt.

Bei einer Umstellung des Datenbanksystems (DBMS) ist es vorteilhaft wenn das alte mit dem neuen als Teil eines heterogenen Datenbanksystems kommunizieren kann und so eine sichere periodische Konversion möglich ist.

Auch für die Integration von kommerziellen und technischen Anwendungen stellt sich dann die Frage, ob das DDBMS eine heterogene Betriebsumgebung hinsichtlich Hardware, Kommunikationssystemen und lokaler Datenbanksysteme unterstützt.

Trotz dieser offenen Fragen läßt sich bereits jetzt sagen, daß zentrale Systeme in Zukunft durch verteilte Datenbanksysteme ersetzt beziehungsweise um eine Verteilungskomponente erweitert werden. Der Übergang vom zentralen DBMS zum verteilten DBMS wird sich dabei in mehreren Stufen vollziehen.

Vom PC oder der Workstation aus kann auf ein zentrales DBMS mit beschränkten lokalen Retrieval-Funktionen zugegriffen werden, wobei die Anwendung auf dem PC oder der Workstation läuft. Dieses Verfahren wird auch als "Remote Database Access" bezeichnet. Im zweiten Schritt wird das Datenbanksystem auf mehrere Knoten mit gleichem Betriebssystem unter einem Kommunikationssystem verteilt. Hierbei entsteht ein transparentes verteiltes Retrieval, wobei Änderungen nur lokal am Wurzelknoten möglich sind. Daraufhin werden verteilte Änderungen und in einem letzten Schritt replizierte Datenhaltung sowie die heterogene Struktur der Betriebs- und Kommunikationssysteme ermöglicht.

Neue Methoden sichern elementare Anforderungen

Die folgenden Ausführungen beziehen sich schwerpunktmäßig auf das relationale Modell, gelten jedoch prinzipiell auch für das hierarchische und das Netzwerk-Datenmodell. Aber auch bei Systemen ohne replizierte Datenhaltung spricht man häufig schon von einem verteilten Datenbankkonzept.

Die Transaktionsverwaltung muß die Atomizität, Konsistenz, Persistenz und Isoliertheit für jede Transaktion gewährleisten. Diese besonders in verteilten Umgebungen komplexe Aufgabe erfordert neue Methoden zur Sicherung der elementaren Anforderungen.

Das Zwei-Phasen-Commit-Protokoll gewährleistet die gemeinsame Sichtbarmachung/Zurücksetzung von Transaktionen,

die Daten auf mehreren Knoten verändern. Knotenausfälle und Leistungsunterbrechungen dürfen die geforderte hohe Verfügbarkeit von Datenbanksystemen nicht beeinträchtigen und müssen aus diesem Grund näher betrachtet werden.

Das Zwei-Phasen-Commit-Protokoll gilt für globale Transaktionen, welche sich nicht auf lokale und nicht redundante Daten beschränken. Es stellt sicher, daß Änderungen auf allen oder keinem der beteiligten Knoten durchgeführt werden. Diese knotenübergreifend auszuführenden Transaktionen werden in Teilaufgaben für andere Knoten zerlegt.

Die Gesamtkoordination der globalen Transaktion wird durch eine Wurzeltransaktion übernommen. Hierbei erledigt die Wurzeltransaktion die Teilaufgabe, die Knoten für die globale Transaktion zu starten. Um, die wichtige, logisch gleichzeitige Beendigung der Teiltransaktionen zu erreichen, wird die Zwei-Phasigkeit des Commit-Protokolls benötigt.

Knotenausfall und Leistungsunterbrechung

Die erste Phase ist beendet wenn alle Subtransaktionen einen Commit/Abort an die Wurzeltransaktion gemeldet haben. Dennoch sind zu diesem Zeitpunkt die Änderungen der Subtransaktionen noch nicht nicht bar. Erst wenn die Wurzeltransaktion - in Abhängigkeit der Meldungen, die sie von den Subtransaktionen erhalten hat - einen Commit/Abort an die Subtransaktionen sendet, werden die Subtransaktionen diese Anweisung ausführen. Erhält die Wurzeltransaktion auch nur von einer Subtransaktion einen Abort, so sendet sie wiederum einen Abort an die Subtransaktionen.

Melden dagegen alle Subtransaktionen Commit, so sendet auch die Wurzeltransaktion eine Commit-Anweisung an die Subtransaktionen. In diesem Fall bedeutet dies für die Subtransaktionen die Sichtbarmachung der Änderungen. Bei Abort wird die Subtransaktion zurückgesetzt.

Eine Umsetzung dieses Protokolls kann folgendermaßen dargestellt werden: Neben der gewöhnlichen lokalen Transaktionsverwaltung existieren verteilte, miteinander kommunizierende Transaktionsverwalter. Der Knoten, der eine globale Transaktion anstößt, ist der Wurzelknoten. Dessen verteilter Transaktionsverwalter (VTV-Agent) übernimmt die Gesamtkoordination und kommuniziert mit den VTV-Agenten der anderen Knoten, welche wiederum ihre lokalen Transaktionsverwalter mit der Ausführung von Diensten beauftragen.

Ein Knotenausfall und eine Leistungsunterbrechung können hinsichtlich der Behandlung beim Zwei-Phasen-Commit-Protokoll als äquivalent betrachtet werden. Tritt einer dieser beiden Fälle bei einem Knoten während der Abarbeitung einer Subtansaktion auf, so muß gewährleistet sein, daß die Wurzeltransaktion dennoch in endlicher Zeit abgeschlossen werden kann. Dies wird mit einer "Time-Out-Bedingung" erreicht. Sie besagt, daß nur eine vorgegebene Zeit auf eine Antwort gewartet wird.

Die Fehlerbehandlung bei dem Ausfall einer Subtransaktion stellt kein Problem dar. Es muß lediglich nach folgenden unterschiedlichen Eintrittszeitpunkten differenziert werden:

1. Ausfall, bevor die Subtransaktion initiiert werden kann,

2. Ausfall, bevor die Subtransaktion Commit/Abort melden kann,

3. Ausfall, bevor die Subtransaktion eine Commit/Abort-Anweisung der Wurzeltransaktion empfangen hat.

Im ersten Fall wird die Wurzeltransaktion versuchen, die Subtransaktion auf einem anderen Knoten auszuführen. Gelingt dies nicht, wird die Wurzeltransaktion, wie im zweiten Fall, allen beteiligten Knoten eine Abort-Anweisung senden. Im dritten Fall muß ein Mechanismus die entsprechende Commit/Abort-Anweisung dem Knoten nach dessen Wiedereingliederung senden. Etwas aufwendiger, aber ebenso offensichtlich ist die Behandlung von Ausfallen des Wurzelknotens. Die beiden Ausfallzeitpunkte, die hier unterschieden werden müssen, sind:

- Ausfall der Wurzeltransaktion, bevor eine globale Commit/Abort-Entscheidung gefällt werden konnte, und

- Ausfall der Wurzeltransaktion, nachdem eine globale Commit/Abort-Entscheidung getroffen wurde.

Die Grundlage der Concurrency-Control-Theorie ist die Serialisierbarkeit von Transaktionen. Damit kann gezeigt werden, daß die parallele Ausführung einer Reihe von Transaktionen keine Anomalien enthält. Ein (paralleler) Ablauf von Transaktionen (Schedule) ist korrekt, wenn dieser serialisierbar ist, wenn das Ergebnis also äquivalent ist zu einer beliebigen permutierten seriellen Ausführung der Transaktionen. Die Äquivalent von zwei Schedules setzt voraus:

1. Jede Leseoperation liest Datenfelder, welche in beiden Schedules durch die gleichen Schreiboperationen erzeugt wurden.

2. Die abschließende Schreiboperation auf jedem Datenfeld ist in beiden Schedules gleich.

In verteilten Datenbanksystemen kommt folgende Bedingung für die Serialisierbarkeit von globalen Transaktionen hinzu: Angenommen, es existiert eine gesamte Reihenfolge von Transaktionen T1 bis Tn so, daß Ti in dieser gesamten Reihenfolge kleiner ist als Tj. Dann muß ein serialisierbares Schedule Sk' existieren, wobei Sk äquivalent zu Sk' ist. Außerdem muß Ti kleiner Tj in Sk' sein, für jeden Knoten k, auf dem beide Transaktionen Subtransaktionen ausgelöst haben.

Sechs Regeln für das Protokoll

In zentralen Datenbanksystemen und bisher auch in verteilten Umgebungen wird vorwiegend das "Strict Two-Phase-Lokking" (Strict 2PI) als Synchronisationsverfahren verwendet. Folgende Regeln gelten für dieses Protokoll:

- Objekte müssen vor dem Zugriff durch Transaktionen entsprechend der auszuführenden Operation gesperrt werden.

- Es werden nur Sperren angefordert, welche die jeweilige Transaktion noch nicht besitzt.

- Entsprechend einer Verträglichkeitstabelle werden die bereits existierenden Sperren anderer Transaktionen berücksichtigt.

- Während der Wachstums- oder Schrumpfungsphase einer Transaktion werden nur Sperren angefordert beziehungsweise freigegeben. Auf diesen bei den Phase beruht der Name des "Two-Phase-Locking"-Protokolls.

- Spätestens, wenn eine Transaktion beendet wird, müssen alle ihre Sperren freigegeben werden.

- Bevor eine Sperre freigegeben wird, muß die Wiederholbarkeit der Transaktion gesichert sein.

Folgende Fragen stellen sich im Zusammenhang des Strict 2PL-Sperrverfahrens mit DDBMS:

1. Gewährleistet Strict 2PL auch für DDBMS, daß nur serialisierbare Schedules erzeugt werden?

2. Sollen die erforderlichen Informationen, die Sperrtabellen, zentral auf einem Knoten oder dezentral auf jedem Knoten gefühlt werden?

3. Welche Auswirkungen hat das Sperrverfahren hinsichtlich der Entstehung und Behandlung von Deadlocks?

Zu Frage 1: Wenn eine globale Transaktion nach Strict 2PL gesperrt wird, so sind auch alle zugehörigen Subtransaktionen für jeden Knoten nach Strict 2PL gesperrt. Betrachtet man die Subtransaktionen gemeinsam, so kann festgestellt wertem daß Strict 2PL auch hier

die Serialisierbarkeit gewährleistet. Allerdings ist dieses Verfahren restriktiver als erforderlich. Es läßt nämlich nicht alle möglichen serialisierbaren Schedules zu, was zu unnötigen Wartezeiten von Transaktionen führen kann.

Zu Frage 2 und 3: Wenn die Sperrtabellen zentral gehalten werden, hat dies natürlich einen hohen Kommunikationsaufwand zwischen den VTV-Agenten der einzelnen Knoten zur Folge. Auch unter Verfügbarkeitsgesichtspunkten ist ein zentrales Sperren nicht empfehlenswert. Ein Ausfall des betreffenden Knotens kann zum Ausfall des gesamten Systems führen. Beim dezentralen Sperren werden die lokal am betreffenden Knoten verfügbaren Objekte in der Sperrtabelle geführt. Ein Nachteil einer solchen Implementierung ist der Aufwand der für die Erkennung von Deadlocks erforderlich ist.

Deadlocks werden häufig durch eine Verletzung der Time-Out-Bedingungen oder durch einen sogenannten "Wait-For-Graph" (WFG) erkannt. Dabei handelt es sich um einen gerichteten Graphen, in dem die Wartezustände der Transaktionen erfaßt werden. Existiert im WFG ein Zyklus, so besteht ein Deadlock. Bei zentralem Sperren und zentralem WFG ist die Deadlock-Erkennung unproblematisch.

In verteilten DBMS wird bei dezentralem Sperren auf jedem Knoten ein lokaler WFG geführt. Die lokalen WFGs sind nicht in der Lage, alle Deadlocks zu erkennen, da nur die lokal verfügbaren Objekte in den Sperrtabellen geführt werden. Diese lokal nicht erkennbaren verteilten Deadlocks müssen durch einen "Global Deadlock Detector" erkannt werden. Er erhält periodisch die Änderungen der lokalen WFGs.

Diese periodische Aktualisierung des globalen WFGs hat zwei Auswirkungen. Eine davon ist, daß Deadlocks für einen gewissen Zeitraum unentdeckt bleiben können. Die andere ist das mögliche Auftreten von sogenannten Phantom-Deadlocks. Letztere entstehen aufgrund von veralteten Kanten im globalen WFG.

Zur Bewältigung von Deadlocks bietet sich aber auch eine Präventivlösung an. Hier wird bei jeder Feststellung einer Wartesituation ein vorbeugender Test durchgeführt. Wenn dabei das Risiko eines Deadlocks festgestellt wird, wird entweder die wartende oder die blockierende Transaktion zurückgesetzt.

Von praktisch weit geringerer Bedeutung als Sperrverfahren wie das zuvor behandelte 2PL sind sogenannte optimistische und zeitstempelbasierte Synchronisationsverfahren.

Bei der Zeitstempel-Methode wird jede Transaktion mit einem Ordnungskennzeichen versehen. Auch jedes Objekt erhält eine Lese- und eine Schreib Zeilmarke. Eine Transaktion kann dann nur ein Objekt lesen oder schreiben, dessen Lese- oder Schreibzeitmarke höher ist als die der Transaktion. Die Erzeugung serialisierbarer Schedules ist hiermit gewährleistet. Jedoch ist relativ häufig ein unnötiges Zurücksetzen von Transaktionen erforderlich.

In verteilten Datenbanksystemen wirkt sich das Zurücksetzen wegen des zusätzlichen Kommunikationsaufwandes noch negativer als in zentralen Datenbanken aus. Dafür können bei der Zeitstempel-Methode normalerweise keine Deadlocks auftreten. Jedoch geht auch dieser Vorteil verloren, wenn etwa mit der "Conservative Timestamp Method" versucht wird, durch Pufferung von Transaktionen die Anzahl der Zurücksetzungen zu vermindern. Die Pufferung versetzt die Transaktionen in eine Art Wartezustand.

Als wesentlicher Vorteil für verteilte Datenbanksysteme bleibt, daß keine globalen Kontrollstrukturen verwaltet werden müssen. Damit entfällt auch der Kommunikationsaufwand für eine Aktualisierung von globalen Kontrollstrukturen. Die Zeitstempel-Methode ist also für DDBMS von höherer Bedeutung als für zentrale DBMS, weil sie mit nur lokal verfügbaren Kontrollstrukturen auskommt und damit auch die Implementierung wesentlich vereinfacht.

Drei Phasen des optimistischen Verfahrens

Die Grundannahme des optimistischen Verfahrens besagt, daß Konflikte - also Situationen, die ohne Synchronisierungsmaßnahmen zu Anomalien führen können - selten auftreten. Optimistische Synchronisationsverfahren bestehen aus drei Phasen:

1. Lesephase: Hier wird die Transaktion ohne Wartezustände ausgeführt. Die Änderungen werden in transaktionseigenen Arbeitsbereichen vorbereitet.

2. Validierungsphase: Überprüfung, ob sich die Änderungen in ein serialisierbares Schedule einordnen lassen. Bei negativem Ergebnis wird die Transaktion zurückgesetzt.

3. Schreibphase: Bei einem positiven Ergebnis werden die Änderungen in die Datenbank geschrieben.

Die Validierung kann nicht von jedem Knoten selbständig vorgenommen werden. Da eine globale Validierung erforderlich ist, kann im allgemeinen kein wesentlicher Vorteil hinsichtlich der Kommunikations kosten gegenüber dem 2PL erzielt werden.

Für die Bildung replizierter Daten in verteilten Datenbanksystemen - redundantes Sprechern von Daten - sprechen viele Gründe. So läßt sich die Antwortzeit verringern, da bei replizierter Datenhaltung eine höhere Zugriffslokalität besteht. Auch die Verfügbarkeit des Systems wird dadurch im allgemeinen erhöht. Das Halten solcher Datensätze hat jedoch einige Komplikationen für die Synchronisation zur Folge. Grundsätzlich muß folgendes gewährleistet sein:

1. Jede Änderung einer Kopie muß protokolliert werden, so daß Transaktionen, die auf an deren Knoten laufen, über die Ungültigkeit der lokal auf deren Knoten vorhandenen Kopie informiert sind.

2. Verschiedene Kopien desselben Objektes dürfen nicht gleichzeitig

durch zwei verschiedene Transaktionen verändert werden.

Als neue Aufgabe für verteilte Systeme kommt somit die Aktualisierung von Kopien hinzu. Auch ein Sperrverfahren wie das beschriebene Strict 2PL muß modifiziert werden, da es nun auch die Kopien zu sperren hat.

Aktualisierung auf drei Wegen

Die Aktualisierung kann synchron, teilsynchron oder asynchron erfolgen. Synchrones Update- umfaßt das Sperren aller Kopien des zu manipulierenden Objekts. Die Änderungen werden dann simultan auf allen betroffenen Kopien durchgeführt. Bei dieser Variante der Aktualisierung können Lese-Operationen auf jede beliebige Kopie zugreifen.

Die teilsynchrone Aktualisierung ist etwas fehlertoleranter als die synchrone Aktualisierung, da nur die verfügbaren Kopien geändert werden. Zum Aktualisierungszeitpunkt ausgefallene Knoten werden nach deren Wiedereingliederung aktualisiert. Lese-Operationen können ebenfalls auf eine beliebige Kopie zugreifen.

Beide Verfahren haben jedoch den Nachteil, daß die Änderungstransaktion bis zur Beendigung der Aktualisierung aller (beziehungsweise der meisten, bei der teilsynchronen Aktualisierung) Kopien warten muß. Wesentlich effizienter hinsichtlich der Antwortzeiten ist die asynchrone Aktualisierung. Bei diesem Verfahren wird die Aktualisierung der Kopien zu einem späteren Zeitpunkt, wenn eine Änderungstransaktion eine aktuelle Version einer Objektkopie (Primär-Kopie) benötigt, vorgenommen.

Auch das Sperren der Kopien kann synchron oder asynchron erfolgen. Synchrones Sperren bedeutet das Aufrechterhalten der Sperren bis zum Ende der Änderungstransaktion. Wie bei der synchronen Aktualisierung können Lese-Operationen auf eine beliebige Kopie zugreifen. Es besteht jedoch ebenfalls der Nachteil, daß für das synchrone Sperren alle Kopien verfügbar sein müssen.

Beim asynchronen Sperren wird nur die Kopie der Objekte gesperrt, auf denen eine Transaktion Änderungen vornimmt. Die betreffende Kopie wird als Primärkopie bezeichnet. Eine Änderung veralteter Kopien desselben Objektes durch andere Änderungstransaktionen muß bei einem solchen Sperrverfahren verhindert werden.

Ein asynchrones Sperrverfahren für verteilte Datenbanksysteme mit replizierter Datenhaltung ist das "Primary-Copy-Verfahren". Eine durchgeführte Änderung wird unmittelbar nur in der Primärkopie sichtbar. Die aktuelle Primärkopie wird nur bei Bedarf, im Sinne der asynchronen Aktualisierung, angefordert. Der Knoten mit der Primär-Kopie eines Objektes übernimmt auch dessen Synchronisation. Nachteilig an diesem Verfahren ist die eingeschränkte Verfügbarkeit aller Knoten mit einer entsprechenden Kopie beim Ausfall des Knotens mit der Primärkopie.

Kein optimales Synchronisationsverfahren

Das "Quorum-Consensus-Verfahren" (Mehrheitsprotokoll) erlaubt einer Änderungstransaktion, eine Kopie zu ändern, wenn eine Mehrheit der Kopien des betreffenden Objektes gesperrt werden kann. Jeder Knoten hält sich dafür Informationen in Form eines "Set of sites" welcher die Knoten enthält, mit denen er tatsächlich kommunizieren kann. Das Hauptproblem dieses Verfahrens entsteht, wenn Transaktionen inkonsistenze Sichten auf das "Set of sites" bekommen. Dies kann immer dann geschehen, wenn eine Teiltransaktion aus mehreren Subtransaktionen besteht.

Durch die Vorstellung der Synchronisation durch das Sperr-, Zeitstempel- und optimistische Verfahren sollte deutlich werden, daß im wesentlichen zwei Methoden verwendet werden. Einmal die Einreihung der Transaktionen in Warteschlangen (Sperrverfahren), und zum anderen die Zurücksetzung von Transaktionen (Zeitstempel- und optimistische Verfahren). Die letztgenannten sind frei von Deadlocks, wogegen bei Sperrverfahren eine Deadlock-Erkennung (WFG oder Time-Out) und deren Behandlung erforderlich ist.

Ein optimales Synchronisationsverfahren für verteilte Systeme gibt es nicht. Jedes hat spezifische Nachteile. So erfordern Sperrverfahren globale Kontrollstrukturen, und optimistische Verfahren haben eine schlechte Performance bei hoher Transaktionsbelastung oder vielen Konflikten. Ist der sogenannte Break-Point bei optimistischen Verfahren überschritten, so sinkt sogar der Durchsatz (Transaktionen/Sekunde) mit ansteigender Zahl der im System befindlichen Transaktionen.

Ein von Wang und Li vorgestellter Algorithmus für verteilte Datenbanksysteme sieht eine individuelle Auswahl von Protokollen durch jede Transaktion vor. Drei Synchronisationsverfahren sind in einem "Unified Concurrency" genannten Kontrollschema integriert. Die Auswahl eines Protokolls durch eine Transaktion findet dort auf der Basis einer Kostenfunktion statt. Aufgrund der Auswahlmöglichkeit aus mehreren Protokollen bezeichnen die Autoren ihren Algorithmus als Ansatz des "Dynamic Concurrency Control".

Parallelitätsgrad als Parameter

Gerade in verteilten Systemen hat die Wirkung des eingesetzten Synchronisationsverfahrens einen erheblichen Einfluß auf die Performance des Systems Hier ist der Hinweis wichtig; daß der Parallelitätsgrad ein Parameter ist, der starken Einfluß auf die Wirkung des Synchronisationsverfahrens ausübt und der jeweiligen Belastungssituation angepaßt werden sollte.

Abschließend muß jedoch gesagt werden, daß bisher kein mir bekannter Hersteller derzeit ein System anbietet, welches einen Funktionsumfang bietet, wie er zu Beginn (verteilte Änderungen, replizierte Datenhaltung, heterogene Betriebsumgebung) beschrieben worden ist.

Die noch geringen Installationszahlen belegen, daß der derzeitige Funktionsumfang von verteilten Datenbanksystemen, das heißt, keine verteilten Änderungen und keine replizierte Datenhaltung, für die Praxis nicht ausreicht. Fast alle großen Anbieter von DBMS entwickeln mit Vehemenz an ihren verteilten Systemen. Somit ist in den nächsten Jahren mit einigen leistungsfähigeren Systemen und steigenden Installationszahlen zu rechnen.

Kambis Ebrahimi ist Geschäftsführer der Firma Datenbankservice in Kirchheim.