Replikation in verteilten Datenbanken

Präsentation zum Thema: "Replikation in verteilten Datenbanken"—  Präsentation transkript:

1 Replikation in verteilten Datenbanken
Gliederung: Einführung Grundlagen und Verfahren Realisierte Technologien am Beispiel von Sybase Jürgen Bittner SQL GmbH Dresden

2 ist eine Funktionalität in
Begriff Replikation ist eine Funktionalität in Integrierten Shared-Nothing-Mehrrechner- Datenbanksystemen, wie z.B. Workstation/Server-DBS und allen DBS mit multipler Allokation von Fragmenten Föderativen Mehrrechner-Datenbanksystemen (homogene und heterogene) zum Synchronisieren der Daten, d.h. zum (konsistenten) Verwalten von Datenkopien Verwalten abhängiger Aktionen, die an verschiedenen Orten einer verteilten Datenbank stattfinden sollen (Steuern von Geschäftsprozessen)

3 Begriff Replikation (konsistentes) Verwalten von Kopien von Daten in verschiedenen Orten einer verteilten Datenbank und zum Steuern von Geschäftsprozessen

4 Ziele der Replikation Verbesserte Verfügbarkeit der Daten Erhöhte Performance Lokale Autonomie in Verbindung mit Integrationsprozessen Ziele verteilter Datenbanken weitgehend in Übereinstimmung mit Zielen der Replikation

5 Betriebliche Anforderungen
Zuverlässige Bereitstellung von Up-to-Date Informationen Unternehmensweite Konsolidierung von dezentralen Einheiten Kombination von Decision Support mit OLTP Unterbrechungsfreier Betrieb trotz geplanter oder ungeplanter Systemausfälle

6 Replikationsstrukturen (Beispiele)
Zentral verfügbare Daten werden verteilt repliziert zur Unterstützung lokaler Anfragen (Decision Support Replicates) Zusammenführung dezentral verfügbarer Daten in einem zentralen Ort (Corporative Data Consolidation) dezentral verfügbare Daten werden zu den jeweils anderen Orten für Anfragen repliziert, ohne daß Eigentümerprinzip gilt (Corporate Data Integration) Daten eines Ortes werden vollständig zu einem anderen Ort repliziert (Stand-by database) In der Praxis mehr oder weniger gemischte Verwendung dieser Strukturen

7 Real-Time Decision Support
Primary OLTP Datenbank OLTP Applikationen Decision Support Applikationen Replicate Decision Support Datenbank Fortlaufende Weitergabe von Änderungen erzeugt eine ‘Echtzeit-Kopie‘ Beseitigt unvorhersehbare Einbrüche bei der OLTP Performance aufgrund langlaufender Abfragen

8 Unternehmensweite Konsolidierung
NY Replicate Site Primary Sites Netzwerk NY Corporate London London Tokyo Tokyo Lokale Autonomie - jeder Standort verwaltet seine eigene Primärkopie Einige oder alle Daten werden in die Zentrale repliziert DB-Schemata müssen nicht identisch sein Up-to-Date Informationen immer verfügbar

9 Unternehmens-Datenverarbeitung
Workgroup Computing Central Datastore Mobile Computing Embedded Computing

10 Replikation in verteilten Datenbanken
Gliederung: Einführung Grundlagen und Verfahren Überblick zum Stand bei einigen DBMS Realisierte Technologien am Beispiel von Sybase

11 Verfahren zur Replikation
Strenge Konsistenz erfordert Synchrone Replikation Schwache Konsistenz ermöglicht Asynchrone Replikation Konsistenz- anforderung Verfahren Verteilte Transaktionen mit 2-PC Dump, Reload Table Snapshot Trigger- und Regel- basierte Replikation Transaktions- basierte Replikation Timestamp- basierte Replikation Performance, Verfügbarkeit Geringe Aktualität lokale Autonomie Konsistente Transaktionen lokale Autonomie Administrativer und Performance Overhead lokale Autonomie Eigentümer prinzip oder hierarchische Topologie ? Script- Entwicklung Probleme, Besonder- heiten

12 Grundlegende Entscheidungskriterien
Bei der Entscheidung über eine Replikationstechnologie ist zu betrachten: Geschäftsanforderungen für die verteilte Datenbank Technologische Bedingungen und Grenzen der Anwendungsumgebung Verfügbare Resourcen für Entwicklung und Administration

