DE112014001873T5 - Replikation für Hot-Standby-Online-Datenbank - Google Patents

Replikation für Hot-Standby-Online-Datenbank Download PDF

Info

Publication number
DE112014001873T5
DE112014001873T5 DE112014001873.2T DE112014001873T DE112014001873T5 DE 112014001873 T5 DE112014001873 T5 DE 112014001873T5 DE 112014001873 T DE112014001873 T DE 112014001873T DE 112014001873 T5 DE112014001873 T5 DE 112014001873T5
Authority
DE
Germany
Prior art keywords
database
backup node
node
page
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112014001873.2T
Other languages
English (en)
Inventor
Jan Lindstrom
Kyosti Laiho
Vilho Tapani Raatikka
Jarmo Parkkinen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112014001873T5 publication Critical patent/DE112014001873T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275Synchronous replication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273Asynchronous replication or reconciliation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1471Saving, restoring, recovering or retrying involving logging of persistent data for recovery

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Retry When Errors Occur (AREA)

Abstract

Diese Erfindung betrifft ein System, ein Verfahren und ein Computerprogrammprodukt, um ein Datenbankabbild von einem funktionsfähigen Primärknoten in einen Sicherungsknoten in einer verteilten Datenbankumgebung zu replizieren, wobei das Verfahren aufweist: Angeben eines Prüfpunktabbilds des Primärknotens einschließlich einer Datenbankstruktur und einer Vielzahl von Datenbankseiten; Anlegen einer Replikatsdatenbank auf einem Sicherungsknoten, indem ein Sicherungsknoten initialisiert und die angegebene Struktur auf dem initialisierten Sicherungsknoten gespeichert wird; Senden einer jeden Datenbankseite des Prüfpunktabbilds an den Sicherungsknoten zum Speichern; nachdem die Erstellung eines Prüfpunktabbilds gestartet wurde, Speichern einer jeden Transaktion auf dem Primärknoten und Erzeugen einer entsprechenden REDO-Transaktion, um sie an den Sicherungsknoten zu senden; Kennzeichnen einer jeden Datenseite, an der eine jede REDO-Transaktion Operationen durchführt; parallel zum Senden der Datenbankseiten, Senden einer jeden erzeugten REDO-Transaktion in der Reihenfolge an den Sicherungsknoten, in der die entsprechende Transaktion stattfand, so dass der Sicherungsknoten die Transaktionen in der richtigen Reihenfolge replizieren kann; und Priorisieren einer jeden gekennzeichneten Datenbankseite, so dass sie vor oder weitgehend zur selben Zeit wie eine entsprechende REDO-Transaktion an dem Sicherungsknoten ankommt, wobei die entsprechende REDO-Transaktion Operationen an der gekennzeichneten Datenbankseite durchführt, ohne darauf warten zu müssen, bis jede Datenbankseite auf dem Sicherungsknoten gespeichert wird.

