DE60306932T2

DE60306932T2 - Schnelle Datenbankreplikation

Info

Publication number: DE60306932T2
Application number: DE60306932T
Authority: DE
Inventors: Andreas Fleck; Jan Dehnel; Stefan Richter; Michael Wittrich; Frank Steichhahn
Original assignee: Alcatel CIT SA; Alcatel SA
Current assignee: Alcatel Lucent SAS
Priority date: 2003-10-08
Filing date: 2003-10-08
Publication date: 2007-05-16
Anticipated expiration: 2023-10-09
Also published as: EP1522932B1; US7788224B2; ATE333680T1; DE60306932D1; US20050080825A1; EP1522932A1

Description

Die Erfindung betrifft ein Verfahren zur Aktualisierung mindestens einer entfernten Datenbank durch Datensätze einer Haupt-Datenbank gemäß der Präambel von Anspruch 1 und auf ein Haupt-Datenbanksystem gemäß der Präambel von Anspruch 6.
Im Bereich der Telekommunikation ist es oft erforderlich, eine Anzahl von entfernten (untergeordneten) Datenbanken entsprechend einer Haupt-Datenbank zu aktualisieren, wobei sich die Haupt-Datenbank z.B. bei einem Telekommunikations-Dienstanbieter befindet. Daher müssen die Daten oder Untermengen von Daten einer Haupt-Datenbank an jede einer Vielzahl von entfernten untergeordneten Datenbanken geliefert werden, z.B. für die Rufnummern-Mitnahme zwischen verschiedenen Dienstanbietern. Um ein aktuelles Daten-Abbild einer Untermenge von Daten in einer untergeordneten Datenbank zu halten, muss zwischen der Haupt-Datenbank und der untergeordneten Datenbank ein Sofort-Datenfilter bereitgestellt werden.
Jedes Mal, wenn Daten in die Haupt-Datenbank eingegeben werden, z.B. wenn ein neuer Teilnehmer eingegeben werden muss oder wenn Teilnehmerdaten aktualisiert werden müssen, müssen diese Daten zu den entfernten oder untergeordneten Datenbanken gesendet werden. Die Haupt-Datenbank enthält zu Verwaltungszwecken mehr Daten als für die Steuerung des Telekommunikationsnetzes erforderlich sind. Darüber hinaus enthält die Haupt-Datenbank möglicherweise Informationen über Zustände, die in Zukunft aktiviert werden. Daher hat die Haupt-Datenbank eine andere Datenstruktur als Proxy- und untergeordnete Datenbanken.
Im US-Patent US005721914 wird ein hierarchisches Daten-Verteilungs-System offen gelegt, in dem eine schrittweise Aktualisierung über mehrere Datenbanken-Ebenen durchgeführt wird. Durch Eingabe von Aktualisierungs-Daten in das System wird der Verteilungs-Prozess aufgerufen, der mit der Aktualisierung des Haupt-Datenbank-Systems beginnt, und dann werden die unteren Datenbank-Ebenen aktualisiert. Dieses Patent wird als der am nächsten liegende bisherige Stand der Technik betrachtet.
In dem Oracle-Handbuch mit dem Titel "Oracle9i Streams" vom Oktober 2002 (XP002271720) wird in Kapitel 22 offen gelegt, wie Daten zwischen verschiedenen Datenbanken, die auch Zwischen-Datenbanken enthalten, durch so genannte Streams repliziert werden können. Zusätzlich dazu wird in dem Oracle-Handbuch mit dem Titel "Oracle9i Database Administration's Guide" vom März 2002 (XP002271722) in Kapitel 28 das Konzept eines gleichzeitigen Zugriffs oder einer Änderung von Daten in mehreren Datenbanken, die sich in mehreren Maschinen befinden, detailliert beschrieben. Der Zweiphasen-Durchführungs-Mechanismus von Oracle garantiert, dass alle Datenbank-Server, die an einer verteilten Transaktion teilnehmen, alle die Anweisungen in der Transaktion entweder ausführen oder wiederholen.
Zur Entkopplung der Haupt-Datenbank von den nachgeordneten Datenbanken ist eine Proxy-Datenbank auf der Seite des Dienstanbieters zwischen die Haupt-Datenbank und die nachgeordneten Datenbanken geschaltet. Aktualisierungen der Haupt-Datenbank werden in die Proxy-Datenbank(en) geladen. Die Proxy-Datenbank leitet die Aktualisierungen weiter an die nachgeordneten Datenbanken. Die Proxy-Datenbank enthält exakt dieselben Daten (gespiegelte Daten) wie sie die nachgeordneten Datenbanken nach der Aktualisierung enthalten sollen.
Die Synchronisation der drei Datenbanken Haupt-, Proxy- und nachgeordnete Datenbank ist jedoch schwierig. Andererseits ist die Unterhaltung mehrerer physikalischer Datenbanken bei Dienstanbietern kostspielig. Darüber hinaus ist es nicht möglich, eine konsistente Datensicherung mehrerer physikalischer Datenbanken durchzuführen.
Es ist eine Aufgabe der Erfindung, ein Verfahren zur Datenreplikation in einem verteilten Datenbank-System vorzuschlagen, das eine einfache Synchronisation erlaubt.
Dieses Ziel wird gemäß der Erfindung durch ein Verfahren gemäß den Lehren von Anspruch 1 und ein Haupt-Datenbank-System gemäß den Lehren von Anspruch 6 erreicht.
Die Grundidee der Erfindung ist, dass eine Haupt-Datenbank und eine Zwischen- oder Proxy-Datenbank, wobei die Proxy-Datenbank als Replikations-Datenbank für weitere, entfernte Datenbanken dient, als logisch unterschiedliche Datenbanken innerhalb einer physikalischen Datenbank konfiguriert werden, wobei die physikalische Datenbank dadurch gekennzeichnet ist, dass sie durch eine einzige Datenbank-Verwaltung gesteuert wird. Zur Aktualisierung der entfernten Datenbanken mit Datensätzen des Haupt-Datenbank-Systems, den Sätzen, die zur Proxy-Datenbank weitergeleitet werden, sind die Proxy-Datenbank und das entfernte Datenbank-System mit einem Synchronisations-Protokoll gekoppelt, wobei das Protokoll sicherstellt, dass die entfernte Datenbank in einem Minimum an Zeit zuverlässig aktualisiert wird. Da die Proxy-Datenbank und die Haupt-Datenbank als Teil einer physikalischen Datenbank realisiert sind, wird der Synchronisationsaufwand zwischen der Haupt-Datenbank und der Proxy-Datenbank minimiert. Insbesondere die Transaktions-Leistung wird durch die Tatsache erhöht, dass keine Zweiphasen-Durchführungen erforderlich sind. Stattdessen wird gemäß der Erfindung eine Objekt-Aktualisierung sowohl der Haupt-Datenbank als auch der Zwischen-Datenbank in einer einzigen Transaktion durchgeführt, in der ein einziger Durchführungs-Befehl sowohl in der Haupt-Datenbank, als auch in der Zwischen-Datenbank ausgeführt wird.
Weitere Verfeinerungen der Erfindung finden sich in den abhängigen Ansprüchen und der unten angegebenen Beschreibung.
Die Erfindung wird im Folgenden weiterhin mit Hilfe der begleitenden Zeichnungen erklärt:
1 zeigt ein verteiltes Datenbank-System mit einem Haupt-Datenbank-System und entfernten Datenbank-Systemen,
2 zeigt beispielhaft ein Blockdiagramm eines Haupt-Datenbank-Systems gemäß der Erfindung und ein beispielhaftes entferntes Datenbank-System, die miteinander kommunizieren,
3 zeigt beispielhaft ein detaillierteres Blockdiagramm des Haupt-Datenbank-Systems,
4 zeigt ein beispielhaftes Szenarium einer Datenbank-Aktualisierung und
5 zeigt eine Variation des Szenariums aus 4.
1 zeigt eine Gesamtansicht eines verteilten Datenbank-Systems mit einem Dienstanbieter-System oder Haupt-Datenbank-System SPS und beispielhaft drei entfernten oder nachgeordneten Datenbank-Systemen SAS1, SAS2 und SAS3. Die Datenbank-Systeme SPS enthalten eine Haupt-Datenbank MDB, und die entfernten Datenbank-Systeme SAS1, SAS2 und SAS3 enthalten jeweils eine nachgeordnete Datenbank SDB1, SDB2, bzw. SDB3 zur dauerhaften Datenspeicherung. Die Datenbank-Systeme sind mit einem Kommunikationsnetz TN verbunden, das vorzugsweise als Paket-Datennetz entsprechend dem Transmission Control Protocol/Internet Protocol (TCP/IP) realisiert ist.
Weiterhin enthalten die Datenbank-Systeme jeweils Schnittstellen-Einheiten zum Kommunikationsnetz, Agenten, Protokoll-Engines und Speicher für dynamische Daten, was in 1 nicht gezeigt wird. Die nachgeordneten Datenbanken SDB1, SDB2 und SDB3 müssen mit Daten geladen werden, die in der Haupt-Datenbank MDB gespeichert sind. Entsprechend dem bisherigen Stand der Technik wird zur Entkopplung der Haupt-Datenbank MDB von den nachgeordneten Datenbanken eine Proxy-Datenbank auf der Seite des Dienstanbieters, die hier nicht gezeigt wird, zwischen der Haupt-Datenbank MDB und den nachgeordneten Datenbanken SDB1, SDB2 und SDB3 geschaltet, wobei die Proxy-Datenbank physikalisch unabhängig von der Haupt-Datenbank MDB ist. Aktualisierungen der Haupt-Datenbank MDB werden in die Proxy-Datenbank geladen. Die Proxy-Datenbank führt dann die Weiterleitung der Aktualisierungen zu den nachgeordneten Datenbanken SDB1, SDB2 und SDB3 durch.
Nach dem bisherigen Stand der Technik sind alle Datenbanken, Haupt-Datenbank MDB, Proxy-Datenbank PDB und die nachgeordneten Datenbanken SDB1, SDB2, SDB3 physikalisch unabhängige Datenbanken. Physikalisch unabhängig bedeutet, dass die Datenbanken jeweils ihr eigenes Dateisystem mit jeweils eigener Verwaltung haben. Für eine Transaktion von Daten von der Haupt-Datenbank MDB zu einer nachgeordneten Datenbank SDB umfasst jede Transaktion eine erste Transaktion von der Haupt-Datenbank zur Proxy-Datenbank und eine zweite Transaktion von der Proxy-Datenbank zu den nachgeordneten Datenbanken. Um die Daten-Konsistenz sicherzustellen, ist eine Synchronisation dieser Transaktionen erforderlich. Darüber hinaus ist auch für die Datensicherung und die Wiederherstellung eine Synchronisation erforderlich.
Gemäß der Erfindung werden die Haupt-Datenbank MDB und die Proxy-Datenbank PDB als eine physikalische Datenbank realisiert. Daher zeigt 2 ein Blockdiagramm mit einem Kundenbetreuungs-System CCS, einem Haupt-Datenbank-System SPS gemäß der Erfindung und eine beispielhafte entfernte Datenbank SDB1. Das Haupt-Datenbank-System SPS enthält einen Haupt-Datenbank-Agenten DBA, wobei eine Haupt-Datenbank MDB beispielhaft aus drei logisch unterschiedlichen Datenbank-Teilen A-C besteht, einer Proxy-Datenbank PDB, einem Prüfungs-Überwacher AM und einem (ersten) Proxy-Datenbank-Agenten AG1. Das (erste) entfernte Datenbank-System SAS1 enthält eine (erste) nachgeordnete Datenbank SDB1, die beispielhaft aus drei Datenbank-Teilen A'-C' besteht. Die Doppelpfeile 1-7 zwischen diesen Einheiten stellen bidirektionale Kommunikations-Beziehungen dar.
Die Proxy-Datenbank dient zur Zwischenspeicherung von Daten, die in einer Eine-zu-Vielen-Replikation (im obigen Beispiel ist n=3) sofort zu den entfernten Datenbanken SDB1, SDB2 und SDB3 zu senden sind.
In der ersten Kommunikations-Beziehung werden Benutzer-Anforderungen, z.B. zur Eingabe neuer Daten, vom Kundenbetreuungs-System CCS zum Haupt-Datenbank-Agenten DBA gesendet. In der zweiten Kommunikations-Beziehung 2 werden Befehle für Datenbanken-Aktionen vom Haupt-Datenbank-Agenten DBA zur Haupt-Datenbank gesendet. In der dritten Kommunikations-Beziehung 3 werden Daten, die an das entfernte Datenbank-System SAS1 zu verteilen sind, zur Proxy-Datenbank gesendet. In der vierten, fünften und sechsten Kommunikations-Beziehung 4, 5, 6 wird die Verteilung der Daten von der Haupt-Datenbank MDB zur nachgeordneten Datenbank SDB1 gesteuert. Der Proxy-Datenbank-Agent AG1 liest/schreibt Daten aus der/in die Proxy-Datenbank PDB. Der Prüfungs-Überwacher AM dient zur Überwachung und zur Sicherstellung einer erfolgreichen Replikation. In der siebten Kommunikations-Beziehung 7 werden die Datenbank-Objekte von der Proxy-Datenbank PDB zur nachgeordneten Datenbank SDB1 übertragen.
Beispielhaft sind die Haupt-Datenbank MDB und die nachgeordnete Datenbank SDB1 jeweils in drei Abschnitte A, B und C, bzw. A', B' und C' unterteilt. Jeder dieser Abschnitte kann als logische Datenbank betrachtet werden. Zur Bereitstellung von Diensten in einem Telefonsystem können die folgenden Dienste zur Rufnummernmitnahme beispielhaft realisiert werden, wobei jedem dieser Dienste ein Datenbank-Abschnitt A, B, C, bzw. A', B' oder C' zugeordnet ist:
Festnetz-Rufnummernmitnahme (Fixed Number Portability, FNP) enthält die Teile geografische Rufnummernmitnahme und lokale Rufnummernmitnahme:
Die lokale Rufnummernmitnahme (LNP) ist die Fähigkeit eines Endanwenders des PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network, Öffentliches Fernsprechnetz/Diensteintegrierendes digitales Netzwerk), dieselbe internationale E.164-Rufnummer beizubehalten, wenn er von einem zum anderen Dienstanbieter wechselt, ohne seinen Standort zu ändern.
Die geografische Rufnummernmitnahme (GNP) ist die Fähigkeit eines Endanwenders, dieselbe internationale E.164-Rufnummer beizubehalten, wenn er von einem Standort zu einem anderen wechselt, ohne den Dienstanbieter zu wechseln.
Die Mobilfunk-Rufnummernmitnahme (Mobile Number Portability, MNP) ist die Fähigkeit eines Endanwenders, dieselbe internationale E.164-Mobilfunk-Rufnummer beizubehalten, wenn er von einem Dienstanbieter zu einem anderen wechselt.
Für diese Dienste kann jeweils eine andere Datenbank auf der Seite des Dienstanbieters und auf der entfernten Seite benutzt werden. Vorzugsweise bildet jede dieser Datenbanken auf jeder Seite logisch unabhängige Datenbanken A, B, C, bzw. A', B', C' auf einem einzigen physikalischen Datenbank-System SPS, bzw. SAS.
Das Haupt-Datenbank-System SPS hat typischerweise die folgenden Charakteristiken:

• Fähigkeit, bis zu 100 Millionen Einträge (pro Anwendung) für bis zu 10 Aktualisierungen pro Sekunde zu behandeln,
• Die maximale Verzögerungszeit pro Einzel-Anforderung darf in einem Netzwerk von 20 SAS-Servern 60s betragen,
• Für eine Batch-Anforderung (1000 Einzeloperationen) 180s, und
• Es muss garantiert werden, dass keine Aktualisierungs-Anforderungen verloren gehen.

Die Haupt-Datenbank MDB kann beispielhaft auf einem kombinierten Netzwerkelement-(NE)-Management/Dienst-Management-Server (CMC/SPS) mit der folgenden Hardware und dem Betriebssystem von der Firma Hewlett Packard und der Datenbank von der Firma Versant realisiert werden:

Hardware: HP A400 oder HP A500

Software: Betriebssystem: HP-UX 11 Datenbank: VDS (Versant Development Suite) 6.0.1.
Das entfernte Datenbank-System SAS ist vorzugsweise ein verteiltes System hoher Verfügbarkeit mit den folgenden beispielhaften Charakteristiken:

• 950 NP Lese-Transaktionen pro Sekunde,
• Maximale Reaktionszeit 30 ms,
• 20 NP Daten-Modifikationen pro Sekunde (ohne die oben angegebenen 950 NP Echtzeit-Transaktionen pro Sekunde einzuschränken),
• SAS muss in einer N+1 – Konfiguration arbeiten, und
• Nicht mehr als 3 Minuten pro Jahr außer Betrieb.

