SQL Anywhere Studio 9.0 erweist sich als fähiges DBMS

Die meisten Entwickler werden wohl aufgrund der Replikationsfähigkeiten und des geringen Platzbedarfs, durch welche die Synchronisierung mit Remote-Datenbanken ermöglicht wird, zu SQL Anywhere neigen. Ob diese sich nun in einem Datenzentrum ein paar Häuser weiter, in einem Laptop am anderen Ende der Welt oder in einem Handheld irgendwo im Außendienst befinden: Die Synchronisierung mit den Datenbanken ist möglich.

Sybase SQL Anywhere setzt drei Replikationstechniken ein. MobiLink und SQL Remote wurden für die Replikation zwischen einer zentralen Datenbank und vielen Remote-Datenbanken konzipiert. Der Replication Server ist für die Replikation zwischen einer relativ geringen Anzahl von Datenbanken in (fast) Echtzeit bestimmt.

Der Hauptunterschied zwischen dem Konzept des Replication Server und denen der beiden anderen Methoden besteht darin, dass der Replication Server eine Änderung bestimmter Daten nur an einem Ort zulässt. Sowohl SQL Remote als auch MobiLink erlauben die gleichzeitige Änderung gleicher Daten an mehreren Orten und stellen dann einen Weg zur Lösung möglicher Konflikte zur Verfügung.

Die drei genannten Replikationstechniken entsprechen drei unterschiedlichen Methoden zum Verschieben von Daten zwischen Datenbanken. Die erste, MobiLink, ist eine sitzungsbasierte Propagationsmethode.

Bei der sitzungsbasierten Methode findet eine Synchronisierung statt, wenn sich ein Remote-System über eine direkte Kommunikationsverbindung, wie z. B. einer WAN-Verbindung, einem herkömmlichen Modem oder einem Funkmodem, wieder mit dem Zentralserver verbindet. Je nachdem, wie frisch die Daten sein müssen, stellen die Remote-Systeme in festgelegten Abständen von Minuten bis hin zu Wochen regelmäßig eine Verbindung her. Die Synchronisierung geht bei der sitzungsbasierten Methode wie folgt vor sich:

• Der Remote-Server stellt eine Verbindung mit dem Synchronisationsserver her.
• Die Änderungen werden hochgeladen.
• Er wartet, bis der Synchronisationsserver die Änderungen konsolidiert hat.
• Er erhält alle relevanten Änderungen.
• Nachdem er diese erhalten hat, schickt er eine Bestätigung an den Synchronisationsserver zurück, darüber dass er die Änderungen erfolgreich integriert hat, wonach die Verbindung getrennt wird.

Die zweite Propagationsmethode verwendet SQL Remote, und sie ist nachrichtenbasiert. Einfach ausgedrückt: Datenbanken verschieben untereinander Aktualisierungen und Änderungen mittels Nachrichten. Bei diesen Nachrichten handelt es sich um Dateien, die mittels einer Übertragungsmethode, wie z. B. FTP, in einem bestimmten Verzeichnis gespeichert werden, sie können aber auch speziell formatierte E-Mail-Nachrichten sein. Ein jeder Datenbank angeschlossener Nachrichtenagent verschickt Nachrichten in Bezug auf Änderungen seiner eigenen Daten. Dieser Agent erhält auch Nachrichten von einer oder mehreren Datenbanken und ändert die Datenbank dem Inhalt der erhaltenen Nachrichten entsprechend. Diese Methode wurde für den Einsatz bei Datenbanken konzipiert, die nur gelegentlich verbunden sind.

Zu guter Letzt gibt es die verbindungsbasierte Replikation mit dem Replication Server. Diese Methode wurde für die schnelle Echtzeitreplikation unter einer kleinen Anzahl von Servern über eine ständige Hochgeschwindigkeitsverbindung konzipiert. Bei dieser Methode werden Änderungen fast unmittelbar, mit nur sehr geringer Wartezeit, von einem Datenbankserver an einen anderen Server übertragen.

Zweifellos hängt die gewählte Methode von den Verbindungsmethoden, der zulässigen Wartezeit zwischen Aktualisierungen, der Anzahl vorhandener Datenbanken usw. ab. Die Dokumentation von SQL Anywhere stellt eine exakte Tabelle zur Verfügung, mit der man die im Einzelfall günstigste Methode bestimmen kann.

Die Festlegung der Propagationsmethode ist eine Sache, deren Konfiguration jedoch wieder eine ganz andere. Für diesen Test wurde die Replikation mit SQL Remote konfiguriert. Die zentrale Datenbank befand sich auf dem Windows 2000 Server, die Remote-Datenbank auf einem Laptop mit Windows 2000 Professional. Auch wenn aufgrund von räumlichen Beschränkungen nicht alle Details der Installation behandelt werden können, folgt nachstehend eine Übersicht der erforderlichen Schritte und was diese beinhalten.

Zunächst wurde die zentrale Datenbank erstellt und die angemessenen Rechte wurden hinzugefügt, um die Replikation zu ermöglichen. Dies erforderte die Vergabe von Herausgaberechten an eine Benutzer-ID, um die Quelle ausgehender Nachrichten zu identifizieren. Anschließend wurde allen Benutzer-IDs, die Nachrichten erhalten sollten, Remote-Rechte erteilt. Dann musste die Art der Nachricht ausgewählt werden. Möglich waren entweder E-Mails oder die Speicherung von Dateien an irgendeinem Speicherplatz zum späteren Austausch. Für diesen Test wurde der Austausch von Dateien gewählt, und die Austauschdateien der Datenbanken wurden in einem Verzeichnis auf dem Server gespeichert.

SQL Anywhere verwendet ein Herausgabe- und Abonnementmodell in SQL Remote, weswegen eine Publikation zur Beschreibung der zu replizierenden Daten und ein Abonnement zum Empfang der Daten erstellt wurden. Danach wurde die Remote-Datenbank auf dem Laptop mit der SQL Anywhere-eigenen Utility zur Extraktion der Datenbank erstellt, wodurch alle Schritte unternommen werden konnten, um eine Remote-Datenbank mitsamt Abonnenten und erforderlichen Benutzer-IDs zu erstellen.

Um die Replikation zu testen, wurde die zentrale Datenbank verändert und dann die Replikationsdatei erstellt, indem der Nachrichtenagent gegenüber der konsolidierten Datenbank ausgeführt wurde. Dies wird über eine Kommandoanfrage getan. Danach wurde der Nachrichtenagent auf dem Laptop ausgeführt, um die Daten zu erhalten und um anschließend nachzuprüfen, ob die Änderungen tatsächlich repliziert wurden. Anschließend wurde der Vorgang umgekehrt, um die Änderungen an den Server zu senden.