Description

  • BEREICH DER ERFINDUNG
  • Diese Erfindung betrifft ein Verfahren und eine Vorrichtung für einen Replikator für eine Hot-Standby-Online-Datenbank.
  • HINTERGRUND
  • In einer Hot-Standby-(HSB-)Datenbank wird eine Transaktion in zwei Phasen festgeschrieben, wobei sowohl ein Primärknoten als auch ein Sicherungsknoten Änderungen erfolgreich bestätigen müssen, bevor die Transaktion als ordnungsgemäß festgeschrieben betrachtet wird. Es handelt sich dabei um ein Protokoll für die zweiphasige Festschreibung (2PC), das sicherstellt, dass eine Datenbank in beiden Knoten immer denselben Zustand aufweist. 2PC ist ein atomares Festschreibungsprotokoll (atomic commitment protocol (ACP)) und ein spezieller Typ eines Konsensprotokolls, das dazu dient, alle an einer verteilten atomaren Transaktion beteiligten Prozesse hinsichtlich der Rage zu koordinieren, ob eine Transaktion festgeschrieben oder abgebrochen (rückgängig gemacht) werden soll. Einige HSB-Datenbanken bieten dem Benutzer die Möglichkeit, zugunsten von Leistungsfähigkeit auf Konsistenz zu verzichten, indem sie relaxiertere Transaktionen ermöglichen. Eine solche Transaktion ist in einem Two-Safe-Received-(2SR-)Protokoll definiert, bei der der Primärknoten eine Festschreibung durchführt, sobald ein Sicherungsknoten bestätigt, dass er alle Protokollsätze der festschreibenden Transaktion erhalten hat.
  • Ein Primärknoten wird zuweilen auch als Hauptknoten bezeichnet und ein Sicherungsknoten wird manchmal als ein Sekundärknoten, Bereitschaftsknoten oder untergeordneter Knoten bezeichnet. Üblicherweise akzeptiert ein Primärknoten alle Transaktionen, während ein Sicherungsknoten lediglich Nur-Lese-Transaktionen akzeptiert.
  • Es gibt verschiedene Möglichkeiten, einen Sicherungsknoten im Gleichlauf mit einem Primärknoten zu halten, doch wird in dieser Veröffentlichung die Protokollreplikation (die auch als Replikation mittels Protokollversand bezeichnet wird) betrachtet. Bei der Protokollreplikation speichert ein Primärknoten jede Schreibtransaktion in seiner Datenbank und in einem Protokollsatz, wobei die Protokollsätze des Weiteren in einen Sicherungsknoten kopiert werden. Wenn ein Sicherungsknoten Protokollsätze empfängt, führt er für jeden empfangenen Protokollsatz eine Wiederholungstransaktion (REDO-Transaktion) durch. Eine REDO-Transaktion wiederholt die referenzierte Transaktion.
  • In den Ausführungsformen wird eine HSB-Datenbank im Interesse eines schnellen Datenzugriffs im Hauptspeicher gespeichert, da der Hauptspeicher im Gegensatz zu einem indirekten Zugriff und einer langsameren Zugriffsgeschwindigkeit des persistenten Speichers von einer Computerverarbeitungseinheit (CPU) direkt adressiert wird. Ein schneller Zugriff auf den Hauptspeicher ist keine Eigenschaft speziell von HSB-Datenbanken, sie trifft aber auf speicherinterne Datenbanken zu, die Hot-Standby-Funktionalität (Funktionalität im aktiven Bereitschaftsmodus) unterstützen können. Protokollsätze werden üblicherweise im persistenten Speicher abgelegt. Eine speicherinterne Datenbank gewährleistet persistente Änderungen an Daten, indem Prüfpunktabbilder (die auch als Momentaufnahmen bezeichnet werden) der Datenbank in regelmäßigen Abständen (oder auf Anforderung) in den persistenten Speicher geschrieben werden. Das Schreiben von Prüfpunktabbildern ist ein Prüfpunktprozess. In einem Prüfpunktabbild werden Daten zu Datenbankseiten zusammengefasst, bei denen es sich um fortlaufende Datenbereiche im Massenspeicher handelt und die üblicherweise gleich groß wie einzelne oder mehrere logische Speicherblöcke sind. Der Einfachheit halber wird davon ausgegangen, dass eine Datenbankseite die gleiche Größe wie ein Plattenblock hat.
  • Eine speicherinterne Datenbank verwaltet ihre aktiven Daten im flüchtigen Hauptspeicher. Es ist üblich, dass eine speicherinterne Datenbank einen integrierten Manager für den Hauptspeicher enthält, der große Teile des Hauptspeichers vom Betriebssystem aus zuordnet, und diesen dann zur Verwendung einer speicherinternen Datenbank auf die geeignetste Art und Weise organisiert. Es wird davon ausgegangen, dass die Daten in unterschiedlich großen Hauptspeichersegmenten gespeichert werden, dass aber jedes Hauptspeichersegment Informationen enthält, die es ermöglichen, die Daten zu Hauptspeicherseitengrößen zusammenzufassen, um ein Prüfpunktabbild zu erstellen. Alternativ könnte die Datenbank in Hauptspeicherseitengrößen im Hauptspeicher gegliedert werden.
  • In einer HSB-Datenbank gibt es einen Primärknoten und üblicherweise einen Sicherungsknoten, doch verfügen manche Varianten über mehrere Sicherungsknoten. In komplexeren Systemen besteht die Möglichkeit, eine Datenbank auf Partitionen (oder ”Shards”) duplizieren zu lassen, wobei eine Partition als Hauptpartition und andere Partitionen als Sicherungspartitionen betrachtet werden. Die Ausführungsformen gelten auch für dieses partitionierte Modell. Bei einem Knoten kann es sich um eine physisch getrennte Computereinheit, eine Karte in einem Kartenträger oder um einen Prozess in einer virtuellen Maschine in dem einzelnen Host-Computer handeln. Von Zeit zu Zeit kann es vorkommen, dass eine HSB-Datenbank oder ein Computerknoten, auf dem eine HSB-Datenbank ausgeführt wird, abstürzt. Ein solcher Absturz zieht das Prüfpunktabbild von einem der Knoten so in Mitleidenschaft, dass die Datenbank, die auf dem in Mitleidenschaft gezogenen Knoten gespeichert ist, nicht mehr wiederhergestellt werden kann. Wenn ein anderer Knoten während eines Absturzes funktionsfähig bleibt, kann er die Rolle des Primärknotens übernehmen (sofern er nicht bereits der Primärknoten war) und mit der Ausführung von Transaktionen fortfahren.
  • Einige Zeit nach dem Ausfall eines Primärknotens wird ein anderer Knoten als Sicherungsknoten initialisiert. Bei dem initialisierten Knoten kann es sich um den ausgefallenen (und wiederhergestellten) Knoten oder um einen Ersatzknoten handeln, der in der Lage ist, die Funktion eines Sicherungsknotens in einer HSB-Datenbank zu übernehmen. Wenn der Primärknoten ausgefallen ist, gibt es keine Möglichkeit, einen Sicherungsknoten anhand eines nicht vorhandenen Prüfpunktabbilds zu initialisieren. Eine Kopie der Datenbank ist nur möglich, wenn der Primärknoten betriebsbereit ist. Wenn die Datenbank nicht auf der Platte des initialisierten Sicherungsknotens gespeichert ist, kann er in REDO-Transaktionen gespeicherte Transaktionen weder wiederherstellen noch verarbeiten. Deshalb muss für den initialisierten Sicherungsknoten eine Kopie der Daten bereitgestellt werden, gefolgt von Protokollsätzen, die alle Änderungen enthalten, welche in der Datenbank auf dem Primärknoten nach dem Zeitpunkt, zu dem das Prüfpunktabbild erstellt worden ist, vorgenommen wurden.
  • Wenn ein Sicherungsknoten nach einem Ausfall neu gestartet wurde, kann es sein, dass sein Prüfpunktabbild beschädigt ist oder dass er über gar kein Prüfpunktabbild verfügt. Folglich muss ein vollständiges Prüfpunktabbild von dem Primärknoten in den Sicherungsknoten kopiert werden, ohne den Primärknoten vom Netz zu nehmen. Der Sicherungsknoten benötigt: Metadaten; Systemtabellen; das neueste Prüfpunktabbild; und REDO-Transaktionen von Schreibtransaktionen, die von einem Punkt, an dem die Erstellung des Prüfpunktabbilds eingeleitet wurde, bis zu einem Punkt, an dem die primäre Datenbank und die Sicherungsdatenbank konsistent sind, ausgeführt wurden.
  • Das Synchronisieren einer Datenbank auf einem Sicherungsknoten mit Daten von einem Primärknoten weist zwei Phasen auf: eine Kopierphase und eine Abgleichsphase. Die Kopierphase weist das Kopieren der auf dem Primärknoten befindlichen Datenbank in den Sicherungsknoten auf. Die Abgleichsphase weist das auf dem Sicherungsknoten erfolgende Anlegen von Protokollsätzen über Transaktionen auf, die bereits ausgeführt und im Primärknoten festgeschrieben worden sind. Wenn einer der Knoten ausgefallen ist oder gerade wiederhergestellt wird, befindet sich das System in einer gefährdeten Phase, da die Ausfalltoleranz der HSB-Datenbank aufgrund des Ausfalls abgenommen hat.
  • Bekannte Lösungen für eine HSB-Synchronisierung erstellen vollständige Kopien von einem oder mehreren Prüfpunktabbildern einschließlich iterativen Versionen der Prüfpunktabbilder, gefolgt von den Protokollsätzen, die von den zuletzt durchgeführten Transaktionen erzeugt wurden.
  • Ein bekannter HSB-Synchronisierungsprozess kann zum Beispiel in einen primären Synchronisierungsprozess in dem Primärknoten aufgeteilt werden: Senden eines Prüfpunktabbilds (einschließlich Metadaten und tatsächlicher Daten) von dem Primärknoten an den Sicherungsknoten; Senden von REDO-Transaktionen, die während der Erstellung des Prüfpunktabbilds aktiv waren; und Senden von REDO-Transaktionen, die während der Synchronisierung in dem Primärknoten ausgeführt wurden. Der entsprechende Sicherungssynchronisierungsprozess kann in die entsprechenden Schritte aufgeteilt werden: Empfangen eines Prüfpunktabbilds (einschließlich Metadaten und tatsächlicher Daten); Empfangen von REDO-Transaktionen, die während der Erstellung des Prüfpunktabbilds aktiv waren; und Empfangen von REDO-Transaktionen, die während der Synchronisierung in einem Primärknoten ausgeführt wurden.
  • Eine speicherinterne Datenbank, die auf handelsüblicher Hardware ausgeführt wird, kann Hunderttausende von einzelnen Schreibtransaktionen pro Sekunde ausführen. Unter normalen Umständen können Nur-Lese-Transaktionen sowohl in einem Primärknoten als auch in einem Sicherungsknoten ausgeführt werden, wodurch eine teilweise Lastverteilung weg vom Primärknoten stattfindet. Wenn andere Knoten ausfallen, muss der verbleibende Knoten gegebenenfalls die Rolle des Primärknotens übernehmen (sofern er nicht bereits der Primärknoten war). Der Primärknoten wird sofort für alle Schreib- und Nur-Lese-Transaktionen zuständig, was die Zahl seiner aktiven Client-Verbindungen in der Praxis möglicherweise verdoppelt. Folglich erhöht sich der Speicherbedarf des Primärknotens erheblich und in Abhängigkeit von den Auslastungs- und Implementierungsdetails kann sich die Leistungsfähigkeit aufgrund der höheren Anzahl von gleichzeitig ausgeführten Transaktionen verringern.
  • Wenn mit der Wiederherstellung des Sicherungsknotens begonnen wird, ist der Primärknoten für die Erstellung eines frischen Prüfpunktabbilds des aktuellen Zustands der Datenbank zuständig, das kopiert wird, um eine Sicherungskopie in einer Datenbank-Vorlage anzulegen. Alle Transaktionen, die während der Erstellung des Prüfpunktabbilds nicht festgeschrieben wurden, müssen im Primärknoten als REDO-Transaktionen verzeichnet, an einen Sicherungsknoten gesendet und ausgeführt werden. Dies stellt die Abgleichsphase dar.
  • Das Kopieren eines Prüfpunktabbilds von einem Primärknoten in einen Sicherungsknoten und das Veranlassen des Sicherungsknotens, einen Abgleich mit dem Primärknoten durchzuführen, muss stattfinden, bevor die Kapazität des Hauptspeichers des Primärknotens erschöpft ist. Wenn die Kapazität des Hauptspeichers des Primärknotens erschöpft ist, schlägt der HSB-Synchronisierungsprozess fehl oder aber die REDO-Transaktionen des Primärknotens müssen alternativ im Massenspeicher gespeichert werden, um den Speicherbedarf zu verringern. REDO-Transaktionen im persistenten Speicher müssen von der Platte des persistenten Speichers gelesen werden, was wesentlich langsamer vonstatten geht als der Lesevorgang von Daten aus einem schnellen Speicher.
  • Greift man aus dem persistenten Speicher auf REDO-Transaktionen zu, verlangsamt dies die Abgleichsphase. Ein langsamer Abgleich erhöht das Risiko von Folgeausfällen sowie die Fähigkeit eines Sicherungsknotens insgesamt, rechtzeitig einen Abgleich mit dem Primärknoten durchzuführen. Zusätzliche Ausfälle während der gefährdeten Zeit können aus Sicht der HSB-Datenbank verhängnisvoll sein. Wenn ein Sicherungsknoten nach dem ersten Ausfall keinen Abgleich mit einem Primärknoten durchführen kann, erhöht sich das Risiko eines schwerwiegenden Fehlers in der Zukunft.
  • Daher wird die Abgleichsphase zu einer ernsthaften Bedrohung für die Verfügbarkeit von HSB-Datenbanken in den Fällen, in denen die Aktualisierungshäufigkeit hoch ist, und es ist wichtig, den HSB-Synchronisierungsprozess so schnell wie möglich zu machen, um dieses Risiko so klein wie möglich zu halten.
  • KURZDARSTELLUNG DER ERFINDUNG
  • In einem ersten Aspekt der Erfindung wird ein Replikator bereitgestellt, um ein Datenbankabbild von einem funktionsfähigen Primärknoten in einer verteilten Datenbankumgebung zu replizieren, wobei der Replikator aufweist: eine Abbildengine, um ein Prüfpunktabbild des Primärknotens einschließlich einer Datenbankstruktur und einer Vielzahl von Datenbankseiten anzugeben; eine Steuerfunktion (Controller), um eine Replikatsdatenbank auf einem Sicherungsknoten anzulegen, indem ein Sicherungsknoten initialisiert und die angegebene Datenbankstruktur auf dem initialisierten Sicherungsknoten gespeichert wird; einen Übertragungsmechanismus, um jede Datenbankseite des Prüfpunktabbilds an den Sicherungsknoten zum Speichern zu senden; eine Protokollfunktion (Logger), um, nachdem die Erstellung eines Prüfpunktabbilds gestartet wurde, jede nachfolgende Transaktion auf dem Primärknoten zu speichern und dadurch eine entsprechende REDO-Transaktion zu erzeugen, um sie an den Sicherungsknoten zu senden; eine Seitenkennung, um jede Datenseite zu kennzeichnen, an der eine jede nachfolgende Transaktion Operationen durchführt; einen parallelen Übertragungsmechanismus, um parallel zum Senden der Datenbankseiten eine jede erzeugte REDO-Transaktion in der Reihenfolge an den Sicherungsknoten zu senden, in der die entsprechende Transaktion stattfand, so dass der Sicherungsknoten die Transaktionen in der richtigen Reihenfolge replizieren kann; und eine Seitensteuerfunktion (page controller), um jede gekennzeichnete Datenbankseite zu priorisieren, so dass sie vor oder weitgehend zur selben Zeit wie eine entsprechende REDO-Transaktion an dem Sicherungsknoten ankommt, wobei die entsprechende REDO-Transaktion Operationen an der gekennzeichneten Datenbankseite durchführen kann, ohne darauf warten zu müssen, bis die verbleibende Datenbankseite auf dem Sicherungsknoten gespeichert wird.
  • Gemäß einem zweiten Aspekt der Erfindung wird ein Verfahren bereitgestellt, um ein Datenbankabbild von einem funktionsfähigen Primärknoten in einen Sicherungsknoten in einer verteilten Datenbankumgebung zu replizieren, wobei das Verfahren aufweist: Angeben eines Prüfpunktabbilds des Primärknotens einschließlich einer Datenbankstruktur und einer Vielzahl von Datenbankseiten; Einleiten des Anlegens einer Replikatsdatenbank auf einem Sicherungsknoten, indem ein Sicherungsknoten initialisiert und die angegebene Datenbankstruktur auf dem initialisierten Sicherungsknoten gespeichert wird; Senden einer jeden Datenbankseite des Prüfpunktabbilds an den Sicherungsknoten zum Speichern; nachdem die Erstellung eines Prüfpunktabbilds gestartet wurde, Speichern einer jeden Transaktion auf dem Primärknoten und Erzeugen einer entsprechenden REDO-Transaktion, um sie an den Sicherungsknoten zu senden; Kennzeichnen einer jeden Datenseite, an der eine jede REDO-Transaktion Operationen durchführt; parallel zum Senden der Datenbankseiten, Senden einer jeden erzeugten REDO-Transaktion in der Reihenfolge an den Sicherungsknoten, in der die entsprechende Transaktion stattfand, so dass der Sicherungsknoten die Transaktionen in der richtigen Reihenfolge replizieren kann; und Priorisieren einer jeden gekennzeichneten Datenbankseite, so dass sie vor oder weitgehend zur selben Zeit wie eine entsprechende REDO-Transaktion an dem Sicherungsknoten ankommt, wobei die entsprechende REDO-Transaktion Operationen an der gekennzeichneten Datenbankseite durchführt, ohne darauf warten zu müssen, bis jede Datenbankseite auf dem Sicherungsknoten gespeichert wird.
  • Es wird vorgeschlagen, dass die Datenbankstruktur angegeben, dem Primärknoten entnommen und an einen neu erzeugten Sicherungsknoten gesendet wird, wobei die REDO-Transaktion parallel dazu gesendet wird, um Operationen auf dem Sicherungsknoten durchzuführen. Der neu erzeugte Sicherungsknoten repliziert die Datenbankstruktur, sobald sie ankommt. Das Replizieren (das auch als Synchronisieren bezeichnet wird) schließt das Erzeugen einer leeren Datenbankstruktur (Metadaten, Tabellen und Indizes) ein. Unmittelbar nach dem strukturellen Replizieren der Metadaten kann der Sicherungsknoten damit beginnen, Verbindungen mit Datenbank-Clients herzustellen und diese zu bedienen. Die verbleibenden Datenseiten werden parallel zur Ausführung von REDO-Transaktionen gesendet. Ein Verzahnen von Datenbankseiten und REDO-Transaktionen ist vorteilhaft, da der Sicherungsknoten die Daten, die am meisten benötigt werden, zuerst empfängt.
  • Zu den nennenswertesten Vorteilen gehört, dass Primärknoten Transaktionen unterbrechungsfrei ausführen können; außerdem können Primärknoten damit beginnen, REDO-Transaktionen an den Sicherungsknoten zu senden, sobald der Sicherungsknoten die Metadaten empfangen und verarbeitet hat. Darüber hinaus machen es die Ausführungsformen möglich, parallel zum Senden von REDO-Transaktionen Datenseiten aus dem Hauptspeicher an den Sicherungsknoten zu senden.
  • Die Ausführungsformen erkennen die Möglichkeit, REDO-Transaktionen von einem Primärknoten in einen Sicherungsknoten zur selben Zeit zu replizieren, zu der eine Vorlagendatenbank (Seed-Datenbank) vom Primärknoten in einen Sicherungsknoten kopiert wird. Anders ausgedrückt, ein HSB-Synchronisierungsprozess schließt herkömmlicherweise das Übertragen eines frischen Prüfpunktabbilds aus dem Massenspeicher eines Primärknotens an einen Sicherungsknoten, gefolgt von einer Abgleichsphase, ein. Erst nach der Abgleichsphase ist es möglich, Protokolltransaktionen von einem Primärknoten an einen Sicherungsknoten zu starten.
  • Die Ausführungsformen ermöglichen es, ein Prüfpunktabbild direkt aus dem Hauptspeicher eines Primärknotens ohne Eingabe-/Ausgabe-Zugriff auf den langsamen persistenten Plattenspeicher in einen Sicherungsknoten zu kopieren. Die Ausführungsformen ermöglichen es auch, während eines HSB-Synchronisierungsprozesses mit dem Replizieren von aktiven REDO-Transaktionen von einem Primärknoten in einen Sicherungsknoten zu beginnen. Folglich geht die Übertragung von Prüfpunktabbildern schneller vonstatten, da es keine Operationen im persistenten Speicher gibt. Außerdem ist der Speicherbedarf in einem Primärknoten wesentlich geringer als in dem Fall, in dem alle aktiven Transaktionen im Primärknoten zwischengespeichert werden müssen, um ein ganzes Prüfpunktabbild (das heißt, jede Datenseite) zu übertragen.
  • Somit ist die Dauer des Synchronisierungsprozesses einer Datenbank nicht an die Leistungsfähigkeit einer Platte oder eines Systems, sondern an die Übertragungskapazität des Netzwerks gebunden. Da sich die Übertragungskapazität des Netzwerks erhöhen lässt, beispielsweise, indem anstelle von TCP/IP proprietäre Netzprotokolle verwendet werden, wird der Eingabe-/Ausgabe-Engpass in den bzw. aus dem Massenspeicher beseitigt, wodurch der HSB-Synchronisierungsprozess verkürzt und die Gesamtverfügbarkeit einer HSB-Datenbank erhöht werden.
  • Die bevorzugte Ausführungsform wird in Bezug auf Two-Safe-Received-(2SR-)Protokolltransaktionen beschrieben, doch könnten andere Ausführungsformen andere Arten von Transaktionen einschließlich One-Safe-Received-(1SR-)Protokolltransaktionen verwenden, bei denen Transaktionen eine Festschreibung durchführen, sobald eine Festschreibungsanforderung von einer Festschreibungsoperation im Primärknoten an den Sicherungsknoten gesendet wurde.
  • Vorteilhafterweise wird einer geänderten Datenbankseite eine höhere Priorität als einer nicht geänderten Datenbankseite eingeräumt. Es ist von Vorteil, die am häufigsten verwendeten Daten (das heißt geänderte Seiten oder genutzte Seiten) so bald wie möglich zu senden, so dass Seiten, die weniger häufig gebraucht werden, nicht um gemeinsam genutzte Ressourcen konkurrieren.
  • Noch vorteilhafter ist, dass einer Datenbankseite im Hauptspeicher eine höhere Priorität als Datenseiten im persistenten Speicher eingeräumt wird. Der Hauptspeicher wird priorisiert, da der Zugriff auf Daten schneller und die Übertragungszeiten kürzer als beim persistenten Speicher sind. Der Hauptspeicher ist üblicherweise ein flüchtiger Speicher mit einer geringeren Kapazität, aber schnelleren Zugriffszeiten. Beim persistenten Speicher handelt es sich üblicherweise um ein persistentes Plattenlaufwerk mit einer höheren Kapazität, aber langsameren Zugriffszeiten.
  • Von noch größerem Vorteil ist, dass das Verfahren des Weiteren aufweist: Kennzeichnen von zwei oder mehr Datenseiten, an denen eine REDO-Transaktion Operationen durchführt; und Senden der zwei oder mehr Datenseiten parallel zum Senden der erzeugten REDO-Transaktion.
  • Darüber hinaus ist noch von Vorteil, dass der Primärknoten den Sicherungsknoten darüber benachrichtigt, dass alle Datenbankseiten gesendet worden sind.
  • Vorzugsweise benachrichtigt der Sicherungsknoten den Primärknoten darüber, dass alle Datenbankseiten empfangen worden sind.
  • Bevorzugt werden REDO-Transaktionen und Datenbankseiten in einem Sendepufferspeicher verschränkt, bevor sie an einen Sicherungsknoten gesendet werden.
  • Noch bevorzugter belasten Transaktionen den Primärknoten fortlaufend.
  • Die Ausführungsformen wirken sich auf Transaktionsprozesse aus, die außerhalb der Clusterdatenbankumgebung weitergeführt werden, so dass die Leistungsfähigkeit der Datenbank den Transaktionsprozessen während des Ausfalls eines Knotens weitgehend konsistent und nicht stark nachlassend erscheint. Eine solche Wirkung entfaltet sich auf Maschinen- und Systemebene eines ausführenden Computers und unterhalb einer jeden darüber liegenden Anwendungsebene. Die Ausführungsformen zeigen, dass der Computer während des Ausfalls eines Knotens schneller wird.
  • In einem dritten Aspekt der Erfindung wird ein Computerprogrammprodukt bereitgestellt, um eine funktionsfähige primäre Datenbank in einer Clusterdatenbankumgebung zu replizieren, wobei das Computerprogrammprodukt ein von einem Computer lesbares Speichermedium aufweist, das über damit realisierten, von einem Computer lesbaren Programmcode verfügt, und wobei der von einem Computer lesbare Programmcode so konfiguriert ist, dass er alle Schritte der Verfahren durchführt.
  • Das Computerprogrammprodukt weist eine Reihe von Anweisungen, die von einem Computer gelesen werden können, auf, welche sich entweder fest auf einem physisch greifbaren Datenträger befinden, wie zum Beispiel einem vom einem Computer lesbaren Datenträger, zum Beispiel einer optischen Platte, einer Magnetplatte, einem Halbleiterlaufwerk, oder die an ein Computersystem unter Verwendung eines Modems oder einer anderen Schnittstelleneinheit über ein physisch greifbares Medium, einschließlich, ohne darauf beschränkt zu sein, optischer oder analoger Übertragungsleitungen, oder aber nicht physisch greifbar unter Verwendung von drahtlosen Techniken, einschließlich, ohne darauf beschränkt zu sein, Mikrowelle, Infrarot oder anderer Übertragungstechniken, übertragen werden können. Die Reihe der von einem Computer lesbaren Anweisungen enthält die gesamte oder einen Teil der hier zuvor beschriebenen Funktionalität.
  • Der Fachmann versteht, dass solche von einem Computer lesbaren Anweisungen in mehreren Programmiersprachen zur Verwendung mit vielen Computerarchitekturen oder Betriebssystemen geschrieben werden können. Überdies können solche Anweisungen unter Verwendung einer beliebigen aktuellen oder zukünftigen Speichertechnologie, einschließlich, ohne darauf beschränkt zu sein, einer Halbleiter-, Magnet oder optischen Technologie, gespeichert oder unter Verwendung einer beliebigen aktuellen oder zukünftigen Übertragungstechnologie, einschließlich, ohne darauf beschränkt zu sein, einer optischen, Infrarot- oder Mikrowellentechnologie, übertragen werden. Es ist vorgesehen, dass ein solches Computerprogrammprodukt als ein austauschbarer Datenträger mit Begleitdokumentation in gedruckter oder elektronischer Form, zum Beispiel in Folie eingeschweißt, vorab geladen mit einem Computersystem, zum Beispiel auf einem ROM oder einer Festplatte eines Systems, oder von einem Server oder einem elektronischen Schwarzen Brett über ein Netzwerk, zum Beispiel über das Internet oder das World Wide Web, vertrieben wird.
  • In einem vierten Aspekt der Erfindung wird ein Computerprogramm bereitgestellt, das auf einem von einem Computer lesbaren Datenträger gespeichert ist und in den internen Hauptspeicher eines digitalen Computers geladen werden kann, welches Teile von Software-Code aufweist, wenn das Programm auf einem Rechner ausgeführt wird, um alle Schritte der Verfahrensansprüche durchzuführen.
  • In einem fünften Aspekt der Erfindung wird ein Datenträgeraspekt der bevorzugten Ausführungsform bereitgestellt, der funktionsfähige Computer-Datenstrukturen aufweist, um, wenn er in ein Computersystem geladen und dadurch darauf betrieben wird, das Computersystem in die Lage zu versetzen, alle Schritte der Verfahrensansprüche durchzuführen. Ein geeigneter Datenträger könnte ein Halbleiterspeicher, ein Magnetplattenlaufwerk oder eine optische Platte sein. Kanäle für die Übertragung von Daten können ebenfalls Speichermedien aller Art sowie Signalübertragungsmedien wie zum Beispiel drahtgebundene oder drahtlose Signalübertragungsmedien aufweisen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Bevorzugte Ausführungsformen der vorliegenden Erfindung werden nun lediglich anhand eines Beispiels und mit Bezug auf die folgenden Zeichnungen beschrieben, bei denen:
  • 1 eine Implementierungsübersicht der bevorzugten Ausführungsform Ist;
  • 2 eine Komponentenübersicht der bevorzugten Ausführungsform ist;
  • 3 ein Ablaufplan eines Prozesses der bevorzugten Ausführungsform Ist;
  • die 4A bis 4D Ablaufpläne von Unterprozessen der bevorzugten Ausführungsform sind;
  • 5 ein Ablaufplan eines entsprechenden Prozesses eines Sicherungsknotens der bevorzugten Ausführungsform ist; und
  • 6 eine Implementierungsübersicht einer parallelen Datenverarbeitungsausführungsform ist.
  • AUSFÜHRLICHE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
  • Bezug nehmend auf 1 wird die Implementierung einer bevorzugten Ausführungsform in einem Hot-Standby-Datenbanksystem 10 beschrieben. Das Hot-Standby-Datenbanksystem 10 kann mit zahlreichen anderen Umgebungen oder Konfigurationen von universellen oder speziellen Datenverarbeitungssystemen betrieben werden. Zu Beispielen für bekannte Datenverarbeitungssysteme, Datenverarbeitungsumgebungen und/oder -konfigurationen, die für den Einsatz mit dem Hot-Standby-Datenbanksystem 10 geeignet sein können, gehören, ohne darauf beschränkt zu sein, Personal-Computer-Systeme, Server-Computersysteme, Thin-Clients, Thick-Clients, tragbare oder Laptopgeräte, Mehrprozessorsysteme, auf einem Mikroprozessor beruhende Systeme, Aufsatzgeräte (Set-Top-Boxen), programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Mainframe-Computersysteme und verteilte Cloud-Computing-Umgebungen, zu denen beliebige der vorstehenden Systeme oder Geräte gehören.
  • Das Hot-Standby-Datenbanksystem 10 kann in dem allgemeinen Kontext von Anweisungen, die von einem Computersystem ausgeführt werden können, wie zum Beispiel Programmmodulen, welche von einem Computer-Prozessor ausgeführt werden, beschrieben werden. Im Allgemeinen können Programmmodule Routinen, Programme, Objekte, Komponenten, Logik und Datenstrukturen enthalten, die bestimmte Aufgaben (Tasks) durchführen oder bestimmte abstrakte Datentypen realisieren. Das Hot-Standby-Datenbanksystem 10 kann in verteilten Cloud-Computing-Umgebungen realisiert werden, in denen Tasks von fernen Verarbeitungseinheiten durchgeführt werden, welche über ein Übertragungsnetzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl in lokalen als auch in fernen Speichermedien eines Computersystems, darunter auch in Hauptspeichereinheiten, befinden.
  • Das Hot-Standby-Datenbanksystem 10 weist auf: den Primärknoten 12 in Form von einem Mehrzweckcomputerserver; eine oder mehrere Eingabeeinheiten 14 und Ausgabeeinheiten 16, die direkt an den Primärknoten 12 angeschlossen sind; einen Sicherungsknoten 12' in Form von einem Computerserver und mindestens einen Ersatzknoten 13.
  • Das Hot-Standby-Datenbanksystem 10 ist mit einem Netzwerk 20 verbunden. Das Hot-Standby-Datenbanksystem 10 tauscht mit einem Benutzer 18 unter Verwendung der Eingabeeinheiten 14 und der Ausgabeeinheiten 16 Daten aus. Zu den Eingabeeinheiten 14 gehören eines oder mehrere von Folgendem: eine Tastatur, ein Scanner, eine Maus, eine Rollkugel oder eine andere Zeigeeinheit. Zu den Ausgabeeinheiten 16 gehören ein Bildschirm oder ein Drucker oder mehrere Bildschirme oder mehrere Drucker. Das Hot-Standby-Datenbanksystem 10 tauscht mit Netzwerkeinheiten (nicht gezeigt) über das Netzwerk 20 Daten aus. Bei dem Netzwerk 20 kann es sich um ein lokales Netz (LAN), ein Weitverkehrsnetz (WAN) oder das Internet handeln.
  • Der Computerserver-Primärknoten 12 weist auf: eine zentrale Verarbeitungseinheit (CPU) 22; einen Netzwerkadapter 24; einen Einheitenadapter 26; einen Bus 28 und einen Hauptspeicher 30.
  • Die CPU 22 lädt Maschinenanweisungen aus dem Hauptspeicher 30 und führt als Reaktion auf die Anweisungen Maschinenoperationen durch. Zu diesen Maschinenoperationen gehören: Erhöhen oder Erniedrigen eines Werts im Register (nicht gezeigt); Übertragen eines Werts aus dem Hauptspeicher 30 in ein Register oder umgekehrt; Verzweigen zu einem anderen Speicherort im Hauptspeicher, wenn eine Bedingung wahr oder falsch ist (was auch als bedingte Verzweigungsanweisung bezeichnet wird); und Addieren oder Subtrahieren der Werte in zwei verschiedenen Registern und Laden des Ergebnisses in ein anderes Register. Eine gebräuchliche CPU kann viele verschiedene Maschinenoperationen durchführen. Ein Satz von Maschinenanweisungen wird als Maschinencodeprogramm bezeichnet, die Maschinenanweisungen werden in einer Maschinencodesprache geschrieben, bei der es sich um die niedrigste Sprachebene der Abstraktion handelt, die in dem System möglich ist. Ein in einer höheren Programmiersprache geschriebenes Computerprogramm muss zuerst in ein Maschinencodeprogramm kompiliert werden, bevor es ausgeführt werden kann. Alternativ kann ein Maschinencodeprogramm wie zum Beispiel eine virtuelle Maschine oder ein Interpreter eine höhere Programmiersprache in Bezug auf Maschinenoperationen auswerten.
  • Der Netzwerkadapter 24 ist mit dem Bus 28 und dem Netzwerk 20 verbunden, um einen Datenaustausch zwischen dem Primärknoten 12 und Netzwerkeinheiten einschließlich Sicherungsknoten zu ermöglichen.
  • Der Einheitenadapter 26 ist mit dem Bus 28 sowie Eingabeeinheiten 14 und Ausgabeeinheiten 16 verbunden, um einen Datenaustausch zwischen dem Computerserver 12 und Eingabeeinheiten 14 und Ausgabeeinheiten 16 zu ermöglichen.
  • Der Bus 28 verbindet die Hauptsystemkomponenten miteinander, darunter den Hauptspeicher 30 mit der CPU 22. Der Bus 28 stellt eine oder mehrere von diversen beliebigen Arten von Busstrukturen einschließlich eines Hauptspeicher-Busses oder einer Hauptspeicher-Steuereinheit, eines peripheren Busses, eines Accelerated Graphics Port und eines Prozessor- oder lokalen Busses, der eine beliebige einer Vielzahl von Busarchitekturen nutzt, dar. Als Beispiel, aber nicht darauf beschränkt, gehören zu solchen Architekturen der Bus ”Industry Standard Architecture (ISA)”, der Bus ”Micro Channel Architecture (MCA)”, der Bus ”Enhanced ISA (EISA)”, der lokale Bus ”Video Electronics Standards Association (VESA)” und der Bus ”Peripheral Component Interconnects (PCI)”.
  • Der Hauptspeicher 30 enthält von einem Computersystem lesbare Datenträger in Form eines flüchtigen Hauptspeichers 32 und eines nicht flüchtigen oder persistenten Hauptspeichers 34. Zu Beispielen für den flüchtigen Hauptspeicher 32 gehören der Direktzugriffsspeicher (RAM) 36 und der Cachespeicher 38. Der volatile Hauptspeicher wird im Allgemeinen verwendet, weil er schneller ist, und der nicht flüchtige Speicher wird im Allgemeinen verwendet, weil er die Daten länger speichert. Das Hot-Standby-Datenbanksystem 10 kann darüber hinaus weitere austauschbare und/oder nicht austauschbare, flüchtige und/oder nicht flüchtige Speichermedien eines Computersystems enthalten. Lediglich als Beispiel kann der persistente Speicher 34 für Leseoperationen von und für Schreiboperationen auf einen nicht austauschbaren, nicht flüchtigen Magnetdatenträger (nicht gezeigt und üblicherweise ein Magnetfestplatten- oder ein Halbleiterlaufwerk) bereitgestellt werden. Obgleich nicht gezeigt, können weitere Speichermedien bereitgestellt werden, darunter: ein externer Anschluss für einen austauschbaren, nicht flüchtigen Halbleiterspeicher; und ein optisches Plattenlaufwerk, um Leseoperationen von oder Schreiboperationen auf eine austauschbare, nicht flüchtige optische Platte wie zum Beispiel eine Compact-Disk (CD), eine digitale Videoplatte (DVD) oder Blu-ray durchzuführen. In diesen Fällen kann jedes Speichermedium über eine oder mehrere Datenträger-Schnittstellen mit dem Bus 28 verbunden werden. Wie weiter gezeigt und nachstehend beschrieben wird, kann der Systemspeicher 30 mindestens ein Programmprodukt enthalten, das über einen Satz (zum Beispiel mindestens einen Satz) von Programmmodulen verfügt, die so konfiguriert sind, dass sie die Funktionen von Ausführungsformen der Erfindung ausführen.
  • Der Satz von Programmmodulen, die so konfiguriert sind, dass sie die Funktionen der bevorzugten Ausführungsform ausführen, weist die Datenbank 100A und den Replikator 200A auf. Der Sicherungsknoten 12' weist die Datenbank 100B und den Replikator 200B auf. Zu weiteren Programmmodulen, die die bevorzugte Ausführungsform unterstützen, aber nicht gezeigt sind, gehören Firmware, ein Bootstrap-Programm, ein Betriebssystem und Support-Anwendungen. Zu dem Betriebssystem, den Support-Anwendungen, anderen Programmmodulen und Programmdaten oder einer bestimmten Kombination daraus kann jeweils eine Implementierung einer Netzwerkumgebung gehören.
  • Das Hot-Standby-Datenbanksystem 10 tauscht mit mindestens einem Netzwerk 20 (wie zum Beispiel einem lokalen Netz (LAN), einem allgemeinen Weitverkehrsnetz (WAN) und/oder einem öffentlichen Netz wie dem Internet) über den Netzwerkadapter 24 Daten aus. Wie gezeigt ist, tauscht der Netzwerkadapter 24 mit den anderen Komponenten des Computerservers 12 über den Bus 28 Daten aus. Es sollte sich verstehen, dass auch andere Hardware- und/oder Software-Komponenten in Verbindung mit dem Hot-Standby-Datenbanksystem 10 verwendet werden könnten, obgleich diese nicht gezeigt sind. Zu Beispielen gehören, ohne auf diese beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Anordnungen von Festplattenlaufwerken, eine redundante Anordnung unabhängiger Festplatten (RAID), Bandlaufwerke und Speichersysteme zur Datenarchivierung.
  • Bezug nehmend auf 2 weist der Replikator 200 (eine allgemeine Klasse von Replikatoren 200A und 200B) die folgenden Komponenten auf: den copyid-Index 202; den dirtyid-Index 204, die Sendewarteschlange 206; das Primärverfahren 300 und das Sicherungsknotenverfahren 500.
  • Bei dem copyid-Index 202 handelt es sich um eine Datenstruktur, die dazu dient, Verweise für Datenbankseiten zu speichern, die bereits an einen Sicherungsknoten für ein bestimmtes Prüfpunktabbild gesendet worden sind.
  • Bei dem dirtyid-Index 204 handelt es sich um eine Datenstruktur, die dazu dient, Verweise für Datenbankseiten zu speichern, die seit der Angabe des Prüfpunktabbilds geändert worden sind. Wenn alle Datenbankseiten für ein Prüfpunktabbild aus dem Hauptspeicher gelesen werden sollen, statt nicht geänderte Datenbankseiten von einer Platte zu lesen, enthält der dirtyid-Index 204 alternativ Kennungen für alle Datenbankseiten. Im ersteren Fall wird, wann immer eine nicht geänderte Datenbankseite geändert wird, ihre Kennung zum dirtyid-Index 204 hinzugefügt. Der Inhalt des dirtyid-Index 204 wird gelöscht, wenn die Erstellung des Prüfpunktabbilds abgeschlossen ist. Im letzteren Fall enthält der dirtyid-Index 204 alle Kennungen von Datenbankseiten der Datenbank.
  • Die Sendewarteschlange 206 ist eine Warteschlange, die dazu dient, Datenbankseiten und REDO-Transaktionen zu speichern, bevor diese an einen Sicherungsknoten gesendet werden.
  • Das Primärverfahren 300 dient zum Replizieren eines Primärknotens und wird nachstehend mit Bezug auf 3 und die 4A bis 4D ausführlich beschrieben.
  • Das Sicherungsknotenverfahren 500 ist ein entsprechender Sicherungsknotenprozess zur Replizierung des Primärknotens und wird nachstehend mit Bezug auf 5 ausführlich beschrieben.
  • Bezug nehmend auf 3 weist das Primärverfahren 300 die logischen Prozessschritte 301 bis 307 auf.
  • In einer Anfangssituation führt das Primärverfahren 300 Transaktionen aus, wenn ein anderer Knoten, der ein neuer Sicherungsknoten werden soll, gestartet wird. Ein neuer Sicherungsknoten verfügt über kein eigenes Datenbankabbild, entweder, weil es beschädigt wurde oder weil es voliständig fehlt. Er muss sich eine gemeinsame Datenbank mit dem Primärknoten teilen. Das Primärverfahren 300 erzeugt eine eigenständige, konsistente Version seiner Datenbank, die als Prüfpunktabbild oder Momentaufnahme bezeichnet wird. In einer speicherinternen Datenbank wird der Prüfpunkt im Hauptspeicher erzeugt, von wo aus er zur Übertragung an einen Sicherungsknoten kopiert wird. Seiten können parallel von der Platte und aus dem Hauptspeicher gelesen werden. Genutzte Seiten befinden sich im Hauptspeicher, da sie erst kürzlich geändert wurden. Folglich ist es wahrscheinlicher, dass sie zu einem früheren Zeitpunkt als die Seiten auf der Platte erneut geändert werden.
  • Eine im copyid-Index 202 eines Primärknotens angetroffene Datenbankseite hat einen der folgenden Zustände: BUFFERED (IM PUFFERSPEICHER BEFINDLICH) (wenn sie bereits zum Sendepufferspeicher hinzugefügt worden ist, sie also schon aufgefunden wurde und man entschieden hat, sie an einen Sicherungsknoten zu senden); und SENT (GESENDET) (wenn das tatsächliche Senden einer Seite stattgefunden hat).
  • Der Schritt 301 dient dazu, ein neues Prüfpunktabbild und eine neue Prüfpunktkennung zu erzeugen. Ein Prüfpunktzähler wird erhöht. Von Transaktionen verursachte Aktualisierungen verlieren während der Erstellung eines Prüfpunktabbilds keine Daten. Aktualisierungstransaktionen können während der Erstellung von Prüfpunktabbildern Festschreibungsoperationen durchführen. Ältere Versionen von Prüfpunktabbildern werden verwaltet, bis sie im persistenten Speicher abgelegt werden.
  • Der Schritt 302 dient dazu, die notwendige Datenbankstruktur einschließlich Metadaten und Systemtabellen aus der Datenbank zu entnehmen und sie an den Sicherungsknoten 12' zu senden.
  • Der Schritt 303 dient dazu, auf eine Antwort zu warten. Eine Bestätigung trifft von dem Sicherungsknoten 12' ein, die darüber informiert, dass Metadaten erfolgreich verarbeitet wurden und der Sicherungsknoten 12' zum Empfang von Daten und REDO-Transaktionen bereit ist.
  • Der Schritt 304 dient zur parallelen Verarbeitung von REDO-Transaktionen und Datenbankseiten und wird nachstehend mit Bezug auf das parallele Prozessverfahren 304 der 4A bis 4D ausführlicher beschrieben.
  • Der Schritt 305 dient dazu, zu erkennen, wann alle Datenbankseiten an den Sicherungsknoten gesendet worden sind, und dazu, den Sicherungsknoten darüber zu benachrichtigen, dass keine weiteren Seiten gesendet werden.
  • Der Schritt 306 dient zur Bestätigung, dass alle Datenbankseiten von dem Sicherungsknoten empfangen worden sind und wiederhergestellt wurden.
  • Der Schritt 307 dient dazu, zur normalen Vorgehensweise zurückzukehren und von einem lokalen zu einem verteilten Festschreibungsprotokoll zu wechseln.
  • Bezug nehmend auf 4A weist das parallele Prozessverfahren 304' die logischen Prozessschritte 304A1, 304A2, 304A3, 304A4, 304F und das Verfahren 304B auf.
  • Der Schritt 304A1 dient dazu, den Prozess in zwei gesonderte Prozesse aufzuteilen, die parallel ausgeführt werden: einen ersten Prozess, um Datenbankseiten an den Sicherungsknoten zu senden, welcher am Schritt 304A2 beginnt, und einen zweiten Prozess am Verfahren 304B, um REDO-Transaktionen zu verarbeiten.
  • Der Schritt 304A2 dient zur Feststellung, ob eine Datenbankseite seit der Erstellung des Prüfpunktabbilds nicht genutzt oder genutzt (nicht geändert oder geändert) wurde. Der dirtyid-Index 204 wird herangezogen. Wenn die Datenbankseite nicht im dirtyid-Index 204 aufgeführt ist, wird die Seite nicht genutzt, und es wird mit dem Schritt 304A3 fortgefahren. Andernfalls wird die Seite genutzt und es wird mit dem Schritt 304A4 fortgefahren. Die Datenbankseite wird genutzt, wenn sie im dirtyid-Index 204 aufgeführt ist, da Änderungen an ihr vorgenommen worden sind.
  • Der Schritt 304A3 dient dazu, die Datenbankseite aus dem Hauptspeicher oder aus dem Massenspeicher zu lesen. Im Hinblick auf die Konsistenz spielt dies keine Rolle, da beide Seiten einander entsprechen. In der bevorzugten Ausführungsform wird die Datenbankseite jedoch aus dem funktionsfähigen Hauptspeicher gelesen, da die Zugriffszeiten schneller sind. Die Datenbankseite, auf die zugegriffen wurde, wird an die Sendewarteschlange 206 zur Übertragung an den Sicherungsknoten gesendet. Nächster Schritt 304F.
  • Der Schritt 304A4 dient dazu, die Datenbankseiten nur deshalb aus dem Hauptspeicher zu lesen, weil sich darin die jeweils aktuellste Kopie der Seite befindet. Nächster Schritt 304F.
  • Das Verfahren 304B dient zum Senden von REDO-Transaktionen an den Sicherungsknoten und wird nachstehend mit Bezug auf 4B ausführlicher beschrieben. Nächster Schritt 304F.
  • Der Schritt 304F dient der Feststellung, ob es weitere Datenbankseiten oder REDO-Transaktionen zu verarbeiten gibt, und wenn ja, der Rückkehr zum Schritt 304A1. Andernfalls wird mit dem Schritt 305 fortgefahren.
  • Bezug nehmend auf 4B weist das Verfahren 304B (sende REDO-Transaktionen an den Sicherungsknoten) die logischen Prozessschritte 304B1 bis 304B9, das Verfahren 304C und das Verfahren 304D auf.
  • Der Schritt 304B1 dient zur Angabe einer Schleife für jede REDO-Transaktion und zur Entnahme einer Kennung einer Datenbankseite von einer entsprechenden REDO-Transaktion.
  • Der Schritt 304B2 dient dazu, eine REDO-Transaktion mit zwei oder mehr Datenbankseiten zu behandeln, indem alle Prüfungen auf allen Seiten durchgeführt werden.
  • Der Schritt 304B3 dient dazu, den copyid-Index 202 auf entnommene Seitenkennungen oder auf Seitenkennungen zu durchsuchen, um festzustellen, ob die Datenbankseite bereits an den Sicherungsknoten gesendet worden ist.
  • Der Schritt 304B4 dient dazu, zum Schritt 304B5 zu verzweigen, wenn die entnommene Seitenkennung (Seiten-ID) nicht im copyid-Index 202 aufgeführt ist und folglich noch nicht an den Sicherungsknoten gesendet worden ist. Andernfalls, wenn sich die entnommene Seiten-ID im copyid-Index 202 befindet, wird mit dem Schritt 304B9 fortgefahren.
  • Der Schritt 304B5 dient dazu, die entnommene Seiten-ID im dirtyid-Index 204 zu suchen, um festzustellen, ob sie nach dem Prüfpunkt geändert worden ist.
  • Der Schritt 304B6 dient dazu, zum Schritt 304B7 zu verzweigen, wenn der dirtyid-Index 204 die entnommene Seiten-ID enthält. Andernfalls verzweigt der Prozess zum Verfahren 304C.
  • Das Verfahren 304C dient zur Behandlung von Seiten-IDs, die nicht im copyid-Index 202 oder im dirtyid-Index 204 aufgefunden werden, und der Weiterschaltung zum Schritt 304F, wenn das Verfahren abgeschlossen ist. Das Verfahren 304C wird nachstehend mit Bezug auf 4C ausführlicher beschrieben.
  • Der Schritt 304B7 dient dazu, die Seite aus dem Hauptspeicher zu lesen.
  • Der Schritt 304B8 dient dazu, die gelesene Seite zur Sendewarteschlange 206 hinzuzufügen, um sie an den Sicherungsknoten zu senden.
  • 304F wurde zuvor als eine in einer Schleife erfolgende Rückkehr zum Schritt 304A1 beschrieben, wenn es weitere Seiten oder REDO-Transaktionen gibt.
  • Der Schritt 304B9 dient dazu, den Status des Eintrags zu lesen und zum Verfahren 304D weiterzuschalten.
  • Das Verfahren 304D dient zur Behandlung von Datenbankseiten-IDs, die im copyid-Index 202 aufgefunden werden, und der Weiterschaltung zum Schritt 304F, wenn das Verfahren abgeschlossen ist. Das Verfahren 304D wird nachstehend mit Bezug auf 4D ausführlicher beschrieben.
  • Bezug nehmend auf 4C weist das Verfahren 304C die logischen Prozessschritte 304C1 bis 304C3, 304E1 und 304E2 auf.
  • Der Schritt 304C1 dient dazu, zum Schritt 304C2 zu verzweigen, wenn die entnommene Datenbankseite nicht genutzt und vor dem neuesten Prüfpunktabbild erstellt wurde. Andernfalls Schritt 304C3.
  • Der Schritt 304C2 dient dazu, eine Datenbankseite aus dem funktionsfähigen Hauptspeicher oder aus dem Massenspeicher zu lesen. Nächster Schritt 304E1.
  • Der Schritt 304E1 dient dazu, eine REDO-Transaktion zur Sendewarteschlange 206 hinzuzufügen. Nächster Schritt 304E2.
  • Der Schritt 304E2 dient dazu, die Kennung der Datenbankseite zum copyid-Index 202 hinzuzufügen, und der anschließenden Weiterschaltung zum Schritt 304F.
  • Der Schritt 304C3 dient dazu, nur die REDO-Transaktion zu der Sendewarteschlange 206 hinzuzufügen, bevor zum Schritt 304F weitergeschaltet wird.
  • Bezug nehmend auf 4D weist das Verfahren 304D die logischen Prozessschritte 304D1 bis 304D3 auf.
  • Der Schritt 304D1 dient dazu, zum Schritt 304D2 zu verzweigen, wenn der Status der Seite ”in der Warteschlange” lautet. Andernfalls, wenn der Status der Seite ”gesendet” lautet, erfolgt eine Verzweigung zum Schritt 304D3.
  • Der Schritt 30402 dient dazu, nach dem Speicherplatz der Seite in der Sendewarteschlange 206 zu suchen und die REDO-Transaktion in die Sendewarteschlange 206 hinter den Speicherplatz der Seite einzufügen. Anschließend erfolgt die Weiterschaltung zum Schritt 304F.
  • Der Schritt 304D3 dient dazu, die REDO-Transaktion baldmöglichst an den Sicherungsknoten zu senden, im Allgemeinen, ohne sie zur Warteschlange hinzuzufügen. Anschließend erfolgt die Weiterschaltung zum Schritt 304F.
  • Bezug nehmend auf 5 weist das Sicherungsknotenverfahren 500 die logischen Prozessschritte 501 bis 506 (einschließlich der Teilschritte 503.1, 503.2, 503.3, 504A1, 504A2, 504B1 und 504B2) auf. Das Sicherungsknotenverfahren 500 stellt eine Ergänzung des Primärverfahrens 300 dar.
  • Der Schritt 501 dient dazu, Metadaten von dem Primärknoten zu empfangen. Metadaten enthalten die Datenbankstruktur und notwendige Informationen, um zum Beispiel ein Datenbankschema zu erzeugen, und ermöglichen es dem Sicherungsknoten, die Datenbank zu öffnen.
  • Der Schritt 502 dient dazu, die Metadaten zu verarbeiten und eine Bestätigung an den Primärknoten zurückzusenden, dass er zum Empfang des Prüfpunktabbilds des Primärknotens und von REDO-Transaktionen bereit ist, die Transaktionen entsprechen, welche im Primärknoten ausgeführt werden.
  • Der Schritt 503 dient dazu, zum Schritt 503.1 zu verzweigen, wenn der Seitentyp vom Typ Prüfpunktabbild ist. Andernfalls, wenn der Dokumenttyp vom Typ REDO-Transaktion ist, schaltet der Schritt zum Schritt 503.2 weiter. Wenn der Sicherungsknoten eine Seite empfängt, stellt er sie wieder her, indem er Zeilen und notwendige Informationen, zum Beispiel die Tabellen-ID und die Transaktions-ID, entnimmt und indem er Zeilen in seine lokale Datenbank einfügt. Der Sicherungsknoten überwacht jede Seite, die er wiederhergestellt hat, indem er sie in den Index einfügt.
  • Der Schritt 503.1 dient dazu, die Tabellen-ID und die Transaktions-ID zu entnehmen und Zeilen und Indizes einzufügen, um die Sicherungsdatenbank zu erstellen. Dann folgt der Schritt 505.
  • Der Schritt 503.2 dient zur Entnahme der Tabellen-ID und der Transaktions-ID, dann folgt der Schritt 503.3.
  • Der Schritt 503.3 dient dazu, zu 504B1 zu verzweigen, wenn die Seite wiederhergestellt wird, und dazu, zum Schritt 504A1 zu verzweigen, wenn die Seite nicht wiederhergestellt wird.
  • Der Schritt 503A1 dient dazu, zum Schritt 503A2 zu verzweigen, wenn die Seite mittels Sperrung wiederhergestellt werden kann, und zum Schritt 504B1, wenn dies nicht möglich ist.
  • Der Schritt 503A2 dient dazu, alle Sperren zu erwerben und zum Schritt 504B1 zu verzweigen, wenn sie alle erworben wurden. Wenn die Seite nicht wiederhergestellt wird, kann die Ausführung nur so weit fortgesetzt werden, wie notwendige Sperren erworben werden. Die Ausführung wartet, bis die entsprechende Seite wiederhergestellt wird. Wenn die Durchführung der Wiederherstellung mittels Sperrung stattfindet, muss die REDO-Transaktionsoperation ohne Sperren warten, bis die Wiederherstellung für die Seite abgeschlossen ist. Andernfalls, wenn die Seite wiederhergestellt wird, kann die REDO-Transaktion wie üblich ausgeführt werden. Wenn es möglich ist, REDO-Transaktionen in einer normalen HSB-Operation parallel auszuführen, dann ist dies auch während der Synchronisierung möglich.
  • Der Schritt 504B1 dient zur parallelen Ausführung der REDO-Transaktionen. Wenn der Sicherungsknoten eine REDO-Transaktion empfängt, entnimmt er ihr notwendige Informationen (zum Beispiel die Tabellen-ID und die Transaktions-ID) und prüft, ob die entsprechende Seite wiederhergestellt worden ist.
  • Der Schritt 504B2 dient dazu, zum Schritt 503 zu verzweigen, wenn der Primärknoten den Sicherungsknoten darüber benachrichtigt, dass die Prüfpunkte vollständig sind. Andernfalls, wenn es keine Benachrichtigung gibt, folgt der Schritt 505.
  • Der Schritt 505 dient zur Entnahme der Seiten-ID und zur Bestätigung. Wenn der Sicherungsknoten eine Benachrichtigung empfängt, dass der Prüfpunkt von dem Primärknoten vollständig gesendet wurde, entnimmt der Sicherungsknoten der Benachrichtigung die Seiten-ID. Wenn diese Seite vollständig wiederhergestellt wird, bestätigt er dem Primärknoten, dass das Prüfpunktabbild empfangen wurde.
  • Der Schritt 506 dient dazu, zur normalen Vorgehensweise zurückzukehren, indem vom lokalen zum verteilten Festschreibungsprotokoll gewechselt wird.
  • Weitere Ausführungsformen der Erfindung werden nun beschrieben.
  • Dem Fachmann dürfte klar sein, dass alle oder ein Teil der logischen Prozessschritte der bevorzugten Ausführungsform alternativ in einer Logik-Vorrichtung oder in einer Vielzahl von Logik-Vorrichtungen realisiert werden können, die Logikelemente aufweist beziehungsweise aufweisen, welche so angeordnet sind, dass sie die logischen Prozessschritte des Verfahrens durchführen, und dass solche Logikelemente Hardware-Komponenten, Firmware-Komponenten oder eine Kombination aus Hardware- und Firmware-Komponenten aufweisen können.
  • Dem Fachmann dürfte ebenso klar sein, dass alle oder ein Teil der Logikkomponenten der bevorzugten Ausführungsform alternativ in einer Logik-Vorrichtung realisiert werden können, die Logikelemente aufweist, um die Schritte des Verfahrens durchzuführen, und dass solche Logikelemente Komponenten wie zum Beispiel Logikgatter in beispielsweise einer programmierbaren logischen Anordnung oder einer anwendungsspezifischen integrierten Schaltung aufweisen können. Eine solche logische Anordnung kann darüber hinaus in Elementen realisiert werden, die eine solche Realisierung möglich machen, um zeitweise oder dauerhaft logische Strukturen in einer solchen Anordnung oder Schaltung aufzubauen, wobei beispielsweise eine virtuelle Hardware-Beschreibungssprache verwendet wird, die mittels fester oder übertragbarer Trägermedien gespeichert und übertragen werden kann.
  • In einer weiteren alternativen Ausführungsform kann die vorliegende Erfindung in Form von einem von einem Computer ausgeführten Verfahren zum Installieren eines Dienstes realisiert werden, der Schritte zum Installieren eines Computerprogrammcodes aufweist, welcher so beschaffen ist, dass er, wenn er in einer Computerinfrastruktur installiert und darauf ausgeführt wird, das Computersystem veranlasst, alle Schritte des Verfahrens durchzuführen.
  • Man wird als vorteilhaft erkennen, dass das Verfahren sowie Komponenten der bevorzugten Ausführungsform alternativ vollständig oder teilweise in einem parallelen Datenverarbeitungssystem realisiert werden können, welches zwei oder mehr Prozessoren aufweist, um eine parallele Software auszuführen.
  • Bezug nehmend auf 6 wird eine beispielhafte parallele Datenverarbeitungs-Ausführungsform 10P beschrieben, die parallele Gruppen von Hot-Standby-Datenbanksystemen zur parallelen Verarbeitung von Datenbanken aufweist. Die bevorzugte Ausführungsform wird in einem Server mit einem einzelnen Prozessor in einer verteilten Datenbankumgebung eingesetzt, aber eine andere Ausführungsform könnte in einem Server mit parallelen Prozessoren in einer verteilten Datenbankumgebung realisiert werden. Das parallele Hot-Standby-Datenbanksystem 10P wird in dem allgemeinen Kontext von Anweisungen, die von einem parallelen Computersystem ausgeführt werden können, wie zum Beispiel parallelen Programmmodulen, welche von dem parallelen Datenverarbeitungssystem 10P ausgeführt werden, beschrieben. Im Allgemeinen können parallele Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen enthalten, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen realisieren. Das parallele Hot-Standby-Datenbanksystem 10P weist auf: die parallelen Computerserver 12A und 12B. Eine direkte Verbindung oder ein Netzwerk ermöglicht den Zugriff zwischen den parallelen Computerservern 12A und 12B.
  • Der parallele Computerserver 12A weist auf: die CPU 22AA, die CPU 22AB; den Netzwerkadapter 24A; den Bus 28A und den Hauptspeicher 30A. Ebenso weist der parallele Computerserver 12B auf: die CPU 22BA, die CPU 22BB; den Netzwerkadapter 24B; den Bus 28B und den Hauptspeicher 30B.
  • Die Busse 28A und 28B stellen eine oder mehrere von diversen beliebigen Arten von Busstrukturen einschließlich eines Hauptspeicher-Busses oder einer Hauptspeicher-Steuereinheit, eines peripheren Busses, eines Accelerated Graphics Port und eines Prozessor- oder lokalen Busses, der eine beliebige Busarchitektur von vielen verschiedenen Busarchitekturen nutzt, dar.
  • Die Hauptspeicher 30A und 30B enthalten von einem Computersystem lesbare Datenträger in Form von flüchtigem Hauptspeicher 32A und 32B (wie zum Beispiel einen Direktzugriffsspeicher und einen Cachespeicher (nicht gezeigt)) und in Form von nicht flüchtigem oder persistentem Hauptspeicher 34A und 34B.
  • Der persistente Hauptspeicher 34A weist auf: mindestens zwei Datenbanken 100AA und 100AB; und das Replikatormodul 200A. Während der Ausführung Zehnt der Replikator die Objekte 200AA und 200AB ab; und die entsprechenden Datenbanken 100AA' und 100AB' werden in den jeweiligen Hauptspeicherbereichen 33AA und 33AB in dem flüchtigen Hauptspeicher 32A instanziiert.
  • Ebenso weist der persistente Hauptspeicher 34B auf: mindestens zwei Datenbanken 100BA und 100BB; und das Replikatormodul 200B. Während der Ausführung lehnt der Replikator die Objekte 200BA und 200BB ab; und die entsprechenden Datenbanken 100BA' und 100BB' werden in den jeweiligen Hauptspeicherbereichen 33BA und 33BB im flüchtigen Hauptspeicher 32B instanziiert.
  • Die persistenten Hauptspeicher 34A und 34B speichern auch: entsprechende Betriebssysteme, ein oder mehrere Anwendungsprogramme, ein Datenbankverwaltungssystem und andere Programmmodule. Das Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten oder eine bestimmte Kombination daraus können jeweils eine Ausführungsart einer Netzwerkumgebung beinhalten. Die Replikatormodule 200A und 200B werden bereitgestellt, um die Funktionen und/oder methodischen Vorgehensweisen der Ausführungsformen in einer parallelen Umgebung auszuführen.
  • Die Datenbank und die Replikatormodule sind autonome Teile der parallelen Ausführungsform. Im Betrieb werden diese beiden Arten von Modulen dem persistenten Hauptspeicher 34A und 34B entnommen und in den flüchtigen Hauptspeicher 32A und 34B geladen, so dass sie von entsprechenden CPUs (CPU 22AA, 22AB, 22BA, 22BB) getrennt voneinander und folglich parallel ausgeführt werden können.
  • In diesem Beispiel sind zwei CPUs pro Server gezeigt, doch kann eine beliebige Anzahl von CPUs verwendet werden, um alternative parallele Ausführungsformen aufzubauen. In diesem Beispiel werden zwei getrennte CPUs verwendet, doch könnte auch eine einzige Verarbeitungseinheit mit mehreren Prozessorkernen verwendet werden, um eine alternative Ausführungsform aufzubauen.
  • In dieser parallelen Ausführungsform sind die CPUs physische CPUs, aber in einer alternativen Ausführungsform können virtuelle CPUs simuliert werden. In einer virtuellen parallelen Datenverarbeitungs-Ausführungsform weist ein Computerserver eine virtuelle Datenverarbeitungsumgebung auf und virtuelle parallele Verarbeitungseinheiten könnten verwendet werden, um eine virtuelle parallele Datenverarbeitungs-Ausführungsform aufzubauen. Ein Computerserver weist eine virtuelle Datenverarbeitungsurngebung auf, die über eine virtuelle Verarbeitungseinheit mit mehreren virtuellen Prozessorkernen verfügt.
  • Weitere Ausführungsformen können eine beliebige Kombination aufweisen von: realen Verarbeitungseinheiten; Prozessorkernen von realen Verarbeitungseinheiten; virtuellen Verarbeitungseinheiten; und virtuellen parallelen Verarbeitungskernen.
  • Dem Fachmann dürfte klar sein, dass viele Verbesserungen und Änderungen an der vorstehenden beispielhaften Ausführungsform vorgenommen werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen.

