In den meisten Anwendungen wäre es äußerst problematisch, wenn die gesamte konsolidierte Datenbank heruntergeladen werden müsste, wenn bestimmte Daten auf dem entfernten Gerät aktualisiert werden sollen. Der Zeitaufwand und die Netzauslastung wären enorm und würden das gesamte System praktisch zum Stillstand bringen. Es gibt verschiedene Verfahren, um sicherzustellen, dass der Upload und der Download nur die von den verschiedenen Benutzern benötigten Elemente umfassen.

Zunächst sollte eine entfernte Datenbank nur eine Teilmenge der Tabellen und Spalten in der konsolidierten Datenbank umfassen. Ein Vertriebsmitarbeiter in der Region A benötigt beispielsweise andere Tabellen und Spalten als ein Vertriebsmitarbeiter in der Region B oder ein Vorgesetzter.

Von den Tabellen und Spalten, die auf einem entfernten Gerät zur Verfügung gestellt werden, sollten nur diejenigen für die Synchronisation vorgesehen werden, die tatsächlich synchronisiert werden müssen. Sie können in einer MobiLink-Anwendung Tabellen und Spalten unabhängig von ihren Namen zuordnen, sofern ihre Datentypen übereinstimmen. Daten werden standardmäßig hoch- und heruntergeladen, doch Sie können in MobiLink auch festlegen, dass bestimmte Spalten nur für den Upload oder für den Download vorgesehen sind.

Die Synchronisation sollte nur die Zeilen in eine entfernte Datenbank herunterladen, die für den Benutzer relevant sind. Sie können den Download nach der entfernten Datenbank, nach dem Benutzer oder nach anderen Kriterien aufteilen. Ein Vertriebsmitarbeiter in der Region A benötigt beispielsweise nur Daten über die Region A.

Sie sollten nur die geänderten Daten aktualisieren. In einer MobiLink-Anwendung basiert der Upload auf dem Transaktionslog. Daher werden Daten standardmäßig nur dann hochgeladen, wenn sie in der entfernten Datenbank geändert wurden. Um dasselbe Verfahren für den Download festzulegen, wählen Sie die Zeitstempel-basierte Synchronisation, sodass das System die Uhrzeit des Daten-Downloads aufzeichnet. Daten werden dann nur heruntergeladen, wenn sie nach diesem Zeitpunkt geändert wurden.

Sie können auch ein System mit einer prioritären Synchronisation implementieren. Zeitsensitive Daten werden in diesem Fall häufig aktualisiert, während weniger zeitkritische Daten nachts oder beim Einstecken des Geräts in eine Dockingstation aktualisiert werden. Sie können die Synchronisation mit Priorität implementieren, indem Sie verschiedene Publikationen erstellen, deren Ausführung zu unterschiedlichen Zeiten geplant ist.

Ihre Benutzer profitieren möglicherweise auch von einem Push-Synchronisationssystem, in dem Daten bei Bedarf an entfernte Geräte übergeben werden. Wenn ein Speditionsunternehmen beispielsweise von einer Verkehrsunterbrechung erfährt, kann es eine Aktualisierung für die LKW-Fahrer herunterladen, die in dem betreffenden Gebiet unterwegs sind. Dies wird in MobiLink als serverinitiierte Synchronisation bezeichnet.

Angenommen Sie haben ein Lager. Jeder Mitarbeiter hat ein mobiles Gerät, über das er den Lagerbestand aktualisiert, wenn er Kisten hinzufügt oder entnimmt. Es wird bei 100 Kisten begonnen, sodass die entfernte Datenbank jedes Mitarbeiters den Wert 100 enthält, ebenso wie die konsolidierte Datenbank. David entnimmt 20 Kisten. Er aktualisiert seine Datenbank und führt eine Synchronisation durch. Jetzt enthält seine Datenbank ebenso wie die konsolidierte Datenbank den Wert 80. Nun entnimmt Susan zehn Kisten. Wenn Susan jedoch ihre Datenbank aktualisiert und synchronisiert, geht ihre Anwendung davon aus, dass die konsolidierte Datenbank den Wert von 100 Kisten enthält und nicht 80. Dadurch entsteht ein Upload-Konflikt.

In dieser Lageranwendung besteht die Lösung darin, eine Konfliktlösungslogik zu erstellen, die besagt, dass der richtige Wert der von David geänderte Wert abzüglich des von Susan eingegebenen Werts ist:

80 - (100 - 90) = 70

Diese Konfliktlösungslogik funktioniert für die Lagerverwaltung, sie ist jedoch nicht für alle Geschäftsanwendungen geeignet. Sie können in MobiLink folgende Fälle mit Konfliktlösungslogik abdecken:

In einigen Fällen können Sie das System so planen, dass keine Upload-Konflikte auftreten. Wenn Daten auf den entfernten Datenbanken aufgeteilt werden, damit sie nicht überlappen, können Konflikte vermieden werden. Wenn es jedoch zu Konflikten kommen kann, sollten Sie eine anwendungsgesteuerte Lösung für die Erkennung und Lösung der Konflikte erstellen.

Für den Upload von Daten, zur Erkennung von Konflikten und zur Synchronisation von gelöschten Zeilen in der konsolidierten Datenbank muss jede synchronisierte Tabelle im Datenbanksystem eindeutige Primärschlüssel haben. Jede Zeile muss einen Primärschlüssel haben, der nicht nur in der Datenbank selbst, sondern im gesamten Datenbanksystem eindeutig ist. Primärschlüssel dürfen nicht aktualisiert werden.