13 Was ist ein Verteiltes System?
C.J. Date’s Arbeitsdefinition: “A distributed database system consists of a collection of sites, connected together via some sort of network, in which: Each site is a database system in its own right Sites have agreed to work together (if necessary), so that a user at any site can access data anywhere in the network exactly as if the data were all stored at the user’s own site.”

14 Verteilte Datenbanken Praktische Faktoren
Nicht alle Systeme erfordern, dass alle Daten an allen Orten verfügbar sind. Nicht alle Systeme erfordern, dass alle Daten an allen Orten stets konsistent sind. Der Grad, in dem das System die Anforderungen der Definition erfüllen soll, ist der wichtigste Faktor bei der Auswahl der Replikationstechnologie.

15 Probleme der verteilten Datenhaltung
Wahl der Technologie ist abhängig von: Konsistenz Lokale Autonomie Datenpartitionierung (-fragmentierung) Transaktionssteuerung Zugriffsmöglichkeiten (connection) Topologie

16 Konsistenz Strenge Konsistenz erfordert, dass sich alle Daten in einem konsistenten Zustand befinden. Schwache Konsistenz erlaubt “nicht-aktuelle” Daten. Latenz ist das Maß, wie lange die Daten brauchen, um konsistent zu werden. In manchen Fällen ist das System nie konsistent, weil es immer Änderungen gibt, die noch nicht repliziert wurden.

17 Strenge oder schwache Konsistenz
Welche Version der Daten wird benutzt? Konto Kto.-Nr. Stand 200 1000 Konto Kto.-Nr. Stand 200 1000 Waterloo Paris

18 Lokale Autonomie Jeder Ort sollte unabhängig von den anderen Orten operieren können. Daten Datenbank-Struktur Applikations-Software Zeit

19 Daten-Partitionierung
Auch als Fragmentierung bezeichnet. Nur die Daten, die an einem Ort benötigt werden, sollen dort gespeichert sein. Die Datenbank eines Ortes ist ein “complete” subset der Daten. Ein Teil der Daten muß für verschiedene Orte dupliziert werden.

20 Daten-Partitionierung Update Anywhere
Primary keys müssen eindeutig sein in der gesamten Verteilten Datenbank. Falls mehrere Orte insert in die gleiche Tabelle ausführen. Erfordert einen Mechanismus zur Konflikterkennung und -auflösung. Falls mehrere Orte berechtigt sind, die gleichen Zeilen zu ändern.

21 Daten-Partitionierung
Bezugsobjekt der Fragmentierung ist Tabelle Jedes Fragment ist eine Tabellen-Untermenge Vollständige Tabelle Teilmenge der Zeilen (row subset) Teilmenge der Spalten (column subset) Row und Column Subset

22 Daten-Partitionierung Grundbegriffe
Forderung: Fragmentierungstransparenz und Replikationstransparenz immer ?

23 Transaktions-Steuerung
Die gewählte Technologie sollte die ACID-Bedingung erfüllen: Atomicity, Consistency, Isolation, Durability Nur “committed data” sollten repliziert werden. “committed data” müssen repliziert werden. Fehler beim Replizieren von “committed data” müssen erkennbar sein. Änderungen müssen in allen Datenbanken in der gleichen Reihenfolge verarbeitet werden. Atomicity The entire transaction must succeed or fail; no partial completions may occur Consistency A transaction must leave the system in the correct state. Isolation The effect of a transaction is not evident to other transactions until it is committed Durability The effects of the committed transaction are permanent and durable.

24 Zugriffsmöglichkeiten
Welcher Netzwerk-Typ steht den Orten zur Verfügung? High-speed LAN/WAN Low-speed Dial-up (RAS) Wireless Indirect ( , ftp) Internet (HTTP) Sneaker-net

25 Hierarchisch Peer-to-peer
Topologie Hierarchisch Peer-to-peer database database database Consolidated database Remote database/ Consolidated database Remote database Remote database database database database Remote database Remote database

26 Topologie Welche Art von Beziehungen existiert zwischen den Orten?
Peer-to-peer (für update anywhere) Jeder Ort kann Daten zu irgendeinem anderen Ort transferieren. Keine zentralisierte Masterkopie existiert. Konfliktauflösung ist extrem schwierig. Es gibt keinen Ort zum Erkennen und Auflösen der Konflikte.