Claims (18)

  1. Replikator, der dazu dient, ein Datenbankabbild von einem funktionsfähigen Primärknoten in einer verteilten Datenbankumgebung zu replizieren, wobei der Replikator aufweist: eine Abbildengine, um ein Prüfpunktabbild des Primärknotens einschließlich einer Datenbankstruktur und einer Vielzahl von Datenbankseiten anzugeben; eine Steuerfunktion, um eine Replikatsdatenbank auf einem Sicherungsknoten anzulegen, indem ein Sicherungsknoten initialisiert und die angegebene Datenbankstruktur auf dem initialisierten Sicherungsknoten gespeichert wird; einen Übertragungsmechanismus, um jede Datenbankseite des Prüfpunktabbilds an den Sicherungsknoten zum Speichern zu senden; eine Protokollfunktion, um, nachdem die Erstellung eines Prüfpunktabbilds gestartet wurde, jede nachfolgende Transaktion auf dem Primärknoten zu speichern und dadurch eine entsprechende REDO-Transaktion zu erzeugen, um sie an den Sicherungsknoten zu senden; eine Seitenkennung, um jede Datenseite zu kennzeichnen, an der eine jede nachfolgende Transaktion Operationen durchführt; einen parallelen Übertragungsmechanismus, um parallel zum Senden der Datenbankseiten eine jede erzeugte REDO-Transaktion in der Reihenfolge an den Sicherungsknoten zu senden, in der die entsprechende Transaktion stattfand, so dass der Sicherungsknoten die Transaktionen in der richtigen Reihenfolge replizieren kann; und eine Seitensteuerfunktion, um jede gekennzeichnete Datenbankseite zu priorisieren, so dass sie vor oder weitgehend zur selben Zeit wie eine entsprechende REDO-Transaktion an dem Sicherungsknoten ankommt, wobei die entsprechende REDO-Transaktion Operationen an der gekennzeichneten Datenbankseite durchführen kann, ohne darauf warten zu müssen, bis jede Datenbankseite auf dem Sicherungsknoten gespeichert wird.
  2. Replikator nach Anspruch 1, wobei einer geänderten Datenbankseite eine höhere Priorität als einer nicht geänderten Datenbankseite eingeräumt wird.
  3. Replikator nach Anspruch 1, wobei einer Datenbankseite im Hauptspeicher eine höhere Priorität als Datenbankseiten im persistenten Speicher eingeräumt wird.
  4. Replikator nach Anspruch 1, der des Weiteren aufweist: Kennzeichnen von zwei oder mehr Datenseiten, an denen eine REDO-Transaktion Operationen durchführt; und Senden der zwei oder mehr Datenseiten parallel zum Senden der erzeugten REDO-Transaktion.
  5. Replikator nach Anspruch 1, wobei der Primärknoten den Sicherungsknoten darüber benachrichtigt, dass alle Datenbankseiten gesendet worden sind.
  6. Replikator nach Anspruch 1, wobei der Sicherungsknoten den Primärknoten darüber benachrichtigt, dass alle Datenbankseiten empfangen worden sind.
  7. Replikator nach Anspruch 1, wobei REDO-Transaktionen und Datenbankseiten in einem Sendepufferspeicher verschränkt werden, bevor sie an einen Sicherungsknoten gesendet werden.
  8. Replikator nach Anspruch 1, wobei Transaktionen den Primärknoten fortlaufend belasten.
  9. Verfahren, das dazu dient, ein Datenbankabbild eines funktionsfähigen Primärknotens in einen Sicherungsknoten einer verteilten Datenbankumgebung zu replizieren, wobei das Verfahren aufweist: Angeben eines Prüfpunktabbilds des Primärknotens einschließlich einer Datenbankstruktur und einer Vielzahl von Datenbankseiten; Anlegen einer Replikatsdatenbank auf einem Sicherungsknoten, indem ein Sicherungsknoten initialisiert und die angegebene Datenbankstruktur auf dem initialisierten Sicherungsknoten gespeichert wird; Senden einer jeden Datenbankseite des Prüfpunktabbilds an den Sicherungsknoten zum Speichern; nachdem die Erstellung eines Prüfpunktabbilds gestartet wurde, Speichern einer jeden nachfolgenden Transaktion auf dem Primärknoten und dadurch Erzeugen einer entsprechenden REDO-Transaktion, um sie an den Sicherungsknoten zu senden; Kennzeichnen einer jeden Datenseite, an der eine jede nachfolgende Transaktion Operationen durchführt; parallel zum Senden der Datenbankseiten, Senden einer jeden erzeugten REDO-Transaktion in der Reihenfolge an den Sicherungsknoten, in der die entsprechende Transaktion stattfand, so dass der Sicherungsknoten die Transaktionen in der richtigen Reihenfolge replizieren kann; und Priorisieren einer jeden gekennzeichneten Datenbankseite, so dass sie vor oder weitgehend zur selben Zeit wie eine entsprechende REDO-Transaktion an dem Sicherungsknoten ankommt, wobei die entsprechende REDO-Transaktion Operationen an der gekennzeichneten Datenbankseite durchführen kann, ohne darauf warten zu müssen, bis jede Datenbankseite auf dem Sicherungsknoten gespeichert wird.
  10. Verfahren nach Anspruch 9, wobei einer geänderten Datenbankseite eine höhere Priorität als einer nicht geänderten Datenbankseite eingeräumt wird.
  11. Verfahren nach Anspruch 9, wobei einer Datenbankseite im Hauptspeicher eine höhere Priorität als Datenbankseiten im persistenten Speicher eingeräumt wird.
  12. Verfahren nach Anspruch 9, das des Weiteren aufweist: Kennzeichnen von zwei oder mehr Datenseiten, an denen eine REDO-Transaktion Operationen durchführt; und Senden der zwei oder mehr Datenseiten parallel zum Senden der erzeugten REDO-Transaktion.
  13. Verfahren nach Anspruch 9, wobei der Primärknoten den Sicherungsknoten darüber benachrichtigt, dass alle Datenbankseiten gesendet worden sind.
  14. Verfahren nach Anspruch 9, wobei der Sicherungsknoten den Primärknoten darüber benachrichtigt, dass alle Datenbankseiten empfangen worden sind.
  15. Verfahren nach Anspruch 9, wobei REDO-Transaktionen und Datenbankseiten in einem Sendepufferspeicher verschränkt werden, bevor sie an einen Sicherungsknoten gesendet werden.
  16. Verfahren nach Anspruch 9, wobei Transaktionen den Primärknoten fortlaufend belasten.
  17. Computerprogrammprodukt, um ein Datenbankabbild von einem funktionsfähigen Primärknoten in einen Sicherungsknoten in einer verteilten Datenbankumgebung zu replizieren, wobei das Computerprogrammprodukt ein von einem Computer lesbares Speichermedium aufweist, das über damit realisierten, von einem Computer lesbaren Programmcode verfügt, wobei der von einem Computer lesbare Programmcode so konfiguriert ist, dass er einen beliebigen der Verfahrensansprüche durchführt.
  18. Computerprogramm, das auf einem von einem Computer lesbaren Datenträger gespeichert ist und in den internen Speicher eines digitalen Computers geladen werden kann, wobei das Computerprogramm Teile von Software-Code aufweist, wenn das Programm auf einem Computer ausgeführt wird, um das Verfahren nach einem beliebigen der Verfahrensansprüche durchzuführen.