Für einen Satz definierter Funktionen (z.B. Replikation) verhält sich die Proxy-Datenbank wie eine logisch von der Haupt-Datenbank unabhängige Datenbank.
Die in der physikalischen Datenbank gespeicherten Datensätze enthalten daher jeweils eine Datenbank-Kennung zur Kennzeichnung, zu welcher der logisch unabhängigen Datenbanken jeder Datensatz gehört.
Das Konzept unabhängiger logischer Datenbanken auf einer physikalischen Datenbank bietet die Möglichkeit, unterschiedliche Datenbanken in einer Transaktion zu behandeln. Es ist keine Transaktions-Synchronisation über verschiedene Datenbanken erforderlich.
Mit diesem Verfahren werden in den Proxy-Datenbanken auf SPS-Seite Replikations-Warteschlangen mit Einträgen von logischen Objekt-IDs der geänderten Objekte verwaltet. Ein so genannter Prozess ReplicationSlaveSiteDriver, der auf der SAS-Seite läuft, liest die Einträge dieser Replikations-Warteschlange, übernimmt sie in eine Replikations-Warteschlange auf der SAS-Seite und kopiert die geänderten Objekte in die entsprechende nachgeordnete Datenbank. Ein Cache-Aktualisierer, der auf jedem SAS läuft, liest schließlich die Replikations-Warteschlange auf SAS-Seite und kopiert die Änderungen in einen Client-Cache eines entsprechenden Anwendungs-Prozesses, wodurch die Änderungen wirksam werden.
Wenn die ReplicationSlaveSiteDrivers aller entfernten SAS-Systeme einen Eintrag der Replikations-Warteschlange auf der SPS-Seite übernommen haben, wird dieser Eintrag dort gelöscht. Entsprechend wird ein Eintrag auf SAS-Seite gelöscht, wenn die entsprechenden Daten in den Client-Cache eines Anwendungs-Prozesses übertragen wurden.
Aus Gründen der Flexibilität ist es auch möglich, dass zwei oder mehr SAS-Systeme eine nachgeordnete Datenbank, die auf einem der SAS-Systeme installiert ist, gemeinsam nutzen. Dann wird nur ein ReplicationSlaveSiteDriver bereitgestellt, aber für jedes SAS-System wird ein Cache-Aktualisierer bereitgestellt, der die Daten im Client-Cache des entsprechenden SAS-Systems aktualisiert. Die Einträge der Replikaktions-Warteschlange in der nachgeordneten Datenbank werden gelöscht, wenn die Cache-Aktualisierer aller SAS-Systeme die Daten übernommen haben.
Für die Datensicherung, die Wiederherstellung und die Roll-Forward-Archive in der physikalischen Datenbank ist keine Synchronisation erforderlich. Weiterhin ist eine schnelle Daten-Neuspeicherung der Proxy-Datenbank, z.B. nach Auftreten eines Fehlers, die Benutzung von Roll-Forward-Archiven und z.B. die Benutzung von Versant Habackup möglich. Somit erlaubt die Erfindung eine einfache Datenbank-Verwaltung auf der Seite des Dienstanbieters.
3 zeigt beispielhaft ein detaillierteres Blockdiagramm des Haupt-Datenbank-Systems SPS der vorherigen Figuren. Über eine grafische Benutzer-API (Application Programming Interface, Anwendungs-Programmierungs-Schnittstelle) GA ist das Haupt-Datenbank-System SPS mit einer grafischen Benutzerschnittstelle GUI verbunden. Über eine Kundenbetreuungs-API CA ist das Haupt-Datenbank-System SPS mit dem Kundenbetreuungs-System CCS verbunden. Über eine Alarm- Schnittstelle AL, eine Datensicherungs-Schnittstelle BU, eine Netzwerkelement-Verwaltungs-Schnittstelle NA und eine Protokollierungs-Schnittstelle LG ist das Haupt-Datenbank-System SPS mit einem Verwaltungs-System CMC verbunden. Das Haupt-Datenbank-System SPS enthält einen Befehls-Interpreter CI, der mit der Kundenbetreuungs-API CA verbunden ist. Weiterhin ist dieser Befehls-Interpreter mit einer Haupt-Datenbank DBA verbunden, die über einen Prüfungs-Überwacher AM mit jedem der beispielhaften Proxy-Datenbank-Agenten AG1-AG3 verbunden ist, und mit der Haupt-Datenbank MDB, die beispielhaft aus drei Unter-Datenbanken MDB1-MDB3 besteht, über einen Datenbank-Adapter ADP mit einer Proxy-Datenbank PDB, und mit der grafischen Benutzer-API GA verbunden ist. Die Proxy-Datenbank PDB ist mit den drei Proxy-Datenbank-Agenten AG1-AG3 verbunden. Diese Agenten sind jeweils einem entfernten Datenbank-System SAS1, SAS2 und SAS3 zugeordnet, sowie die Proxy-Datenbank PDB jeder dieser entfernten Datenbanken zugeordnet ist.
Die Bezeichnung Verbindung bedeutet eine Kommunikations-Beziehung auf logischer Basis. Die Verbindungen haben hauptsächlich eine Haupt-Kommunikationsrichtung, die Verbindungen sind bidirektional, da normalerweise eine Rückkopplung (Quittung oder OK) zurückgesendet wird. Im Folgenden werden die Haupt-Einheiten detaillierter beschrieben:
Befehls-Interpreter CI:
Diese Einheit empfängt Befehle vom Kundenbetreuungs-System CCS, verteilt diese Befehle an die verschiedenen Haupt-Datenbanken und verwaltet die Rückgabe-Daten, die zurück an das Kundenbetreuungs-System CCS zu senden sind.
Haupt-Datenbank MDB:

– Diese Einheit führt die dauerhafte Speicherung der kompletten Dienst-Daten durch.

Diese Daten werden unterhalten, um sie zu den entfernten nachgeordneten Datenbanken SDB1, SDB2, SDB3 zu übertragen. Weiterhin enthält diese Datenbank Zeitsteuerungs-Bedingungen für die Übertragung der Daten (z.B. Aktivierungs-Zeitpunkte) und erzeugt Scheduling-Anforderungen, die an den Datenbank-Scheduler DBS zu senden sind.
Haupt-Datenbank-Agent DBA:
Diese Einheit liest und schreibt Daten von/zur Haupt-Datenbank MDB. Sie enthält die komplette Anwendungs- und Daten-Manipulations-Logik, führt syntaktische Prüfungen und die Wartung der entsprechenden Strukturen für die Objekt-Navigation durch. Zusätzlich dazu können Semantik- und Konsistenz-Prüfungen durchgeführt werden.
Datenbank-Scheduler DBS:
Diese Einheit erlaubt die Zeitsteuerung von Datenübertragungen. Daten, die mit einer Zeiterzögerung zu den Proxy-Datenbanken übertragen werden müssen, werden von dieser Einheit behandelt.
SAS-Proxy-DB-Agenten AG1, AG2, AG3:
Diese Agenten lesen und schreiben Daten von/zur Proxy DB. Die Aufgaben dieser Agenten umfassen die Wartung der Datenbank-Struktur. Sie führen auch eine Objekt-Navigation aus. Die Datenbank-Agenten unterhalten jeweils einen Zeiger auf eine Daten-Warteschlange der Proxy-Datenbank PDB. Diese Zeiger markieren das Datenelement in der Warteschlange, bis zu dem die Elemente bereits zuvor erfolgreich in die entsprechende entfernte Datenbank SDB1, SDB2, SDB3 geladen wurden.
(SAS) Proxy-Datenbank PDB:
Diese Datenbank dient als Zwischenspeicher für Daten, die jeweils in einer Eine-zu-Vielen-Replikation sofort zu den entfernten Datenbanken SDB1, SDB2 und SDB3 zu laden oder zu senden sind. Die zu sendenden Datenelemente werden in eine Warteschlange gestellt.
SAS DB Adapter ADP:
Diese Einheit wandelt Daten von einer Haupt-Datenbank MDB für die Proxy-Datenbank PDB. Sie verbirgt die Details der Abbildung zwischen beiden Datenmodellen (Haupt-DB-Datenmodell ist für die Bereitstellung optimiert, SAS-Proxy für den schnellen Zugriff von Dienst-Steuerungen).
Prüfungs-Überwacher AM:
Diese Einheit führt einen regelmäßigen Vergleich des Zustandes der Haupt-Datenbank MDB, der SAS-Proxy-Datenbank PDB und der entfernten Datenbanken durch, um die erfolgreiche Replikation zu prüfen. Auf Anforderung sendet der Prüfungs-Überwacher Ergebnisse zurück zu einem Datenverwalter.
Die Verwaltungs-Einheit CMC führt Verwaltungsaufgaben auf dem SPS durch, z.B. die Alarm-Verarbeitung, Datensicherung, Netzwerkelement-Verwaltung und Protokollierung.
4 zeigt ein beispielhaftes Szenarium der Aktualisierung einer entfernten Datenbank für eine sofort ausgeführte Aktualisierungs-Anforderung. Dazu werden die Befehle M1 – M20 zwischen den in 3 erklärten Einheiten wie folgt ausgetauscht:
Ein erster Befehl M1 mit einer Anforderung wird vom Kundenbetreuungs-System CCS zum Befehls-Verteiler oder Interpreter CI gesendet. Der Befehls-Interpreter stellt diesen Befehl in eine Warteschlange und sendet einen zweiten Befehl M2 als Quittung zurück. Nachdem der Befehl in die Warteschlange gestellt wurde, sendet der Befehls-Interpreter CI einen dritten Befehl M3 mit einer Anforderung zum Haupt-(Datenbank)-Agenten DBA, der einen vierten Befehl M4 als Quittung zurückliefert. Der Haupt-Agent DBA löst mit einem fünften Befehl M5 zur Haupt-Datenbank MDB die Aktualisierung der entsprechenden Objekte aus. Mit einem sechsten Befehl M6 sendet der Haupt-Agent DBA eine Objekt-Synchronisations-Anforderung zum (SAS-Datenbank-) Adapter ADP. Der Adapter ADP liest die entsprechenden Objekte aus der Haupt-Datenbank MDB, was als siebter Befehl M7 symbolisiert wird, und sendet einen achten Befehl M8 mit einer Aktualisierungs-Anforderung an zum Beispiel den (ersten) Proxy-(Datenbank)-Agenten AG1. Der Proxy-Agent AG1 löst mit einem neunten Befehl M9 zur Proxy-Datenbank PDB die Aktualisierung der entsprechenden Objekte aus und mit einem zehnten Befehl M10 zur Proxy-Datenbank PDB sendet er einen Befehl zur Erzeugung einer Übertragungs-Anforderung. Er sendet einen elften Befehl M11 mit einem OK zurück zum Adapter ADP, der dieses OK als zwölften Befehl M12 zum Haupt-Agenten DBA weiterleitet. Der Haupt-Agent DBA sendet den dreizehnten Befehl M13 mit einem Befehl zur Durchführung der Änderungen sowohl an die Haupt-Datenbank MDB als an die Proxy-Datenbank PDB. Somit wird ein einziger Durchführungs-Befehl für beide Datenbanken MDB und PDB ausgeführt.
Der Durchführungs-Befehl beendet die Aktualisierungs-Transaktion zwischen den Datenbanken. Eine Transaktion besteht im Allgemeinen aus einem Satz von logisch abhängigen einzelnen Aktionen. Mit einer Transaktion wird eine Datenbank von einem logisch folgerichtigen Zustand in einen anderen logisch folgerichtigen Zustand versetzt. Sobald sie Änderungen einer Transaktion freigegeben sind, stehen sie in der Datenbank dauerhaft zur Verfügung.
Danach sendet der Haupt-Agent einen vierzehnten Befehl M14 als Antwort zum Befehls-Interpreter CI, der diesen Befehl in eine Warteschlange stellt, bevor er einen fünfzehnten Befehl M15 als Antwort zum Kundenbetreuungs-System CCS sendet. Unabhängig davon stellt die Proxy-Datenbank PDB die Übertragungs-Anforderungen M10 für jede entfernte Datenbank SDB1, SDB2, SDB3 in eine Warteschlange. Hier wird nur eine Aktualisierung einer einzigen entfernten Datenbank SDB1 betrachtet: Ein Transfer-Prozessor TP liest die (in die Warteschlange gestellte(n)) Transfer-Anforderung(en), was als sechzehnter Befehl M16 symbolisiert wird, liest die Änderungen, was als siebzehnter Befehl M17 symbolisiert wird, und sendet die Änderungen mit einem achtzehnten Befehl M18 an die entfernte Datenbank SDB1. Weiterhin sendet der Transfer-Prozessor TP einen neunzehnten Befehl M19 mit einer Aktualisierungs-Transfer-Aufforderung an die Proxy-Datenbank PDB und sendet den zwanzigsten Befehl M20 mit einem Durchführungs-Befehl sowohl an die Proxy-Datenbank, als auch die entfernte Datenbank SDB1.
5 zeigt eine Variation des Szenariums aus 4 mit einer planmäßigen Aktualisierungs-Anforderung. Daher wird zwischen der Haupt-Datenbank MDB und dem Adapter ADP ein Scheduler DBS (logisch) eingeführt. Anstelle des sechsten Befehls M6 aus 3 werden fünf Befehle M61 – M65 wie folgt ausgeführt:
Ein erster geänderter Befehl M61 mit einer Liste von zu beobachtenden Objekten wird vom Haupt-Agenten DBA zum Scheduler DBS gesendet, der einen zweiten geänderten Befehl M62 als OK zurücksendet. Der Haupt-Agent sendet einen dritten geänderten Befehl M63 mit einem Ausführungs-Befehl zur Haupt-Datenbank MDB. Der Scheduler nimmt die Objekte in eine Planungs-Liste SL auf. Zu einem vorher festgelegten Zeitpunkt (die vordefinierten Zeitpunkte sind z.B. periodisch festgelegt) sendet der Scheduler DBS einen vierten geänderten Befehl M64 zur Haupt-Datenbank MDB und löst damit die Aktualisierung der entsprechenden Objekte aus. Mit einem fünften geänderten Befehl M65 sendet der Haupt-Agent DBA eine Objekt-Synchronisations-Anforderung zum Adapter ADP. Nachdem die unter 3 beschriebene Aktualisierungs-Transaktion beendet ist, sendet, statt dass der Haupt-Agent DBA den Durchführungs-Befehl M13 sendet, der Scheduler DBS den Durchführungs-Befehl M13' sowohl zur Haupt-Datenbank MDB als auch zur Proxy-Datenbank PDB. Die weiteren Aktionen zur Aktualisierung der entfernten Datenbank bleiben unverändert, wie in 3 beschrieben.
Delta-Replikation:
In vorhandenen Replikations-Verfahren zur Aktualisierung objektorientierter Datenbanken werden komplette Objekte von einer Haupt-Datenbank zu einer oder mehreren nachgeordneten Datenbanken (SDB) verteilt. Das bedeutet, dass die Replikation ein Objekt sendet, wenn mindestens ein Objekt-Attribut auf der Seite der Haupt-Datenbank geändert wurde. Es kommt zu Leistungsfähigkeits-Problemen, wenn viele große Objekte in kurzer Zeit geändert wurden. Obwohl oft nur ein oder wenige Attribute geändert werden, wird jedes Objekt komplett an alle nachgeordneten Datenbanken (SDB) gesendet.
Gemäß einem weiteren Aspekt der Erfindung wird ein so genanntes Nachrichten-Konzept implementiert. Ein Nachrichten-Objekt enthält die geänderten Attribute eines Datenbank-Objektes.
Dieses Nachrichten-Objekt wird in die Replikations-Warteschlange übertragen, wobei das entfernte Datenbank-System die Einträge in der Replikations-Warteschlange liest, sie in eine weitere Replikations-Warteschlange auf der entfernten Seite übernimmt und die Attribut-Werte auf das entsprechende gespiegelte Datenbank-Objekt abbildet.
Delta-Replikation ist ein Nachrichten-Konzept, das den Vorteil bietet, nur geänderte Attribute eines zu aktualisierenden Datenbank-Objektes zu senden. Dieses Konzept verringert somit die Datenverkehrs-Last.