27 Topologie Hierarchisch
Jeder Ort sendet und empfängt Daten auf- und abwärts innerhalb der Hierarchie. Eine zentrale Masterkopie (konsolidierende Datenbank) existiert. Daten müssen stets über eine konsolidierende Datenbank zu anderen Orten repliziert werden. Erkennen und Auflösen der Konflikte sind in der konsolidierenden Datenbank implementiert.

28 Topologie Peer-to-peer (für Eigentümerprinzip)
Jeder Ort kann Daten zu irgendeinem anderen Ort transferieren. Keine zentralisierte Masterkopie existiert, aber jedes Fragment besitzt genau einen Eigentümer(ort) - Primärkopie. Konflikte werden vermieden. Konfliktauflösung ist nicht erforderlich.

29 Weitere Probleme Anzahl der Orte Hersteller
Bestimmte Technologien sind bei großer Anzahl besser geeignet (mass deployment). Hersteller Sind die DBMS der verschiedenen Orte vom gleichen Hersteller ?

30 Verfahren zur Replikation
Strenge Konsistenz erfordert Synchrone Replikation Schwache Konsistenz ermöglicht Asynchrone Replikation Konsistenz- anforderung Verfahren Verteilte Transaktionen mit 2-PC Dump, Reload Table Snapshot Trigger- und Regel- basierte Replikation Transaktions- basierte Replikation Timestamp- basierte Replikation Performance, Verfügbarkeit Geringe Aktualität lokale Autonomie Konsistente Transaktionen lokale Autonomie Administrativer und Performance Overhead lokale Autonomie Eigentümer prinzip oder hierarchische Topologie ? Script- Entwicklung Probleme, Besonder- heiten

31 Streng konsistente Replikation
Replikation muß bei meisten DBMS programmiert werden, nur ein Hersteller gestattet Definieren der Replikation für Tabellen Benutzt das 2-Phase-Commit (automatisch oder programmiert) alle Kopien sind identisch großer Protokoll-Overhead reduziert die Fehlertoleranz und Verfügbarkeit

32 Streng konsistente Replikation
Änderungen werden “simultan” in allen Datenbanken ausgeführt. 200 1000 Konto Kto.-Nr. Stand 200 1000 Konto Kto.-Nr. Stand Bitte Warten, das Konto wird gerade geändert Withdraw $100 Waterloo Paris

33 Streng konsistente Replikation : Konsistenz
Wenn absolute Konsistenz gefordert ist. Die Transaktion wird in allen oder keiner der beteiligten Datenbanken realisiert.

34 Streng konsistente Replikation Lokale Autonomie
Sehr niedriges Niveau der lokalen Autonomie. Falls ein Ort ausfällt, ist das gesamte System nicht mehr verfügbar. 200 1000 Konto Kto.-Nr. Stand 200 1000 Konto Kto.-Nr. Stand X Leider ist das System nicht verfügbar Abhebung $100 Waterloo Paris

35 Streng konsistente Replikation : Daten-Partitionierung
Daten können beliebig partitioniert werden. Die Applikation muß die notwendigen Änderungen überall ausführen. Da die Transaktion in den beteiligten Datenbanken simultan ausgeführt wird, gibt es keine Probleme mit primary keys oder Konflikten.

36 Streng konsistente Replikation : Transaktions-Steuerung
Ein Distributed Transaction Server (DTS) ist erforderlich. Datenbank-Server mit DTS-Funktionalität Spezieller DTS Application Server mit DTS-Funktionalität

37 Verteiles 2-Phasen-Commit
(Koordinator) R3 Teil-TA-Ausführung PREPARE PREPARE Logging READY (FAILED) Logging COMMIT COMMIT (ABORT) Logging, Sperrfreigabe ACK Logging Basisverfahren: 4 N Nachrichten (N = Anzahl der Teil-TA) 2 (N + 1) Log-Writes ABORT-Nachrichten gehen nur an Teil-TA, die nicht mit FAILED gestimmt haben Problem bei 2PC: bei Koordinatorausfall lange Blockierung möglich

38 Streng konsistente Replikation : Zugriffsmöglichkeiten
Zuverlässiges Netzwerk ist erforderlich. Geschwindigkeit der Applikation ist stark abhängig von der Geschwindigkeit des Netzwerks.