DE112014001873.2T 2013-06-25 2014-03-18 Replikation für Hot-Standby-Online-Datenbank Pending DE112014001873T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1311259.4 2013-06-25
GB1311259.4A GB2515501A (en) 2013-06-25 2013-06-25 Replication for on-line hot-standby database
PCT/EP2014/055431 WO2014206581A1 (en) 2013-06-25 2014-03-18 Replication for on-line hot-standby database

Publications (1)

Publication Number Publication Date
DE112014001873T5 true DE112014001873T5 (de) 2016-01-07

Family

ID=48998901

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112014001873.2T Pending DE112014001873T5 (de) 2013-06-25 2014-03-18 Replikation für Hot-Standby-Online-Datenbank

Country Status (6)

Country Link
US (1) US9798792B2 (de)
JP (1) JP6362685B2 (de)
CN (1) CN105339939B (de)
DE (1) DE112014001873T5 (de)
GB (2) GB2515501A (de)
WO (1) WO2014206581A1 (de)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2515501A (en) 2013-06-25 2014-12-31 Ibm Replication for on-line hot-standby database
US10366102B2 (en) * 2014-02-19 2019-07-30 Snowflake Inc. Resource management systems and methods
CA2980196A1 (en) * 2015-03-20 2016-09-29 Royal Bank Of Canada System and methods for message redundancy
US20160321332A1 (en) * 2015-05-01 2016-11-03 Microsoft Technology Licensing, Llc Database scaling with isolation
US10261943B2 (en) 2015-05-01 2019-04-16 Microsoft Technology Licensing, Llc Securely moving data across boundaries
CN105227683B (zh) * 2015-11-11 2018-10-19 中国建设银行股份有限公司 一种ldap集群数据同步方法及***
CN107122354B (zh) * 2016-02-24 2020-05-08 华为技术有限公司 事务执行方法、装置及***
CN107665155B (zh) * 2016-07-28 2021-07-09 华为技术有限公司 处理数据的方法和装置
CN106502835B (zh) * 2016-10-26 2018-10-16 ***股份有限公司 一种容灾备份方法及装置
US10769040B2 (en) * 2016-11-21 2020-09-08 Sap Se Logical equivalent replication with snapshot based fallback of database systems
US10795779B2 (en) * 2017-02-17 2020-10-06 Sap Se Asynchronous garbage collection in database redo log replay
US10481986B2 (en) * 2017-07-11 2019-11-19 Sap Se Automatic adoption of parallelized database garbage collection
US11157511B2 (en) * 2017-07-19 2021-10-26 Sap Se Physical replication of database
CN107368392A (zh) * 2017-07-25 2017-11-21 郑州云海信息技术有限公司 一种从数据库的重建方法、主数据库及从数据库
US11301332B2 (en) * 2017-07-31 2022-04-12 Honeywell International Inc. Automatic firmware upgrade of an embedded node
CN108446187B (zh) * 2018-03-07 2021-02-09 上海达梦数据库有限公司 数据备份方法及数据还原方法
CN110413210B (zh) * 2018-04-28 2023-05-30 伊姆西Ip控股有限责任公司 用于处理数据的方法、设备和计算机程序产品
US11334439B2 (en) 2018-08-29 2022-05-17 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US11196542B2 (en) 2018-08-29 2021-12-07 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US10901957B2 (en) * 2018-08-29 2021-01-26 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
CN110874287B (zh) * 2018-08-31 2023-05-02 阿里巴巴集团控股有限公司 数据库中数据的备份及恢复方法、装置及电子设备
CN111198782A (zh) * 2018-11-16 2020-05-26 ***通信集团辽宁有限公司 数据重分布方法、装置、设备及存储介质
US10997204B2 (en) * 2018-12-21 2021-05-04 Elasticsearch B.V. Cross cluster replication
US11341159B2 (en) 2019-08-22 2022-05-24 International Business Machines Corporation In-stream data load in a replication environment
CN110825758B (zh) * 2019-10-31 2022-11-15 ***股份有限公司 一种交易处理的方法及装置
CN111400404A (zh) * 2020-03-18 2020-07-10 中国建设银行股份有限公司 一种节点初始化方法、装置、设备及存储介质
CN111443867B (zh) * 2020-03-24 2021-08-03 腾讯科技(深圳)有限公司 一种数据存储方法、装置、设备及存储介质
US11907260B2 (en) 2020-04-19 2024-02-20 International Business Machines Corporation Compare processing using replication log-injected compare records in a replication environment
CN113934745A (zh) * 2020-06-29 2022-01-14 中兴通讯股份有限公司 数据同步处理方法、电子设备以及存储介质
WO2022094895A1 (en) * 2020-11-05 2022-05-12 Alibaba Group Holding Limited Virtual data copy supporting garbage collection in distributed file systems
CN113961150B (zh) * 2021-10-29 2024-04-02 苏州浪潮智能科技有限公司 一种分布式持久性内存文件***保持数据一致性的方法

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5170480A (en) * 1989-09-25 1992-12-08 International Business Machines Corporation Concurrently applying redo records to backup database in a log sequence using single queue server per queue at a time
US5799323A (en) * 1995-01-24 1998-08-25 Tandem Computers, Inc. Remote duplicate databased facility with triple contingency protection
US5799322A (en) * 1995-01-24 1998-08-25 Tandem Computer, Inc. System and method for stopping updates at a specified timestamp in a remote duplicate database facility
SE510050C2 (sv) * 1997-07-21 1999-04-12 Ericsson Telefon Ab L M Metod för insamlande av logginformation vid förändring av databas
US5951695A (en) 1997-07-25 1999-09-14 Hewlett-Packard Company Fast database failover
US5884328A (en) * 1997-08-29 1999-03-16 Tandem Computers, Inc. System and method for sychronizing a large database and its replica
US20030142955A1 (en) * 1997-09-12 2003-07-31 Aki Hashizume Apparatus for correcting an abnormality of video signal of a video system, its method, and recording medium storing the method
US6732123B1 (en) * 1998-02-23 2004-05-04 International Business Machines Corporation Database recovery to any point in time in an online environment utilizing disaster recovery technology
US7260590B1 (en) * 2000-12-06 2007-08-21 Cisco Technology, Inc. Streamed database archival process with background synchronization
US7305421B2 (en) 2001-07-16 2007-12-04 Sap Ag Parallelized redo-only logging and recovery for highly available main memory database systems
US7039663B1 (en) * 2002-04-19 2006-05-02 Network Appliance, Inc. System and method for checkpointing and restarting an asynchronous transfer of data between a source and destination snapshot
US8121978B2 (en) * 2002-11-15 2012-02-21 Sybase, Inc. Database system providing improved methods for data replication
US8095511B2 (en) 2003-06-30 2012-01-10 Microsoft Corporation Database data recovery system and method
US8108429B2 (en) * 2004-05-07 2012-01-31 Quest Software, Inc. System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services
US7587429B2 (en) 2004-05-24 2009-09-08 Solid Information Technology Oy Method for checkpointing a main-memory database
JP4484618B2 (ja) * 2004-07-30 2010-06-16 株式会社日立製作所 ディザスタリカバリシステム、プログラム及びデータの複製方法
US7529783B2 (en) * 2004-12-22 2009-05-05 International Business Machines Corporation Log shipping data replication with parallel log writing and log shipping at the primary site
US7519859B2 (en) 2005-08-30 2009-04-14 International Business Machines Corporation Fault recovery for transaction server
US20070220059A1 (en) * 2006-03-20 2007-09-20 Manyi Lu Data processing node
US9098347B2 (en) * 2006-12-21 2015-08-04 Vmware Implementation of virtual machine operations using storage system functionality
US7711712B2 (en) * 2007-03-12 2010-05-04 Hitachi, Ltd. System and method for managing consistency among volumes based on application information
US8300917B2 (en) * 2007-11-29 2012-10-30 Wells Fargo Bank N.A. Remote deposit capture for the gaming industry
US7974943B2 (en) 2008-10-30 2011-07-05 Hewlett-Packard Development Company, L.P. Building a synchronized target database
CN101741894B (zh) * 2008-11-26 2012-09-19 ***通信集团公司 一种分布式***的升级方法、升级调度节点及***
US9230002B2 (en) * 2009-01-30 2016-01-05 Oracle International Corporation High performant information sharing and replication for single-publisher and multiple-subscriber configuration
CN101594254B (zh) * 2009-06-30 2011-04-27 中国运载火箭技术研究院 一种基于代理技术的网格计算容错***及方法
US8627135B2 (en) * 2010-08-14 2014-01-07 Teradata Us, Inc. Management of a distributed computing system through replication of write ahead logs
US8589361B2 (en) * 2010-08-30 2013-11-19 Oracle International Corporation Reduced disk space standby
US10430298B2 (en) 2010-10-28 2019-10-01 Microsoft Technology Licensing, Llc Versatile in-memory database recovery using logical log records
US8527546B2 (en) 2010-11-25 2013-09-03 International Business Machines Corporation Generating a checkpoint image for use with an in-memory database
US8868512B2 (en) 2011-01-14 2014-10-21 Sap Se Logging scheme for column-oriented in-memory databases
US9495398B2 (en) 2011-02-18 2016-11-15 International Business Machines Corporation Index for hybrid database
US9155320B2 (en) 2011-07-06 2015-10-13 International Business Machines Corporation Prefix-based leaf node storage for database system
GB2502098A (en) 2012-05-16 2013-11-20 Ibm Performance analysis of a hypothetical database
GB2515501A (en) 2013-06-25 2014-12-31 Ibm Replication for on-line hot-standby database
US9424261B2 (en) * 2014-04-02 2016-08-23 Oracle International Corporation Techniques to take clean database file snapshot in an online database

