19 Existierende Mehrrechner-Datenbanksysteme
Nachteilig ist, daß Sybase noch kein transparentes Zwei-Phasen-Commit anbietet, sondern die verteilte Commit-Bearbeitung weitgehend von den Anwendungsprogrammen zu kontrollieren ist. Insbesondere fungiert die Anwendung als Commit-Koordinator und muß beide Commit-Phasen durch explizite Aufrufe an die an der Transaktion beteiligten Server initiieren. Wird einer der Server bei der Commit-Behandlung "vergessen" oder ihm ein falsches Commit-Ergebnis mitgeteilt, ergeben sich inkonsistente Datenbankzustände! Ein weiteres Problem ist, daß die Ausführung der Commit-Koordinierung auf unsicheren Client-Rechnern (Workstations, PCs) stattfindet. Um zumindest den aktuellen Stand des Commit-Protokolls auf einer "sicheren" Seite zu vermerken, unterstützt Sybase die Einrichtung eines Commit-Services auf einem der Server. Allerdings liegt es wieder in der Verantwortung des Programmierers, diesen Service einzurichten und ihm das Commit-Ergebnis mitzuteilen (der Commit-Service protokolliert daraufhin die Commit-Entscheidung). Nur im Fehlerfall (Server-Ausfall, Timeout) wenden sich die involvierten Datenbank-Server an den Commit-Service, um den Zustand der Transaktion zu erfragen.
Das skizzierte Commit-Protokoll ist zudem auf Sybase-DBS beschränkt. Da Sybase SQL-Server die XA-Schnittstelle unterstützt, kann jedoch durch Nutzung eines XA-konformen TP-Monitors ein für die Anwendungen transparentes Commit-Protokoll erreicht werden.
Das neue Sybase OmniSQL-Gateway vereint die Funktionalität von Open Server sowie mehreren Gateways (zu DB2, Oracle, Rdb etc.). Damit wird es möglich, in einer SQL-Anweisung auf Daten mehrerer unabhängiger Datenbanken zuzugreifen, insbesondere um verteilte Join-Berechnungen vorzunehmen. Im OmniSQL-Gateway wird dazu ein globaler Katalog verwaltet, der den Benutzern ein hohes Maß an Verteilungstransparenz bietet. Mit dem globalen Katalog wird nicht nur die Datenlokation der einzelnen Objekte verborgen, sondern auch eine Angleichung unterschiedlicher Namenskonventionen und Datentypen vorgenommen. Damit wird die Funktionalität eines föderativen DBS erreicht. Eine Beschränkung besteht darin, daß der globale Katalog nicht mit den lokalen Kataloge der einzelnen DBS synchronisiert ist, so daß der Administrator durch Anwendung eines Tools lokale Schemaänderungen in den globalen Katalog bringen muß. Zudem sind Änderungen auf eine Datenbank beschränkt. Da das OmniSQL-Gateway an seiner Anwenderschnittstelle TransactSQL anbietet, werden auch globale gespeicherte Prozeduren unterstützt, in denen auf mehrere Datenbanken zugegriffen werden kann.
Eine weitere Neuerung in System 10 stellt der Replication Server dar, mit dem eine Kopie der Datenbank (bzw. Teilen davon) an einem entfernten Ort geführt werden kann. Die Aktualisierung der Kopie erfolgt asynchron durch Übertragung der Log-Daten. Dies ermöglicht eine schnelle Katastrophen-Recovery, indem beim Ausfall des Primärsystems die Verarbeitung mit der DB-Kopie fortgeführt wird. Im Normalbetrieb können lesende Anfragen, die nicht den absolut neuesten DB-Zustand benötigen, auf der Kopie arbeiten. Somit lassen sich komplexe Anfragen ohne Beeinträchtigung von OLTP-Anwendungen ausführen.
Der Navigation Server schließlich erlaubt eine parallele DB-Verarbeitung auf einem eng oder lose gekoppelten Parallelrechner. Dabei wird bei loser Kopplung ein Shared-Nothing-Ansatz verfolgt. Der Navigation Server ist eine dedizierte Komponente, die komplexe Anfragen in Teilanfragen zerlegt, die von mehreren Instanzen des Sybase SQL Servers parallel bearbeitet werden. Neben Anfragen können jedoch auch OLTP-Anwendungen auf derselben Datenbank bearbeitet werden. Die Festlegung der Datenpartitionierung erfolgt durch ein spezielles Tool (Configurator), das u.a. Angaben zum erwarteten Lastprofil als Eingabe verlangt. Es kann jedoch auch die aktuelle DB-Verarbeitung überwachen und Änderungen in der DB-Verteilung empfehlen. Der Navigation Server wurde zusammen mit NCR entwickelt und ist daher zunächst auf NCR-Parallelrechnern lauffähig.