39 Streng konsistente Replikation : Topologie
Typisch für eine peer-to-peer Topologie. Da alle Datenbanken “simultan” geändert werden, ist keine Masterkopie erforderlich.

40 Streng konsistente Replikation Weitere Probleme
“Leicht” zu verstehen Sehr wenige Orte können unterstützt werden. Verteilung der Daten schwer skalierbar, da das Hinzufügen weiterer verteilter Komponenten die Performance senkt Heterogene Umgebungen “einfach” zu unterstützen.

41 Schwach Konsistente Replikation
Primäre Kopie der Daten primäre und replizierte Daten sind nicht zu jeder Zeit identisch Hohe Performance erreichbar hohe Verfügbarkeit der Daten und Fehlertoleranz

42 Verfahren der schwach konsistenten Replikation
Dump und Reload Table Snapshot Replikation Trigger- und regelbasierte Replikation Transaktions-basierte Replikation Timestamp-basierte Replikation

43 Dump und Reload Datenbank Backups Datenbank Logs
Versenden von Daten zu entfernten Orten Versenden von Transaktionen zum Zentralort gewöhnlich lange Verzögerungszeit Schwierigkeiten mit großen Datenmengen

44 Dump und Reload Topologie
database database database database database database

45 Table Snapshots Replikation
Mehrere Hersteller unterstützen definierte Snapshots Replikate sind Kopien von: Tabellen Teilmengen von Tabellen Views, Queries Ausführung automatisch (Trigger- oder zeitgesteuert) oder manuell meist read-only, aber auch eine updatable snapshot-Lösung existiert Problem: begrenzte Konsistenz muß von Anwendungen berücksichtigt werden spezielle Lösungen zum Erreichen akzeptabler Performance

46 Trigger-basierte Replikation
Primärort Replikatort 1 Replikatort 2 begin Propagation queue update T1 Call uppdate T1(...) Trigger delete T1 Call delete T1(...) Trigger insert T2 Call insert T2(...) Trigger update T3 Call update T3(...) Store and forward 2-PC Trigger Transaktion . commit Transaktion

47 Trigger-basierte Replikation (1)
Trigger - ursprünglich Konzept zur Sicherung der Datenintegrität, hauptsächlich der Referenzintegrität Belastung mit Replikationslogik führt zu großen Administrationsproblem “The excessive use of triggers can create a complex web of mechanisms, which may be difficult to maintain in a large application“ Replikation bezüglich einer Tabelle erfordert i.a. mehrere Trigger Performance Probleme: Triggerverfahren bewirkt Belastung der Transaktionen zeilenweises Auslösen, evtl. für jeweils mehrere Zielorte Daten- und Systemressourcen werden für längere Zeit gesperrt

48 Trigger-basierte Replikation (2)
Trigger in Verbindung mit “Update anywhere“ (symmetrische Replikation) erfordern synchronisierten Triggercode weitere Belastung der Triggeradministration, z.B. bei 100 Tabellen die über 5 Server repliziert werden, sind bis zu 3 x 5 x 100 = 1500 Trigger notwendig; falls ein Server hinzuzukommt, sind alle zu ändern

49 Transaktions-basierte Replikation
Primärort Replikatort 1 Replikatort 2 Begin Update T1 delete T1 insert T2 update T3 Commit Replication Server DB- Server Transaktion Log Transfer Manager Replication Server Replication Server DB- Server Transaktion Log Stable queue

50 Symmetrische Replikation versus Eigentümerprinzip
replizierte Daten dürfen an mehreren Orten geändert werden Konfliktauflösung erforderlich nur strukturgleiche Tabellen können repliziert werden Objekt der Datenreplikation ist Tabelle Objekt der Prozedurreplikation ist identische Prozedur Eigentümerprinzip jedes Datenelement besitzt einen Eigentümer (Primärort), der dieses Datenelement ändern darf; die Replikatorte dieser Datenelemente dürfen nur lesen keine Konflikauflösung erforderlich Replikate können strukturell von Primärdaten abweichen kleinstes Objekt der Datenreplikation ist Spalte einer Zeile Objekt der Prozedurreplikation ist “beliebige“ Prozedur

51 Transaktions-basierte Replikation:
Peer-to-peer/Eigentümerprinzip Modulare Architektur mit Support für Heterogenität Andere Daten Quellen Replication Agent Network Replication Server Andere Daten Ziele DB- Server Replication Agent Replication Driver for ODBC Replication Server verwaltet die Konfiguration und Verteilung von Transaktionen Replication Agents protokollieren Update Transactions an den Quell-Datenbanken Gateways und Replication Driver für ODBC liefern Änderungen für DBMS verschiedener Hersteller 8