Also Published As

Publication number Publication date
WO2014206581A1 (en) 2014-12-31
JP6362685B2 (ja) 2018-07-25
GB201311259D0 (en) 2013-08-14
US20150339366A1 (en) 2015-11-26
GB2530958A (en) 2016-04-06
GB2515501A (en) 2014-12-31
GB2530958B (en) 2018-04-25
GB201601176D0 (en) 2016-03-09
JP2016522514A (ja) 2016-07-28
CN105339939B (zh) 2019-01-08
CN105339939A (zh) 2016-02-17
US9798792B2 (en) 2017-10-24

Similar Documents

Publication Publication Date Title
DE112014001873T5 (de) Replikation für Hot-Standby-Online-Datenbank
DE112010004947B4 (de) Wiederherstellung einer vollständigen Systemsicherung und inkrementeller Sicherungen unter Verwendung von mehreren gleichzeitigen Datenströmen von Einheiten
DE69126066T2 (de) Verfahren und Gerät zur Optimierung des Logbuchaufhebungsgebrauchs
DE69126067T2 (de) Verfahren und Gerät zur Verwaltung von Zustandsidentifizierern zur effizienten Wiederherstellung
DE60317383T2 (de) Datenwiederherstellungsvorrichtung unter Verwendung von Journaldaten und Identifikationsinformation
DE3853452T2 (de) Mehrfachverarbeitung mit hoher Verfügbarkeit.
DE68924119T2 (de) Verfahren und Vorrichtung zum Wiederanlauf nach einem Fehler in einem digitalen Rechnersystem.
DE602004005344T2 (de) Verfahren, system und programm zur handhabung eines failover zu einem fernspeicherort
DE60312746T2 (de) Wiederherstellung nach fehlern in datenverarbeitungsanlagen
DE3786956T2 (de) Verwaltung von registrierungsdaten in einem transaktionsorientierten System.
DE69911930T2 (de) Hochverfügbare dateiprozessoren
DE112011100623B4 (de) Read-Other-Protokoll zur Aufrechterhaltung der Paritätskohärenz in einem Writeback-Datenspeichersystem mit verteilter Redundanz
DE602005004166T2 (de) Vorrichtung, system und verfahren zur reinitialisierung einer serialisierung von dateisystemen
DE602005002532T2 (de) Cluster-datenbank mit ferndatenspiegelung
DE112011104471T5 (de) Verfahren zur Failover-Verwaltung von virtuellen Maschinen und System zum Unterstützen desselben
DE102006009617B4 (de) Informationssystem und Verfahren zum Steuern von mehreren Hot Plug Vorgängen
DE102015107990A1 (de) Verfahren und Vorrichtung zur dynamischen Knotenreparatur in einer Mehrfachknotenumgebung
DE112012001660T5 (de) Speicher-Checkpointing in einem System gespiegelter virtueller Maschinen
DE102014117465A1 (de) Unterstützter kohärenter gemeinsamer Speicher
CN109643310B (zh) 用于数据库中数据重分布的***和方法
DE102019111068A1 (de) Datenspeichersystem mit LUN-Archivierung in die Cloud unter Verwendung einer Volume-to-Object(Volumen-zu-Objekt)-Umsetzung
DE102013215009A1 (de) Verfahren und System zur Optimierung der Datenübertragung
DE112014002275T5 (de) Datenbankverwaltungssystem und -verfahren
DE112012001761T5 (de) Hochverfügbarkeit von virtuellen Maschinen
DE602004007925T2 (de) Verwalten einer beziehung zwischen einem zielvolumen und einem quellenvolumen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0017300000

Ipc: G06F0016000000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0016000000

Ipc: G06F0016270000

R016 Response to examination communication
R084 Declaration of willingness to licence