Claims

Verfahren zur Aktualisierung einer entfernten Datenbank (SDB) mit Datensätzen einer Haupt-Datenbank (MDB), wobei die Datensätze an eine Zwischen-Datenbank (PDB) weitergeleitet und in der Zwischen-Datenbank (PDB) gespeichert werden, wobei die Zwischen-Datenbank (PDB) und die entfernte Datenbank (SDB) mittels eines Synchronisations-Protokolls gekoppelt sind, wobei das Protokoll sicherstellt, dass die entfernte Datenbank (SDB) zuverlässig von der Zwischen-Datenbank (PDB) aktualisiert wird, dadurch gekennzeichnet, dass die Haupt-Datenbank (MDB) und die Zwischen-Datenbank (PDB) als logisch unterschiedliche Datenbanken in einer physikalischen Datenbank innerhalb eines einzigen Haupt-Datenbank-Systems (SPS) konfiguriert sind, das durch eine einzige Datenbank-Verwaltung gesteuert wird, wobei eine Objekt-Aktualisierung sowohl der Haupt-Datenbank (MDB), als auch der Zwischen-Datenbank (PDB) innerhalb einer einzigen Transaktion ausgeführt wird, in der ein einziger Durchführungs-Befehl sowohl auf der Haupt-Datenbank (MDB), als auch auf der Zwischen-Datenbank (PDB) ausgeführt wird.
Verfahren gemäß Anspruch 1, worin die einzige Datenbank-Verwaltung gleichzeitig eine Datensicherung, Daten-Wiederherstellung und Roll-Forward-Archive sowohl der Haupt-Datenbank (MDB), als auch der Proxy-Datenbank (PDB) umfasst.
Verfahren gemäß Anspruch 1, worin ein Datenbank-Adapter (ADP) Daten von der Haupt-Datenbank (MDB) in die Proxy-Datenbank (PDB) wandelt, wobei er Details der Abbildung zwischen beiden entsprechenden Datenmodellen verbirgt.
Verfahren gemäß Anspruch 1, worin ein Datenbank-Scheduler (DBS) empfangene Aktualisierungs-Anforderungen ausführt, indem er zu vordefinierten Zeitpunkten eine Übertragung von Daten von der Haupt-Datenbank (MDB) zur Proxy-Datenbank (PDB) auslöst.
Verfahren gemäß Anspruch 1, worin Nachrichten-Objekte erzeugt werden, die Informationen über geänderte Attribute von Datenbank-Objekten enthalten, wobei diese Nachrichten-Objekte in eine Replikations-Warteschlange übertragen werden, wobei das entfernte Datenbank-System (SAS1, SAS2, SAS3) die Einträge dieser Replikations-Warteschlange liest, sie in eine weitere Replikations-Warteschlange auf der entfernten Seite übernimmt und die Attribut-Werte auf die entsprechenden gespiegelten Datenbank-Objekte abbildet.
Haupt-Datenbank-System (SPS), das Sende-Mittel zur Übertragung von Datensätzen in eine Zwischen-Datenbank (PDB) enthält, wo die Datensätze gespeichert werden, wobei die Zwischen-Datenbank (PDB) und ein entferntes Datenbank-System (SAS) Protokoll-Mittel zur Ausführung eines Synchronisations-Protokolls enthalten, wobei das Protokoll sicherstellt, dass die entfernte Datenbank (SDB) von der Zwischen-Datenbank (PDB) zuverlässig aktualisiert wird, dadurch gekennzeichnet, dass eine Haupt-Datenbank (MDB) und die Zwischen-Datenbank (PDB) als logisch unterschiedliche Datenbanken in einer physikalischen Datenbank innerhalb des Haupt-Datenbank-Systems (SPS) konfiguriert sind, das durch eine einzige Datenbank-Verwaltung gesteuert wird, wobei das Haupt-Datenbank-System (SPS) Mittel enthält, um eine Objekt-Aktualisierung sowohl der Haupt-Datenbank (MDB), als auch der Zwischen-Datenbank (PDB) innerhalb einer einzigen Transaktion auszuführen, in der ein einziger Durchführungs-Befehl sowohl auf der Haupt-Datenbank (MDB), als auch auf der Zwischen-Datenbank (PDB) ausgeführt wird.