52 Transaktions-basierte Replikation: Hierarchisch
Message Agent Message Agent DB Remote database Inbox Network LAN Log Message Agent Consolidated database DB Inbox Log Remote database DB Inbox Log 8

53 Transaktions-basierte Replikation
Product sku_key qty_oh 1234 10 9 8 X 10 9 X 10 UPDATE Product SET qty_oh = 9 WHERE sku_key = 1234 UPDATE Product SET qty_oh = 8 WHERE sku_key = 1234 Product sku_key qty_oh 1234 10 9 8 X 10 10 9 X

54 Transaktions-basierte Replikation Konsistenz
Niedriges bis hohes Konsistenz-Niveau ist möglich. Geschwindigkeit des “store and forward messaging system” entscheidet wie konsistent die Datenbank ist. Irgendeine Latenz ist immer vorhanden.

55 Transaktions-basierte Replikation Lokale Autonomie
Hohe lokale Autonomie Datenbank benötigt nur Daten, die von der Applikation benötigt werden.

56 Transaktions-basierte Replikation Partitionierung
Daten sind meist partitioniert. Jede DB hat gemeinsame Daten und spezifische Daten. Update anywhere erfordert: Unique primary keys. Konflikt-Erkennung und Auflösungsverfahren.

57 Transaktions-basierte Replikation Transaktions-Steuerung
Transaktions-Steuerung muss garantieren: Senden und Verarbeiten in korrekter Reihenfolge. Keine Transaktion darf verlorengehen.

58 Transaktions-basierte Replikation Zugriffsmöglichkeiten
Ob eine direkte Verbindung erforderlich ist oder nicht ist abhängig von den Latenzanforderungen.

59 Transaktions-basierte Replikation Topologie
Peer-to-peer und hierarchische Topologien können benutzt werden. Konfliktauflösung erfordert in der Regel ein hierarchisches Modell.

60 Transaktions-basierte Replikation Weitere Aspekte
Nur Transaktionen werden transportiert, deshalb: Ist es möglich viele DB zu unterstützen. Der Durchsatz ist unabhängig von der DB-Grösse.

61 Timestampbasierte Replikation: mit Synchronisations-Server
Consolidated Database Server Consolidated DB TCP/IP ODBC Remote Database Server (ASA or UltraLite) MobiLink Client (ASA or UltraLite) MobiLink Server TCP/IP Remote DB

62 Timestampbasierte Replikation
Gegenwärtiger Zustand der Daten wird zwischen den DB transportiert. Kann als “complete refresh” oder nur für geänderte Zeilen ausgeführt werden.

63 Timestampbasierte Replikation
Product sku_key qty_oh 1234 10 8 X 10 UPDATE Product SET qty_oh = 8 WHERE sku_key = 1234 Product sku_key qty_oh 1234 10 9 X 10 10 9 8 X

64 Timestampbasierte Replikation Konsistenz
Niedriges bis hohes Konsistenz-Niveau ist möglich. Daten sind nur unmittelbar nach der Synchronization konsistent. Frequenz der Synchronisation beinflusst das Niveau der Konsistenz aber in jedem Fall gibt es irgendeine Latenz.

65 Timestampbasierte Replikation Lokale Autonomie
Hohe lokale Autonomie Datenbank benötigt nur Daten, die von der Applikation benötigt werden.

66 Timestampbasierte Replikation Partitionierung
Daten sind meist partitioniert. Jede DB hat gemeinsame Daten und spezifische Daten. Update anywhere erfordert: Unique primary keys. Konflikt-Erkennung und Auflösungsverfahren.

67 Timestampbasierte Replikation Transaktions-Steuerung
Transaktionsgrenzen werden nicht verwaltet. Some operation sequences can not be synchronized. (i.e. insert then delete of a row with the same primary key value) Most synchronization technologies “batch” the operations. e.g. all deletes, then inserts, then updates

68 Timestampbasierte Replikation Zugriffsmöglichkeiten
Erfordert eine stabile Netzwerk-Verbindung während des Synchronisation-Prozesses. Geschwindigkeit der Verbindung beeinflusst den Umfang der Daten der synchronisiert werden kann.