MobiLink bietet mehrere Möglichkeiten, eindeutige Primärschlüssel zu garantieren. Eine von ihnen ist, den Datentyp des Primärschlüssels auf eine GUID festzulegen. Ein GUID (Globally Unique Identifier) ist ein global eindeutiger Bezeichner und eine 16 Byte große hexadezimale Zahl. MobiLink stellt die Funktion NEWID zur Verfügung, die bewirkt, dass für eine neue Zeile automatisch ein GUID erstellt wird.

Eine weitere Lösung ist ein zusammengesetzter Schlüssel. In MobiLink hat jede entfernte Datenbank einen eindeutigen Wert, der als entfernte ID bezeichnet wird. Ihre Primärschlüssel können zum Beispiel aus der entfernten ID und einem normalen Primärschlüssel, z.B. einer Ordinalzahl, gebildet werden.

SQL Anywhere stellt auch eine Lösung mit globalen Autoinkrement-Werten zur Verfügung. Sie deklarieren hierbei eine Spalte als GLOBAL AUTOINCREMENT. Beim Hinzufügen einer Zeile wird der Primärschlüssel automatisch erstellt, indem der letzte Wert erhöht wird. Diese Lösung ist am besten geeignet, wenn die konsolidierte Datenbank eine SQL Anywhere-Datenbank ist.

Schließlich können Sie auch einen Pool von Primärschlüsseln erstellen, die auf entfernte Datenbanken verteilt werden.

Wie Sie das geeignete Primärschlüsselsystem auswählen, hängt wie zahlreiche andere Entscheidungen bei der Entwicklung einer Synchronisationslösung davon ab, welche Stufe der Kontrolle über die konsolidierte und die entfernte Datenbank Sie benötigen. Häufig müssen die entfernten Datenbanken in der Lage sein, ohne jegliche Administration zu arbeiten. Sie stellen möglicherweise auch fest, dass es schwierig ist, das Schema in der konsolidierten Datenbank zu ändern. Die Wahl des RDBMS-Systems für die konsolidierte Datenbank schränkt möglicherweise auch Ihre Möglichkeiten ein, da nicht alle RDBMS-Systeme alle Funktionen unterstützen.

Ein weiterer wichtiger Punkt in einem Synchronisationssystem ist die Behandlung von Zeilen, die aus der konsolidierten Datenbank gelöscht werden. Angenommen Sie löschen eine Zeile aus der konsolidierten Datenbank. Wenn ein anderer Mitarbeiter seine entfernte Datenbank das nächste Mal synchronisiert, wird die Löschung heruntergeladen und die Zeile damit aus seiner Datenbank gelöscht. Was geschieht jedoch mit der Löschung in der konsolidierten Datenbank? Die Zeile kann nicht gelöscht werden, da die Löschung auch noch in die entfernte Datenbank eines weiteren Benutzers heruntergeladen werden muss.

Es gibt zwei Möglichkeiten, Download-Löschungen zu handhaben. Sie können jeder Tabelle eine Statusspalte hinzufügen, die anzeigt, ob die Zeile gelöscht wurde. In diesem Fall wird die Zeile nie gelöscht, sondern nur für die Löschung markiert. Sie können die für die Löschung markierten Zeilen in regelmäßigen Abständen bereinigen, wenn Sie sicher sind, dass alle entfernten Datenbanken aktualisiert wurden. Alternativ dazu können Sie auch für jede Tabelle eine Schattentabelle erstellen. In der Schattentabelle werden die Primärschlüsselwerte von gelöschten Zeilen gespeichert. Wenn eine Zeile gelöscht wurde, füllt ein Trigger die Schattentabelle, und die Werte in der Schattentabelle legen fest, was in der entfernten Datenbank gelöscht werden soll.

In einem synchronisierten Datenbanksystem sollten nur festgeschriebene Datenbanktransaktionen synchronisiert werden. Außerdem sollten alle festgeschriebenen Transaktionen, die zu synchronisierende Daten einbeziehen, synchronisiert werden. Andernfalls sollte ein Fehler generiert werden. Dies ist das Standardverhalten in MobiLink.

Sie müssen auch die Isolationsstufe der Verbindung zur konsolidierten Datenbank berücksichtigen. Sie müssen eine Isolationsstufe verwenden, die eine optimale Performance ebenso wie die Datenkonsistenz sicherstellt. Die Isolationsstufe 0 (READ UNCOMMITTED) eignet sich gewöhnlich nicht zur Synchronisation, da sie Dateninkonsistenzen verursachen kann.

Standardmäßig verwendet MobiLink die Isolationsstufe SQL_TXN_READ_COMMITTED für Uploads und, wenn möglich, die Snapshot-Isolation für Downloads (andernfalls wird SQL_TXN_READ_COMMITTED verwendet). Die Snapshot-Isolation vermeidet das Problem, dass Downloads blockiert werden, bis Transaktionen in der konsolidierten Datenbank geschlossen werden. Doch nicht alle RDBMS-Systeme unterstützen die Snapshot-Isolation.

Die jährliche Umstellung auf die Sommer- bzw. Winterzeit kann während der Stunde, in der die Zeit umgestellt wird, ein Problem für synchronisierte Datenbanken darstellen. Im Herbst wird die Zeit von 03:00 Uhr auf 02:00 Uhr zurückgestellt. Wenn Sie versuchen, zwischen 02:00 Uhr und 03:00 Uhr zu synchronisieren, ist der Zeitstempel der Synchronisation nicht eindeutig. Es kann zum Beispiel unklar sein, ob es sich um das erste 02:15 Uhr oder das zweite 02:15 Uhr handelt.

Um dieses Problem zu lösen, können Sie den Server während der Zeitumstellung eine Stunde lang herunterfahren oder Sie können den konsolidierten Datenbankserver auf die koordinierte universelle Zeit (Coordinated Universal Time, UTC) umstellen.

• Synchronisationsmethoden