69 Timestampbasierte Replikation Topologie
Peer-to-peer und hierarchische Topologien können benutzt werden. Peer-to-peer ist schwierig, wenn update anywhere erlaubt ist. Welche Kopie ist korrekt? Wer löst einen update-Konflikt auf ?

70 Timestampbasierte Replikation Weitere Aspekte
Heterogene Umgebungen sind unterstützt. Jeder Ort kann unabhängig voneinander synchronisieren, deshalb können viele Orte unterstützt werden.

71 Replikation in verteilten Datenbanken
Gliederung: Einführung Grundlagen und Verfahren Überblick zum Stand bei einigen DBMS Realisierte Technologien am Beispiel von Sybase

72 Replication Server Replicate Sites Primary Sites Adaptive Server
Agent Replication Server DirectCONNECT (Native drivers) Adaptive Server/Enterprise Adaptive Server/Anywhere Oracle Informix OS/390 DB2 Replication Toolkit for MVS DirectCONNECT/ Anywhere (ODBC)

73 Replication Server Hauptmerkmale
Transaktionen werden zu einem Replication Server gesendet, der diese zwischenspeichert und zu den Zielorten sendet Eine schnelle Verbindung wird vorausgesetzt Nahezu real time (niedrige Latenz) Große Datenmengen Begrenzte Anzahl von Orten Heterogene DBMS-Umgebung unterstützt Uni-direktional

74 Replication Server Primärort Replikatort Replication
Agent Replication Server

75 Replication Server - Komponenten Primärort
Ursprung der Datenänderung Mehrere Hersteller von RDBMS unterstützt Hält Eintragungen für alle Transaktionen, normalerweise im Transaktions-Log, nicht bei allen RDBMS möglich

76 Replication Server - Komponenten Replication Agent
Liest das Transactions-Log des Primärortes Übergibt “committed transactions” in der Reihenfolge ihrer Verarbeitung an den Replication Server.

77 Replication Server - Komponenten Replication Server
Empfängt Transaktionen von Replication Agents Speichert die Transaktionen solange bis sie an allen Replikatorten erfolgreich verarbeitet werden konnten Verwaltet die Verbindungen zu allen Replikatorten Automatisches Recovery und Restore Bestimmt welche Orte die Transaktion benötigen und startet sie in der korrekten Reihenfolge

78 Replication Server - Komponenten Replication Server
Verhindert “circular” transactions. Ermöglicht Nutzer-programmierte “function strings” zur Manipulation der Transaktion Daten-Konvertierung Konvertieren des SQL in heterogenen Umgebungen Erkennt SQL-Fehler

79 Replication Server - Komponenten Replikatort
Verarbeitet SQL, das vom Replication Server gesendet wurde Ein Replikatort kann auch als Primärort definiert werden, wenn bi-direktionale Replikation benötigt wird

80 Replication Server - Fragmentierungsmodelle
Verteilte Primärfragmente create replication definition Rep_DB1 with primary at DSDB1.DB1 with all tables named ‘table’…... DB1 Fragment 1- primär Fragment 2- repliziert Fragment 3- repliziert DB2 DB3 Fragment 1- repliziert Fragment 1- repliziert Fragment 2- repliziert Fragment 2- primär Fragment 3- primär Fragment 3- repliziert

81 Replication Server - Fragmentdefinition
Replication definition: create replication definition Rep_DB1 with primary at DSDB1.DB1 with all tables named ‘table’ (columnname…, ) primary key (id,...) searchable columns (id,….) create subscription Sub_DB2 for Rep_DB2 with replicate at DB1 where id = ‘…’ create subscription Sub_DB3 for Rep_DB3 with replicate at DB1 where id = ‘...’ Subscription definition:

82 Replication Server - Fragmentierungsmodelle
Konsolidierende Replikation Fragment 1 - primär Fragment 1- repliziert Fragment 2- repliziert Fragment 3- repliziert Fragment 2 - primär Fragment 3 - primär

83 SQL Remote ASE ASA OR ASA ASA MAPI VIM FILE FTP SMTP MAPI VIM FILE FTP

84 SQL Remote Hauptmerkmale
Vollständige lokale Autonomie Partitionierung durch: Column values Subqueries Where clauses Nachrichtenbasiert (keine session) MAPI (Microsoft), VIM (Lotus), SMTP, FTP and File

85 SQL Remote Hauptmerkmale
Hierarchisch Konsolidierende DB ist ASA oder ASE Remote DB sind ASA Homogen Viele Tausende Remote DB möglich Zentralisierte Administration Gestattet entfernte Administration einschließlich Schemaänderungen Für Endanwender völlig transparent Datensicherung mobiler Rechner

86 SQL Remote Komponenten
Consolidated Database Server Message Agent Consolidated Data Store Message System Remote Database Server Message Agent Remote Data Store

87 SQL Remote - Message Agent
Network LAN Consolidated database DB DB Remote database Inbox Inbox Log Log 8

88 SQL Remote - Message Agent
Network WAN Consolidated database Remote database DB Inbox R Inbox C DB Log Log 8

89 SQL Remote Komponenten Konsolidierende DB
Enthält eine Kopie aller Daten, die zu replizieren sind Realisiert Konflikterkennung und Auflösung Transaktionen werden im Transactions-Log aufgezeichnet Verwaltet zusätzliche Daten im Transaktions-Log über Transaktionen und Fragmente, die zu replizieren sind

90 SQL Remote Komponenten Message Agent
Liest im Transactions-Log die Transaktionen, die repliziert werden sollen Bildet Nachrichten für jeden Ort, der Teilhaber der Transaktion ist Kooperiert mit dem Nachrichtensystem Garantiert korrektes Versenden und Verarbeiten der Transaktionen Erkennt Konflikte

91 SQL Remote Komponenten Message System
Sichert die “store and forward”-Technologie Benutzt: MAPI SMTP VIM File FTP

92 SQL Remote Komponenten Remote DB
Enthält eine Teilmenge der Daten Transaktionen werden im Transactions-Log aufgezeichnet Verwaltet zusätzliche Daten im Transaktions-Log über Transaktionen und Fragmente, die zu replizieren sind

93 SQL Remote: Publisher und Subscriber
“Publication” definiert die zu replizierenden Daten “Subscription” definiert das Replikationsziel Bi-direktionale Replikation Publish Subscribe Subscribe Publish

94 SQL Remote - Fragmentdefinition
Publication definition: CREATE PUBLICATION publication-name (TABLE table-name [(column-name,…)] [WHERE search-condition] [SUBSCRIBE BY expression], …) CREATE SUBSCRIPTION TO publication-name [(subscription-value)] FOR subscriber-id Subscription definition:

95 MobiLink ASA, ASE, Microsoft, Oracle, IBM
HTTP, TCPIP Serial HotSync, Wireless ASA, PalmOS, CE, Pagers, Phones

96 MobiLink Hauptmerkmale
Vollständige lokale Autonomie Vollständige Kontrolle über Daten-Partitionierung auf der konsolidierenden DB durch die Verwendung von Scripts Scriptsprache der Konsolidierenden DB Keine Partitionierung in der remote DB

97 MobiLink Hauptmerkmale
Session basiert Bi-direktional Mittlere bis hohe Latenz

98 MobiLink Hauptmerkmale
Hierarchische Topologie Konsolidierende DB kann ODBC-DB sein Sybase, Microsoft, Oracle, IBM ASA und/oder UltraLite remote DB Optimiert für Tausende remote DB Skalierbar durch konsolidierende DB

99 MobiLink Komponenten Consolidated Database Server
Consolidated Data Store TCP/IP ODBC Remote Database Server (ASA or UltraLite) MobiLink Client (ASA or UltraLite) MobiLink Server TCP/IP Remote Data Store

100 MobiLink Synchronization Server
Interface zwischen konsolidierender DB und remote server. Arbeitet mit ODBC-basierter KDB Verantwortlich für vollständige Sicherung des Synchronisationsprozesses Unterstützt mehrere Synchronisationsprozesse simultan

101 MobiLink Konsolidierende Synchronisations- Logik
SQL statements werden in der konsolidierenden DB ausgeführt Geschrieben in der Sprache der KDB Steuert den Synchronisations-Server. Datenfluß in beiden Richtungen Behandelt Konflikte

102 MobiLink Remote Synchronisations- Logik
ASA und UltraLite verfolgen alle Datenänderungen Eine Synchronisations-Komponente realisiert: Lesen aller Änderungen zum Aufbau eines “upload stream” Empfangen des “download stream” und verarbeiten der Änderungen in der remote DB