DE60018872T2 - System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen - Google Patents

System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen Download PDF

Info

Publication number
DE60018872T2
DE60018872T2 DE60018872T DE60018872T DE60018872T2 DE 60018872 T2 DE60018872 T2 DE 60018872T2 DE 60018872 T DE60018872 T DE 60018872T DE 60018872 T DE60018872 T DE 60018872T DE 60018872 T2 DE60018872 T2 DE 60018872T2
Authority
DE
Germany
Prior art keywords
transaction
image track
image
file
instructions
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.)
Expired - Lifetime
Application number
DE60018872T
Other languages
English (en)
Other versions
DE60018872D1 (de
Inventor
Malcolm Los Gatos Mosher
Simon Campbell Whitworth. P.
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.)
Compaq Computer Corp
Original Assignee
Compaq Computer 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 Compaq Computer Corp filed Critical Compaq Computer Corp
Application granted granted Critical
Publication of DE60018872D1 publication Critical patent/DE60018872D1/de
Publication of DE60018872T2 publication Critical patent/DE60018872T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2069—Management of state, configuration or failover
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2071—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using a plurality of controllers
    • G06F11/2074—Asynchronous techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2082—Data synchronisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2089—Redundant storage control functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
    • G06F11/1662—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit the resynchronized component or unit being a persistent storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2066—Optimisation of the communication load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/855—Details of asynchronous mirroring using a journal to transfer not-yet-mirrored changes
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99953—Recoverability
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99955—Archiving or backup

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

  • Die vorliegende Erfindung betrifft allgemein Datenbankverwaltungssysteme mit einer Hauptdatenbankanlage und einer duplizierten oder Ersatzdatenbankanlage, und besonders ein System und ein Verfahren für die Synchronisation einer Ersatzdatenbank mit einer Hauptdatenbank, während Anwendungen fortfahren, die Hauptdatenbank aktiv zu verändern.
  • Hintergrund der Erfindung
  • Die vorliegenden Erfindung ist eine Verbesserung der Tandem-"remote data facility"(RDF)-Technologie, die in den U.S. Patenten Nr. 5,799,322 und 5,799,323 offengelegt ist, welche beide am 25. August 1998 herausgegeben wurden.
  • Die Tandem-RDF-Technologie nach dem Stand der Technik wurde im Lauf der Zeit einer Reihe von Veränderungen unterzogen, um die Bandbreite des Systems zu erhöhen, wobei die Bandbreite durch die Spitzenzahl von Transaktionen pro Sekunde angezeigt wird, welche auf dem Hauptsystem durchgeführt und auf dem Ersatzsystem nachvollzogen werden können. Die vorliegende Erfindung stellt eine Menge von neuen Technologien dar, um so eine weitere große Erhöhung der Bandbreite zu erreichen. Einige der durch die vorliegende Erfindung für die Erhöhung der Bandbreite verwendeten Techniken verletzen grundlegende Annahmen der Systeme nach dem Stand der Technik und verlangen sowohl einen Neuentwurf der Mechanismen nach dem Stand der Technik als auch einige vollständig neue Mechanismen, um sicherzustellen, dass das Ersatzsystem eine "weiche Synchronisation" mit dem Hauptsystem während des normalen Betriebs beibehält, und um ebenfalls sicherzustellen, dass das Ersatzsystem zu einem vollständig konsistenten internen Zustand gebracht werden kann, wann immer das Ersatzsystem eine Übernahmeoperation ausführen und als Hauptsystem verwendet werden muss.
  • Das U.S. Patent Nr. 5,799,322 legt ein Verfahren und System für den Betrieb eines Ersatzsystems offen, um so Datenbankaktualisierungen nachzuführen, die auf einem Hauptsystem durchgeführt werden. Das System hat eine Datenbank, Anwendungsprogramme, welche diese Datenbank verändern, und einen Transaktionsmanager, der Prüfsätze in lokalen Prüfabbildspuren speichert, welche die Veränderungen reflektieren. Eine Vielzahl von Ersatzsystemen wird verwendet, um "dreifachen Ausfallschutz" vorzusehen. Eine Dateilöschprozedur wird verwendet, um nicht mehr benötigte Abbildspurdateien zu löschen.
  • Nach der vorliegenden Erfindung wird entsprechend Anspruch 1 ein Betriebsverfahren eines Ersatzsystems vorgesehen, um so Datenbankaktualisierungen nachzuführen, die auf einem Hauptsystem durchgeführt wurden, und das Verfahren umfasst die folgenden Schritte:
    • Empfangen eines Stroms von Prüfsätzen von dem Hauptsystem, wobei die Prüfsätze umfassen: Aktualisierungsprüfsätze, die Datenbankaktualisierungen bezeichnen, welche durch Transaktionen erzeugt werden, die auf dem Hauptsystem ausgeführt werden, Transaktionszustandssätze und Zeitintervallkontrollsätze, wobei mindestens eine Untermenge der Transaktionszustandssätze ein Durchführungs-/Stornierungsergebnis für eine spezifizierte Transaktion bezeichnet; wobei jeder Aktualisierungsprüfsatz und jeder Transaktionszustandssatz einen Transaktionsidentifikator umfasst, der eine korrespondierende Transaktion auf dem Hauptsystem identifiziert;
    • Speichern der Aktualisierungsprüfsätze in einer oder mehrerer Abbildspuren;
    • Untersuchen der empfangenen Transaktionszustandssätze in einer vordefinierten chronologischen Reihenfolge und für jede Abbildspur Erzeugen einer gegenwärtigen Transaktionstabelle, welche einen Bereich von Transaktionsidentifikatoren für Transaktionen repräsentiert, für die es mindestens einen Transaktionszustandssatz zwischen aufeinander folgenden Zeitintervallkontrollsätzen in dem Strom der Prüfsätze gibt;
    • Sichern der gegenwärtigen Transaktionstabelle als eine vorangehende Transaktionstabelle und Erzeugen einer neuen gegenwärtigen Transaktionstabelle immer dann, wenn ein Zeitintervallkontrollsatz empfangen wird;
    • Speichern einer jeden der Abbildspuren als eine Folge von Abbildspurdateien einschließlich dem Generieren einer neuen Abbildspur jedesmal dann, wenn eine vorangehende Abbildspurdatei einen vordefinierten Zustand erreicht, und dem Speichern einer Kopie der vorangehenden Transaktionstabelle in jeder neuen Abbildspurdatei zu dem Zeitpunkt, an dem die neue Abbildspurdatei erzeugt wird;
    • für jede Abbildspur: Zugreifen auf die und Verarbeiten der Prüfsätze in der Reihenfolge der Abbildspurdateien für diese Abbildspur; und
    • periodisches Ausführen einer Dateilöschprozedur für das Löschen von nicht länger benötigten Abbildspurdateien, welches umfasst:
    • Identifizieren einer ältesten Transaktionstabellenkopie aus einer Menge von Transaktionstabellenkopien, deren jede die Transaktionstabellenkopie in der letzten Abbildspurdatei umfasst, auf die für jede der Abbildspuren zugegriffen wird;
    • Zugreifen auf eine Abbildspurdatei für eine der Abbildspuren;
    • Vergleichen eines ersten Satzes neuester Transaktionsidentifikatoren in der Transaktionstabellenkopie in der zugegriffenen Abbildspurdatei mit einem zweiten Satz ältester Transaktionsidentifikatoren in der identifizierten ältesten Transaktionstabellenkopie und bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  • Die vorliegende Erfindung sieht auch ein Computerprogrammprodukt nach Anspruch 5 vor für die Verwendung in einem Betriebsverfahren für ein Ersatzsystem, um so die auf einem Hauptsystem durchgeführten Datenbankänderungen zu verdoppeln, und das Computerprogrammprodukt umfasst:
    • einen Empfängermodul, der einen Strom von Prüfsätzen in einer oder mehreren Abbildspuren empfängt und speichert, welche von dem Hauptsystem empfangen werden, wobei die Prüfsätze umfassen: Aktualisierungsprüfsätze, die Datenbankaktualisierungen bezeichnen, welche durch Transaktionen erzeugt werden, die auf dem Hauptsystem ausgeführt werden, Transaktionszustandssätze und Zeitintervallkontrollsätze, wobei mindestens eine Untermenge der Transaktionszustandssätze ein Durchführungs-/Stornierungsergebnis für eine spezifizierte Transaktion bezeichnet; wobei jeder Aktualisierungsprüfsatz und jeder Transaktionszustandssatz einen Transaktionsidentifikator umfasst, der eine korrespondierende Transaktion auf dem Primärsystem identifiziert;
    • der Empfängermodul die Aktualisierungsprüfsätze in einer oder mehrerer Abbildspuren speichert;
    • der Empfängermodul Instruktionen umfasst für: das Untersuchen der empfangenen Transaktionszustandssätze in einer vordefinierten chronologischen Reihenfolge und für jede Abbildspur Instruktionen für das Erzeugen einer gegenwärtigen Transaktionstabelle, welche einen Bereich von Transaktionsidentifikatoren für Transaktionen repräsentiert, für die es mindestens einen Transaktionszustandssatz zwischen aufeinanderfolgenden Zeitintervallkontrollsätzen in dem Strom der Prüfsätze gibt; das Sichern der gegenwärtigen Transaktionstabelle als eine vorangehende Transaktionstabelle und Erzeugen einer neuen gegenwärtigen Transaktionstabelle immer dann, wenn ein Zeitintervallkontrollsatz empfangen wird; das Speichern einer jeden der Abbildspuren (136, 138) als eine Sequenz von Abbildspurdateien einschließlich dem Generieren einer neuen Abbildspur jedesmal dann, wenn eine vorangehende Abbildspurdatei einen vordefinierten Zustand erreicht, und dem Speichern einer Kopie der vorangehenden Transaktionstabelle in jeder neuen Abbildspurdatei zu dem Zeitpunkt, an dem die neue Abbildspurdatei erzeugt wird;
    • mindestens einen Aktualisierungsmodul, der die durch die Aktualisierungsprüfsätze bezeichneten Datenbankaktualisierungen auf die Ersatzdatenbank in der Reihenfolge sequen tiell anwendet, in der die Aktualisierungsprüfsätze in den Abbildspurdateien gespeichert sind; und
    • eine Dateilöschprozedur für das Löschen von nicht länger benötigten Abbildspurdateien, wobei die Dateilöschprozedur Instruktionen umfasst für das: Identifizieren einer ältesten Transaktionstabellenkopie aus einer Menge von Transaktionstabellenkopien, deren jede die Transaktionstabellenkopie in der letzten Abbildspurdatei umfasst, auf die für jede der Abbildspuren zugegriffen wird; Zugreifen auf eine Abbildspurdatei für eine der Abbildspuren; Vergleichen eines ersten Satzes neuester Transaktionsidentifikatoren in der Transaktionstabellenkopie in der zugegriffenen Abbildspurdatei mit einem zweiten Satz ältester Transaktionsidentifikatoren in der identifizierten ältesten Transaktionstabellenkopie und bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  • Die vorliegende Erfindung sieht auch das Computerprogrammprodukt von Anspruch 7 vor, wobei die Dateilöschprozedur umfasst:
    • für jede Abbildspur, für die es mehr als eine vordefinierte (RetainCount) Anzahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind:
    • Instruktionen für das Zugreifen auf die Abbildspurdateien in chronologischer Reihenfolge mit Ausnehmen der RetainCount Abbildspurdateien, die am wenigsten weit zurückliegen;
    • für jede zugegriffene Abbildspur: Instruktionen für das Vergleichen des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren;
    • Instruktionen für das bedingte Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz; und
    • Stoppen des Zugriffs auf die Abbildspurdateien für die Abbildspur, wenn einer der Transaktionsidentifikatoren in dem ersten Satz nicht älter als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz ist.
  • Nach der vorliegende Erfindung wird ferner ein Ersatzcomputersystem nach dem unabhängigen Anspruch 9 vorgesehen.
  • Zusammenfassend umfasst die vorliegende Erfindung ein verteiltes Computerdatenbanksystem mit einem lokalen Computersystem und einem fernen Computersystem. Das lokale Computersystem hat eine lokale Datenbank, die auf einem lokalen Speichermedium gespeichert ist, Anwendungsprogramme, welche die lokale Datenbank verändern, und einen Transaktionsmanager, der Prüfsätze in einer lokalen Abbildspur speichert, welche diese Anwendungsprogrammveränderungen der lokalen Datenbank wie auch Durchführungs-/Stornierungssätze reflektiert, die bezeichnen, welche der Transaktionen, die jene Datenbankveränderungen ausmachen, durchgeführt und welche storniert wurden. Jeder Prüfsatz hat eine zugeordnete Prüfspurposition in der lokalen Abbildspur, die sonst als eine MAT-(Hauptprüfspur)-Position bezeichnet wird.
  • Das ferne Computersystem, das von dem lokalen Computersystem entfernt aufgestellt ist, hat eine Ersatzdatenbank, die auf einem fernen Speichermedium gespeichert ist, welche dem fernen Computersystem zugeordnet ist.
  • Eine ferne Datenverarbeitungsverdoppelungsanlage (RDF, remote duplicate data facility) liegt teilweise in dem lokalen Computersystem und teilweise in dem fernen Computersystem für die Beibehaltung virtueller Synchronisation der Ersatzdatenbank mit der lokalen Datenbank. Die RDF umfasst einen Extraktorprozess, der auf dem lokalen Computersystem ausgeführt wird, und einen Empfängerprozess und einen oder mehrere Aktualisierungsprozesse, die auf dem fernen Computersystem ausgeführt weiden.
  • Der Extraktorprozess, der auf dem lokalen Computersystem ausgeführt wird, zieht Prüfsätze aus der lokalen Abbildspur heraus. Er hat eine Vielzahl von Nachrichtenpuffern (vier in der bevorzugten Ausführungsform) für das gemeinsame Puffern von Gruppen von herausgezogenen Prüfsätzen und überträgt jeden Nachrichtenpuffer an das ferne Computersystem, wenn der Puffer voll ist oder ein Zeitglied abgelaufen ist.
  • Der Empfängerprozess, der auf dem fernen Computersystem abläuft, empfängt Nachrichtenpuffer, die von dem Extraktorprozess übertragen werden, und verteilt die Prüfsätze in einem empfangenen Nachrichtenpuffer auf eine oder mehrere Abbildspuren in dem fernen Computersystem. Die Prüfsätze umfassen Aktualisierungsprüfsätze und Rückabwicklungsprüfsätze, welche Datenbankaktualisierungen und Datenbankrückabwicklungen bezeichnen, die durch die auf dem Hauptsystem ausgeführten Transaktionen erzeugt werden.
  • Der Empfängerprozess speichert die Veränderungsprüfsätze in einer oder mehrerer Abbildspuren und speichert jede Abbildspur in einer Folge von Abbildspurdateien. Der Empfängerprozess speichert auch eine Transaktionstabelle in jeder Abbildspurdatei, welche einen Bereich von Transaktionsidentifikatoren für Transaktionen repräsentiert, die potentiell in dem Hauptsystem zum Zeitpunkt anhängig sind, zu dem der erste Prüfsatz in der Prüfspurdatei durch das Hauptsystem erzeugt wurde.
  • Für jede Abbildspur gibt es einen Aktualisiererprozess, der auf einen Ersatzdatenbankdatenträger die Datenbankaktualisierungen und -stornierungen einbringt, die durch die Aktualisierungsprüfsätze und Rückabwicklungsprüfsätze in der Abbildspur bezeichnet werden. Die Aktualisierungsprüfsätze und Rückabwicklungsprüfsätze werden auf den Ersatzdatenbankdatenträger in derselben Reihenfolge eingebracht, in der sie in der Abbildspur gespeichert sind, ohne Rücksicht darauf, ob die korrespondierenden Transaktionen in dem Hauptsystem durchgeführt oder rückabgewickelt wurden.
  • Das ferne Computersystem führt eine Dateilöschprozedur periodisch aus, welche die älteste Transaktionstabelle unter den Transaktionstabellen in der letzten Abbildspurdatei identifiziert, auf die für jede der Abbildspuren zugegriffen wird. Dann greift die Dateilöschprozedur für jede Abbildspur auf die Abbildspurdatei in einer vordefinierten, chronologischen Reihenfolge zu und vergleicht für jede zugegriffene Abbildspurdatei eine erste Menge neuester Transaktionsidentifikatoren in der Transaktionstabelle der Datei mit einer zweiten Menge ältester Transaktionsidentifikatoren in der identifizierten ältesten Transaktionstabelle. Die Prozedur löscht die zugegriffene Abbildspurdatei nur dann, wenn alle Transaktionsidentifikatoren in der erste Menge älter als korrespondierende Transaktionsidentifikatoren in der zweiten Menge sind.
  • Kurze Beschreibung der Zeichnungen
  • Zusätzliche Ziele und Merkmale der Erfindung werden leichter offenkundig werden aus der folgenden detaillierten Beschreibung, wenn sie in Verbindung mit den Zeichnungen genommen wird, in denen:
  • 1 ein Blockdiagramm eines Datenbankmanagementsystems mit einer fernen Datenbankverdoppelungsanlage nach dem Stand der Technik ist.
  • 2 eine konzeptionelle Darstellung der Prüfpunktprozedur, Kontextsicherungsprozedur und der Übernahmeprozedur bei Ausfall ist, die von dem in 1 gezeigten System verwendet werden.
  • 3 eine schematische Darstellung der Konfigurationsdatei ist, die verwendet wird, um die Konfiguration eines jeden RDF-Systems in einer bevorzugten Ausführungsform zu definieren.
  • 4 ein Blockdiagramm eines Datenbankmanagementsystems mit einer Vielzahl paralleler, ferner Datenbankverdoppelungsanlagen ist.
  • 5A und 5B Datenstrukturen abbilden, die vom Extraktorprozess in einer bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden.
  • 6A, 6B, 6C, 6D und 6E Flussdiagramme von Prozeduren sind, die von dem Extraktorprozess in einer bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden.
  • 7A ein Blockdiagramm eines Empfängerkontextsatzes ist. 7B ist ein Blockdiagramm einer Menge von Abbildspurkontextsätzen. 7C, 7D, 7E, 7F, 7G und 7H sind Blockdiagramme von Datenstrukturen, die von dem Empfängerprozess und dem Löscherprozess in einer bevorzugten Ausführungsform der vorliegenden Efindung verwendet werden.
  • 8A, 8B, 8C, 8D, 8E, 8F, 8G, 8H, 8I, 8J und 8K Flussdiagramme von Prozeduren sind, die von dem Empfängerprozess in einer bevorzugten Ausführungsform der vorliegenden Erfindung ausgeführt werden.
  • 9 ein Blockdiagramm von Datenstrukturen ist, die im Hauptspeicher gespeichert sind und von jedem Aktualisiererprozess in einer bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden.
  • 10A, 10B, 10C, 10D und 10F Flussdiagramme von Prozeduren sind, die von den Aktualisiererprozessen in einer bevorzugten Ausführungsform der vorliegenden Erfindung ausgeführt werden.
  • 11 ein Flussdiagramm von Aktionen abbildet, die durch ein Ersatzsystem durchgeführt werden, wenn eine RDF-Übernahme durchgeführt wird, um so das Ersatzsystem auf die Übernahme vorzubereiten und als das Hauptsystem zu betreiben.
  • 12 ein Flussdiagramm der Prozedur abbildet für die Erzeugung einer Rückabwicklungsliste von Transaktionen, deren Endzustand unbekannt ist.
  • 13 eine Transaktionszustandstabelle abbildet, die in einer bevorzugten Ausführungsform verwendet wird.
  • 14A und 14B ein Flussdiagramm der Aktualisiererrückabwicklungsprozedur abbildet für Aktualisierungen für unvollständige Transaktionen.
  • 15 ein Flussdiagramm einer Prozedur abbildet für das periodische Löschen von Abbildspurdateien, die nicht länger von dem Ersatzsystem benötigt werden.
  • Beschreibung der bevorzugten Ausführungsformen
  • Überblick über das RDF-System
  • 1 repräsentiert die Basisarchitektur des RDF-Systems von Tandem Computer, während 2 die Beziehung zwischen einigen der RDF-Prozesse und ihrer jeweiligen lokalen Ersatzprozesse zeigt. Im Transaktionsverarbeitungssystem von Tandem hat jeder Prozess einen jeweiligen lokalen Ersatzprozess, der automatisch aufgerufen wird, wenn der Hauptprozess versagt. Jeder lokaler Ersatzprozess liegt auf einer unterschiedlichen CPU als sein jeweiliger Hauptprozess und bietet eine erste Stufe von Ausfallschutz. Ein Hauptzweck des RDF-(ferne Datenverarbeitungsanlage)-Systems ist, Ausfälle in dem Hauptsystem aufzufangen, die nicht durch die Verwendung lokaler Ersatzprozesse (und anderer Hilfsmaßnahmen) gelöst werden können, wie etwa einen vollständigen Ausfall des Hauptsystems.
  • Das in 1 gezeigte Computersystem 100 hat eine Transaktionsmanagementeinrichtung 102, die Prüfsatzeinträge auf eine Hauptprüfspur (MAT, master audit trail schreibt. Die Prüfsatzeinträge bezeichnen Veränderungen, die zu "geprüften Dateien" auf durch "RDF geschützte Datenträger" 106 einer Hauptdatenbank 108 auf einem Hauptsystem 110 gemacht werden. Alle durch RDF geschützte Datenträger sind konfiguriert, alle Transaktionsprüfsätze auf die MAT 104 zu schreiben.
  • Das RDF-System 120 umfasst Prozesse sowohl auf den lokalen Prozessoren 110, 160 als auch den fernen Ersatzprozessoren 122, 162. Die RDF 120 handhabt eine verdoppelte Datenbank 124 (auch Ersatzdatenbank genannt) durch Verfolgen von Veränderungen, die den "geprüften Dateien" auf durch "RDF geschützten Datenträgern" 106 des Hauptsystems zugefügt werden, und durch Aufbringen jener Veränderungen auf korrespondierende Ersatzdatenträger 126 auf dem Ersatzcomputersystem 122. Eine "geprüfte Datei" (manchmal eine "RDF-geprüfte Datei genannt) ist eine Datei, für die RDF-Schutz freigegeben wurde, und ein durch "RDF geschütztes Datenträger" ist eine logische oder physikalische Einheit der Plattenspeicherung, für die RDF-Schutz freigegeben wurde.
  • Auf einem Hauptsystem 110 liest ein RDF-Extraktorprozess 130 die Hauptprüfspur (MAT) 104, welche ein Journal ist, das von der Transaktionsmanagementeinrichtung (TM/MP) über alle Datenbanktransaktionen geführt wird, die geprüfte Dateien betrifft, und sendet alle logischen Prüfsätze, die den durch RDF geschützten Datenträgern zugeordnet sind, an einen RDF-Empfängerprozess 132 auf einem Ersatzcomputersystem.
  • Die MAT 104 wird als eine Folge von Dateien mit sequentiell numerierten Dateinamen gespeichert. Die MAT-Dateien sind alle von einer festen Größe (für jedes System konfigurierbar), wie etwa 64 MByte. Die TMF 102 und der Extraktorprozess 130 sind beide programmiert, von einer MAT-Datei zur nächsten automatisch (und voneinander unabhängig) fortzuschreiten.
  • Extraktorprozess - Überblick
  • Mit Bezug auf 5A fügt der Extraktorprozess 130 jedem Prüfsatz, den er aus der Hauptprüfspur 104 herauszieht und der einem geschützten Datenträger zugeordnet ist, einen MAT-Positionswert 288 und einen Zeitstempel 290 hinzu. Der MAT-Positionswert ist die Position in der MAT des extrahierten Prüfsatzes. Der hinzugefügte Zeitstempel ist als der RTD-Zeitstempel bekannt und ist der Zeitstempel der letzten Transaktion, die vor der Erzeugung des Prüfsatzes in der MAT 104 abgeschlossen wurde. Der sich ergebende Satz wird ein Prüfabbildsatz oder Abbildsatz 284 genannt. Der Extraktorprozess speichert jeden Prüfabbildsatz in Nachrichtenpuffer 242, deren jeder in der bevorzugten Ausführungsform eine Größe von etwa 28 KByte hat.
  • Der Extraktorprozess verwendet zwei bis acht Nachrichtenpuffer 242, wobei vier Nachrichtenpuffer eine typische Konfiguration darstellen. Nach dem Füllen und Übertragen eines Nachrichtenpuffers 242 an dem Empfängerprozess über einen Kommunikationskanal 144 (1) wartet der Extraktorprozess 130 nicht auf eine Bestätigungsantwortnachricht von dem Empfängerprozess 132. Statt dessen fährt er mit der Verarbeitung von Prüfsätzen in der MAT 104 fort, solange ein anderer Nachrichtenpuffer verfügbar ist, und speichert Prüf abbildsätze in den nächsten verfügbaren Nachrichtenpuffer 242. Jeder Nachrichtenpuffer wird nicht verfügbar gemacht, nachdem er zum Empfängerprozess 132 übertragen wird, bis eine korrespondierende Bestätigungsantwortnachricht von dem Empfängerprozess 132 empfangen worden ist, wobei der Nachrichtenpuffer 142 zu diesem Zeitpunkt für die Verwendung durch den Extraktorprozess 130 wieder verfügbar wird.
  • Der Extraktorprozess 130 führt eine einzige Prüfpunktoperation während des Starts des Extraktorprozesses durch, und dieser Prüfpunkt 158 sendet nur einen Übernahmeort an den Ersatzextraktorprozess 150 (siehe 2). Auch speichert er nicht dauerhaft einen Kontextsatz. Statt dessen verlässt sich der Extraktorprozess 130 auf Information, die er von dem Empfängerprozess 132 empfängt, wenn RDF entweder gestartet oder erneut gestartet wird, wie in größerem Detail im Folgenden erläutert wird, wie auch während eines RDF-Starts.
  • Im Gegensatz zu vorhergehenden Verwirklichungen sendet der Extraktorprozess in der vorliegenden Erfindung an das Ersatzsystem alle logischen Prüfsätze für die geschützten Datenträger, einschließlich Aktualisierungsprüfsätze, die Veränderungen repräsentieren, welche durch die Transaktionen an den Datenbanksätzen gemacht werden, und Rückabwicklungsprüfsätze (auch Stornierungsprüfsätze genannt) für abgebrochene Transaktionen. Für Aktualisierungen und Stornierungen speichert der Extraktorprozess sowohl die Vorher-Abbilder als auch die Nachher-Abbilder des aktualisierten Datenbanksatzes in den Abbildsätzen, die an das Ersatzsystem gesendet werden, um zu ermöglichen, dass diese Operationen von den Aktualisierern 134 sowohl wieder ausgeführt als auch dann rückabgewickelt werden können.
  • Der Extraktorprozess 130 sendet auch alle Transaktionszustandssätze und TMP-Kontrollpunktsätze an das Ersatzsystem. Es gibt fünf Typen von Transaktionszustandssätzen: aktiv, vorbereitet, verwertend, durchgeführt und verworfen. TMP-Kontrollpunktsätze bezeichnen Grenzen von Transaktionsrechnungsintervallen (Kontrollpunktintervalle genannt) in dem Hauptsystem. Es wird garantiert, dass jede Transaktion mindestens einen Transaktionszustandssatz während jedes Kontrollpunktintervalls erzeugt, in dem sie aktiv (d.h. lebend) ist, außer möglicher Weise während des Kontrollpunktintervalls, in dem die Transaktion beginnt.
  • Diese Transaktionszustandssätze und TMP-Kontrollpunktsätze und ihre Verarbeitung durch das RDF-System wird im Folgenden in größerem Detail erläutert.
  • Empfängerprozess - Überblick
  • Der Empfängerprozess 132 bestätigt sofort jeden empfangenen Nachrichtenpuffer. Keine Verarbeitung des Nachrichtenpuffers wird durchgeführt, bevor die Bestätigung gesendet worden ist. Das RDF-System bietet enge Synchronisation des Extraktorprozesses und des Empfängerprozesses, und liefert automatische Resynchronisation, wann immer ein Neustart- oder Restartzustand auftritt. Z.B. werden sich die zwei Prozesse resynchronisieren, wann immer einer der Prozesse wieder gestartet wird oder einen Hauptprozessausfall hat, und wann immer der Empfängerprozess Prüfsätze von dem Extraktorprozess empfängt, die nicht in Reihenfolge sind.
  • Der Empfängerprozess 132 sortiert empfangene Prüfsätze derart, dass (A) Transaktionszustandssätze einschließlich Durchführungssätze/Stornierungssätze und Kontrollpunktsätze nur in der Hauptabbildspur 136 und (B) jeder Datenbankaktualisierungsprüfsatz oder Datenbankrückabwicklungsprüfsatz in nur eine Abbildspur 138 abgelegt wird, die ausschließlich mit dem Aktualisiererprozess 134 korrespondiert, der diesen Prüfsatz verwenden wird, um die auf dem Ersatzdatenträger 126 gespeicherten Daten aktualisieren wird.
  • Beim Sortieren und Speichern der empfangenen Prüfsätze bestimmt der Empfängerprozess 132 die älteste und die neueste Transaktion, die während einer jeden TMP-Kontrollpunktperiode für jeden Prozessor eines jeden Knotens des Hauptsystems aktiv ist. Diese Information über "aktive Transaktionen" wird ebenfalls in den Prüfabbildspuren gespeichert, welche von den Aktualisierern verwendet wird. Diese Information über "aktive Transaktionen" wird verwendet, um effizient Abbildspuren zu identifizieren, die gelöscht werden können, weil sie nicht länger von dem System benötigt werden.
  • Wann immer der Empfängerprozess einen speziellen "StopUpdaters"-Prüfsatz empfängt, kopiert er diesen Satz in alle Abbildspuren. Der StopUpdaters-Prüfsatz, der auf dem Hauptsystem 110 durch spezielle "onlineDDL"-Prozeduren produziert wird, bewirkt, dass jeder Aktualisierer 134 stoppt. Jeder Aktualisierer schreibt eine Nachricht in das Journal, die an zeigt, dass er angehalten hat, weil er einen bestimmten StopUpdaters-Prüfsatz gelesen hat. Wenn alle Aktualisierer als Reaktion auf denselben StopUpdaters-Prüfsatz angehalten worden sind, sollte der Bediener des RDF (A) dieselbe DDL-Prozedur auf dem fernen Ersatzsystem durchführen wie durch die "online DDL"-Prozedur auf dem Hauptsystem durchgeführt wurde, und dann (B) die Aktualisierer wieder starten. Diese Prozedur wird verwendet, um eine kontinuierliche virtuelle Synchronisation der lokalen und fernen Datenbanken sicherzustellen, wenn "online DDL"-Prozeduren verwendet werden, um Datenbankobjekte auf dem Hauptsystem mit minimaler Unterbrechung von Benutzerzugriffen auf die restrukturierten Datenbankobjekte zu restrukturieren.
  • Der Empfängerprozess führt eine einzige Prüfpunktoperation während des Starts des Empfängerprozesses durch, und dieser Prüfpunkt 164 sendet nur einen Übernahmeort an den Ersatzempfängerprozess 152 (siehe 2). Jedoch speichert er periodisch (z.B. einmal jede 5 bis 15 Sekunden) dauerhaft einen Empfängerkontextsatz 270 und eine Menge von Abbildspurkontextsätzen 271 auf einer nicht flüchtigen (Platten-)Speichervorrichtung 172 (siehe 7A und 7B).
  • Löscherprozess - Überblick
  • Der Löscherprozess entfernt periodisch Abbildspurdateien, die nicht länger benötigt werden, selbst im Fall einer Übernahme. Weil die Aktualisierer Prüfsätze auf die Ersatzdatenbank selbst für Transaktionen einbringen, deren Ausgang unbekannt ist, entfernt der Löscher Abbildspurdateien, deren Prüfsätze alle mit Transaktionen korrespondieren, deren Ausgang dem Ersatzsystem bekannt ist.
  • Aktualisiererprozess - Überblick
  • Jeder RDF-geschützte Datenträger 106 auf dem Hauptcomputersystem 110 hat seinen eigenen Aktualisiererprozess 134 auf dem Ersatzcomputersystem 122, der für das Einbringen von Prüfabbildsätzen auf den korrespondierenden Ersatzdatenträger 126 auf dem Ersatzcomputersystem 122 verantwortlich ist, um so die prüfgeschützten Dateien auf diesem Datenträger zu verdoppeln. Prüfabbildsätze, die sowohl den ausgeführten als auch den stornierten Transaktionen auf dem Hauptsystem zugeordnet sind, werden auf die Datenbank auf dem fernen Ersatzcomputersystem 122 eingebracht. In der vorliegenden Erfindung wird kein Versuch unternommen, das Einbringen stornierter Transaktionen auf die Ersatzdatenbank zu vermeiden, weil bestimmt worden ist, dass es effizienter ist, sowohl die Aktualisierungsprüfsätze als auch die Stornierungsprüfsätze für solche Transaktionen einzubringen, als die Aktualisierer zu zwingen zu warten, bis der Ausgang einer jeden Transaktion bekannt ist, bevor die Aktualisierungen der Transaktion auf die Ersatzdatenbank eingebracht werden. Einfach durch Einbringen aller logischen Prüfsätze auf die Ersatzdatenbank sind die Aktualisierer in der Lage, die Ersatzdatenbank im Wesentlichen mit der Hauptdatenbank zu synchronisieren. Auch vermeidet diese Technik Unterbrechungen des RDF-Systems, die durch lang laufende Transaktionen verursacht werden. In vorangegangenen Versionen des RDF-Systems von Tandem würden lang laufende Transaktionen das Ersatzsystem dazu bringen, das Einbringen von Prüfsätzen auf die Ersatzdatenbank vollständig zu stoppen, bis solche Transaktionen abgeschlossen sind.
  • Die Prüfabbildsätze in jeder Abbildspur 136, 138 werden typisch einer nach dem anderen von den Aktualisierern 134 gelesen und verarbeitet. Jeder Aktualisierer 134 liest alle Prüfabbildsätze in der korrespondierenden Abbildspur, nutzt aber nur die Prüfabbildsätze, die dem Hauptplattendatenträger zugeordnet sind, für die dieser Aktualisierer verantwortlich ist.
  • In periodischen Intervallen speichert jeder Aktualisierer seine derzeitige Abbildspurposition in einem Kontextsatz dauerhaft auf Platte. Diese Position wird die Restart-Abbildspurposition genannt.
  • Wenn ein Aktualisiererprozess 134 eine Grenzposition erreicht, die von dem Empfänger spezifiziert ist, was von dem Aktualisierer als das logische Dateiende der Abbildspur 136, 138 behandelt wird, der er zugeordnet ist, führt er ein Warten für eine vorausgewählte Zeitspanne wie etwa zwei bis zehn Sekunden durch, bevor er eine andere Nachricht an den Empfänger sendet, um eine aktualisierte Grenzposition anzufordern. Nur wenn die Grenzposition aktualisiert worden ist, kann der Aktualisierer weitere Prüfabbildsätze lesen.
  • Monitorprozess - Überblick
  • Der Monitorprozess 140 und ein anderer Prozess mit dem Namen RDFCOM (welche für den Zweck dieses Dokuments kollektiv als der Monitor bezeichnet wird) werden verwendet, um Ausgaben als Reaktion auf Benutzerkommandos an das RDF-System durchzuführen.
  • RDF Konfigurationsdatei
  • Mit Bezug auf 3 wird die Struktur eines jeden RDF-Systems 120 repräsentiert durch eine Konfigurationsdatei 180, die auf dem Kontrolldatenträger des Hauptsystems 110 und dem Kontrolldatenträger des dem RDF-System zugeordneten Ersatzsystems 122 gespeichert ist. Die Konfigurationsdatei 180 umfasst
    • – einen globalen RDF-Konfigurationssatz 181;
    • – einen Monitorkonfigurationssatz 182 für die Identifizierung von Kennwerten des Monitorprozesses des RDF-Systems;
    • – einen Extraktorkonfigurationssatz 183 für die Identifizierung von Kennwerten des Extraktorprozesses des RDF-Systems;
    • – einen Empfängerkonfigurationssatz 184 für die Identifizierung von Kennwerten des Empfängerprozesses des RDF-Systems;
    • – einen Löscherkonfigurationssatz 185 für die Identifizierung von Kennwerten des Löscherprozesses des RDF-Systems;
    • – je einen Aktualisiererkonfigurationssatz 186 für jeden der Aktualisierer des RDF-Systemsfür die Identifizierung von Kennwerten des korrespondierenden Aktualisiererprozesses des RDF-Systems;
    • – je einen Aktualisiererkonfigurationssatz 187 für jede der Abbildspuren in dem Ersatzsystem;
  • Die in dem globalen RDF-Konfigurationssatz 181 gespeicherte Information umfasst:
    • – den Knotennamen des Hauptsystems;
    • – den Knotennamen des Ersatzsystems;
    • – den vom RDF-System verwendeten Kontrollunterdatenträger;
    • – den Zeitpunkt, zu dem das RDF-System initialisiert wurde;
    • – den Namen und Ort der Journaldatei des RDF-Systems;
    • – die Anzahl der Abbildspuren in dem Ersatzsystem;
    • – die Anzahl der geschützten Datenträger, welche auch die Anzahl der Aktualisierer in dem Ersatzsystem ist;
    • – die Anzahl der vom RDF-System verwendeten Nachrichtenpuffer; und andere Information, die hier nicht relevant ist.
  • Jeder der Prozesskonfigurationssaätze 182 – 187 umfasst Information, welche die CPU identifiziert, auf denen der jeweilige Prozess und sein Ersatzprozess läuft, die dem Prozess zugewiesene Priorität, u.s.w. Zusätzlich spezifiziert der Empfängerkonfigurationssatz 184 auch die Größe einer jeden Abbildspurdatei und den Datenträger, der für die Speicherung der Hauptabbildspurdateien verwendet wird.
  • Der Löscherkonfigurationssatz 185 umfasst einen Parameter, der Abbildspur-RetainCount genannt wird und die minimale Anzahl von Abbildspurdateien bezeichnet, die für jede Abbildspur beibehalten wird.
  • Die Aktualisiererkonfigurationssätze 186 identifizieren jeweils die Abbildspur, von welcher der zugeordnete Aktualisierer Information liest, den Hauptdatenträger, dessen Prüfinformation von dem Aktualisierer zu verarbeiten ist, und den Ersatzdatenträger, auf den Datenbankaktualisierungen von dem Aktualisierer einzubringen sind
  • Jeder Abbildspurkonfigurationssatz 187 identifiziert den Plattendatenträger, auf dem die Abbildspurdateien für die korrespondierende Abbildspur zu speichern sind.
  • Benutzung von Parallelen RDF-Systemen - Überblick
  • Mit Bezug auf 4 wird ein System gezeigt, in dem die Datenträger 106 auf einem Hauptsystem 110 durch zwei oder mehrere parallele RDF-Systeme 220 geschützt werden. Jedes RDF-System 220 enthält seine eigene Kopie aller der in 1 gezeigten Prozesse und Datenstrukturen für ein einzelnes RDF-System 120.
  • Identische Kopien der gesamte Konfigurationsdatei für jedes RDF-System sind auf dem Hauptsystem und den Ersatzsystemen gespeichert, während der Kontext, die Ausnahmen und Abbilddateien nur auf dem Ersatzsystem gespeichert sind.
  • Das Halten vielfacher Ersatzkopien einer Datenbank ist besonders nützlich in mindestens zwei kommerziellen Umgebungen:
    • 1) Anwendungen, die nur intensive Leseanfragen (Blättermode) stellen. Ein klassisches Beispiel davon würde eine Telefonrechnungsstellungssystem sein, in dem die Rechnungsdatenbankänderungen auf dem Hauptsystem und die Telefonverzeichnisanfragen auf dem Ersatzsystem durchgeführt würden.
    • 2) Anwendungen in denen ein "dreifacher Ausfall"-Schutz verlangt wird. Der relevante dreifache Ausfall ist der Ausfall des Hauptdatenbanksystems und eines fern liegenden Ersatzsystems (zweifacher Ausfall) während überlappender Zeiträume (dritter Ausfall). Insbesondere ist es in solchen Anwendungen inakzeptabel, Anwendungen auf einem einzigen System ohne ein Ersatzsystem ablaufen zu lassen.
  • Statt dessen wird verlangt, dass (A) das Hauptsystem mindestens zwei parallele Ersatzsysteme hat, (B) nach dem Verlust des Hauptsystems ein Ersatzsystem als das neue Hauptsystem eingesetzt wird, (C) ein anderes Ersatzsystem als das Ersatzsystem zu dem neuen Hauptsystem eingesetzt wird, und (D) ein neues RDF-System eingerichtet wird, um Daten von dem neuen Hauptsystem auf das andere Ersatzsystem zu verdoppeln. Somit sind die Daten auf dem Hauptsystem, selbst wenn es tatsächlich ein früheres Ersatzsystem ist, immer durch mindestens ein RDF-System geschützt. Beispiele von Systemen, in denen ein dreifacher Ausfallschutz verlangt wird, sind große Bankensysteme oder eine nationale Geldmitteltransaktionseinrichtung oder ein Clearinghousesystem.
  • Ein einziges RDF-System, das konfiguriert ist, Datenbanken über vielfache Ersatzsysteme zu verdoppeln, ist aus einer Anzahl von Gründen nicht praktisch. Z.B. würde verlangt werden, dass der Extraktorprozess einen Prüfsatzpuffer an vielfache Ersatzsysteme überträgt. Aber wenn der Kommunikationspfad zu nur einem der Ersatzsystem ausfällt, würde das Extraktorprozesssystem entweder die Übertragung von Prüfsatzinformation an alle Ersatz systeme einzustellen haben, bis die Probleme des Kommunikationspfads gelöst sind, oder es hätte zu verfolgen, welche Prüfsatzinformation an jedes der Ersatzsysteme übertragen wurde (was ineffizient sein würde) Folglich werden dann, wenn vielfache Ersatzsysteme benötigt werden, vielfache RDF-Systeme 220 mit einem gemeinsamen Hauptknoten verwendet.
  • Um die Orte der von jedem der parallelen RDF-System 220 verwendeten Dateien zu verfolgen, wird die folgende Namensgebungskonvention in einer bevorzugten Ausführungsform angewendet. Der "Pfadname" einer jeden Konfigurationsdatei eines RDF-Systems ist vorzugsweise von der Form "$SYSTEM.xxx.config", wo $SYSTEM immer der Name des Kontrolldatenträgers eines jeden Knotens in dem System 100 ist, "config" die Datei als eine RDF-Konfigurationsdatei identifiziert und "xxx" ein "Unterdatenträger"-Name ist, der das RDF-System eindeutig identifiziert. Wenn ein Hauptsystem 110 durch mehr als ein RDF-System geschützt ist, wird jedes dieser RDF-Systeme einen unterschiedlichen Unterdatenträgernamen haben. In der bevorzugten Ausführungsform besteht der jedem RDF-System zugewiesene Unterdatenträgername aus dem Knotennamen des Hauptsystems und einem alphanumerischen Zeichen (z.B. 1, 2,... oder ein Buchstabe) als Unterdatenträger-Suffix. Falls z.B. der Knotenname des Hauptsystems 110 "A" ist und zwei parallele RDF-Systeme eingesetzt sind, würden ihre jeweiligen Konfigurationsdateien wahrscheinlich $SYSTEM.A1.config und $SYSTEM.A2.config benannt sein.
  • Wie in 4 gezeigt, werden ähnliche Namensgebungskonventionen für die Kontextdatei, die Ausnahmedatei und die Abbilddateien eines jeden RDF-Systems 220 verwendet, wie oben erläutert. Jede Kontextdatei des RDF-Systems speichert alle Kontextsätze für das System. Jedesmal, wenn ein Kontextsatz dauerhaft gespeichert wird, wird der Satz in der Kontextdatei auf Platte gespeichert. Die Ausnahmedatei und die Abbilddateien werden im Folgenden in größerem Detail diskutiert. In der bevorzugten Ausführungsform werden Abbildspuren auf vom Benutzer ausgewählten Datenträgern gespeichert, die unterschiedlich sind von dem Kontrolldatenträger $SYSTEM, aber sie verwenden immer noch denselben "xxx"-Kontrollunterdatenträgernamen wie die korrespondierenden Konfigurations- und Kontextdateien.
  • Es wird bemerkt, dass die RDF-Konfigurations-, Kontext- und Ausnahmedateien, die zuvor auf einem Kontrollunterdatenträger eines Ersatzsystems (z.B. $SYSTEM.A1) gespeichert sind, gelöscht werden müssen, bevor eine neue Konfiguration unter Verwendung desselben Ersatzsystems initialisiert werden kann. Das RDF-System wird automatisch alle alten Abbildspurdateien löschen, wenn ein neues RDF-System neu gestartet wird.
  • Prüfsatztypen
  • Die Hauptprüfspur (MAT) 104 enthält die folgenden Typen von Sätzen:
    • – Aktualisierungssätze, welche die Veränderungen an einem Datenbankdatenträger reflektieren, die durch eine Transaktion durchgeführt werden, durch Bereitstellen von Vorher- und Nachhersatzabbildern des aktualisierten Datenbanksatzes. Jeder Aktualisierungssatz bezeichnet die Transaktions-ID der Transaktion, welche die Datenbankveränderung herbeigeführt hat, und die Identität des Datenbankdatenträgers und Datenbanksatzes, die aktualisiert worden sind.
    • – Rückabwicklungssätze, welche die Umkehrung der vorangegangenen Veränderungen reflektieren, die an einem Datenbankdatenträger durchgeführt wurden. Die durch Rückabwicklungssätze repräsentierten Datenbankveränderungen werden manchmal hier Aktualisierungsstornierungen genannt und sind bezeichnet durch Vorher- und Nachhersatzabbildern des aktualisierten Datenbanksatzes. Rückabwicklungsprüfsätze werden erzeugt, wenn eine Transaktion abgebrochen wird und die durch die Transaktion herbeigeführten Datenbankveränderungen rückgängig gemacht werden müssen. Jeder Rückabwicklungssatz bezeichnet die Transaktions-ID der Transaktion, weiche die Datenbankveränderung herbeigeführt hat, und die Identität des Datenbankdatenträgers und Datenbanksatzes, die durch die Aktualisierungsstornierung modifiziert worden sind.
    • – Transaktionszustandssätze einschließlich Durchführungs- und Stornierungssätze, Transaktionsaktivitätssätze, wie auch Transaktionsvorbereitungs- und Transaktionsabbruchsätze. Durchführungs- und Stornierungssätze bezeichnen, dass eine spezifizierte Transaktion durchgeführt oder storniert worden ist. Transaktionsaktivitätssätze (manchmal auch Transaktionslebenszeichensätze genannt) wie auch Transaktions vorbereitungs- und Transaktionsabbruchsätze bezeichnen, dass eine Transaktion aktiv ist. Jeder Transaktionszustandssatz bezeichnet die Transaktions-ID der Transaktion, über deren Zustand berichtet wird. Es wird garantiert, dass jede Transaktion einen Transaktionszustandssatz während eines jeden TMP-Kontrollzeitrahmens (d.h. zwischen zwei aufeinander folgenden TMP-Kontrollpunkten) produziert. Ein Transaktionsaktivitätssatz wird in der Hauptprüfspur gespeichert, wenn die Transaktion während eines TMP-Kontrollzeitrahmens nicht durchgeführt oder storniert wird.
    • – TMP-Kontrollpunktsätze, die "Zeitmarken" sind, welche durch die TMF 102 in die Hauptprüfspur in unterschiedlichen Intervallen abhängig von der Transaktionsbelastung des Systems eingefügt werden. Während einer starken Transaktionsbelastung können TMP-Kontrollpunktsätze mit einem Abstand von weniger als einer Minute eingefügt werden; bei mäßiger Belastung ist die durchschnittliche Zeit zwischen TMP-Kontrollpunktsätzen etwa fünf Minuten; und bei sehr leichter Belastung kann die Zeit zwischen TMP-Kontrollpunktsätzen so lang sein wie eine halbe Stunde. Es wird gesagt, dass die Menge der Prüfsätze zwischen zwei aufeinander folgenden TMP-Kontrollpunktsätzen innerhalb eines "TMP-Kontrollzeitrahmens" fallen.
    • – StopUpdaters-Sätze, welche bewirken, dass alle Aktualisierer stoppen, wenn sie diesen Satz in ihrer Abbildspur lesen.
    • – Andere Sätze, die für die gegenwärtige Diskussion nicht relevant sind.
  • Detaillierte Beschreibung des Extraktorprozesses
  • Mit Bezug auf 5A und 5B sind die von dem Extraktorprozess 130 verwendeten Hauptdatenstrukturen wie folgt. Wie oben festgestellt, nutzt der Extraktorprozess 130 zwei oder mehr Nachrichtenpuffer 242. Ein Teil eines jeden Nachrichtenpuffers 242 wird verwendet, um einen "Kopf" 280 zu speichern, der (A) eine Nachrichtenfolgenummer und (B) einen Zeitstempel umfasst. Der Rumpf 282 des Nachrichtenpuffers 242 wird verwendet, um Prüfabbildsätze 284 zu speichern. Jeder Prüfabbildsatz 284 umfasst einen Prüfinformationsabschnitt 286, einen MAT-Positionswert 288 und einen RTD-(relativer Zeitverzögerungs)-Zeitstempelwert 290. Der Prüfinformationsabschnitt 286 wird von dem Prüfsatz in der MAT 104 kopiert, während die MAT-Position 288 des Prüfsatzes und das RTD-Zeitstempelfeld 290 durch den Extraktorprozess hinzugefügt werden, um einen "Prüfabbildsatz" 284 zu erzeugen.
  • Der Prüfinformationsabschnitt 286 besteht aus der in den Prüfsätzen der MAT 104 gefundenen Standardinformation, wie die Vorher- und Nachherfeldwerte für eine modifizierte Reihe in einer Datenbanktabelle oder eine Durchführungs-/Stornierungsbezeichnung für eine abgeschlossene Transaktion. Andere Prüfsätze in der MAT, die für dieses Dokument relevant sind, sind die anderen Typen der oben angeführten Transaktionszustandssätze, TMP-Kontrollpunktsätze und "StopUpdaters"-Prüfsätze.
  • Der Extraktorprozess 130 führt auch eine Nachrichtenpufferzustandstabelle 294, die für jeden Nachrichtenpuffer anzeigt, dass der Puffer für die Benutzung verfügbar ist, oder nicht verfügbar ist, weil er gegenwärtig durch den Extraktorprozess benutzt wird. Zusätzlich führt der Extraktorprozess 130 eine Nachrichtenfolgenummer in dem Register 295, einen MAT-Dateizeiger in dem Register 296, einen lokalen Zeitstempelwert in dem Register 297 und ein Notizfeld 298, in dem er Prüfabbildsätze speichert, die er gegenwärtig verarbeitet.
  • Schließlich umfasst der Extraktorprozess 130 eine Datenstruktur 299 für die Speicherung von Antwortnachrichten, die er von dem Empfängerprozess 132 empfängt. Diese Datenstruktur umfasst ein erstes Feld, das den Typ der empfangenen Nachricht bezeichnet, einen Nachrichtenpufferidentifikator und ein "Nachrichtenwert"-Feld. Der Nachrichtenwert ist gleich einem MAT-Positionswert, wenn der Nachrichtentyp "Resynchronisationsantwort" ist, und ist gleich einem "OK"- oder "Fehler"-Zustandscode, wenn der Nachrichtentyp "Nachrichtenpufferbestätigung" ist.
  • Mit Bezug auf 6A – 6E arbeitet der Extraktorprozess 130 wie folgt.
  • Die Extraktorstartprozedur 300 wird aufgerufen, wann immer der Extraktorprozess 130 oder sein Ersatzprozess gestartet wird, wie im Fall einer Ausfallübernahme oder einer Übertragung der Steuerung zurück zu dem Hauptextraktorprozess 130 von dem Ersatzextraktorprozess. Die Startprozedur beginnt mit der Durchführung einer "statischen Initialisierung" des Extraktorprozesses (Schritt 302), was bedeutet, dass alle von dem Extraktorprozess verwendeten statischen Datenstrukturen zugewiesen und initialisiert werden. Während der Initialisierung liest der Extraktorprozess Informationen, die eine Menge von RDF-geschützte Objekte bezeichnen, aus der Konfigurationsdatei und baut eine interne Tabelle der RDF- geschützten Plattendatenträger auf. Diese Tabelle wird später als ein Prüfsatzfilter verwendet, so dass Prüfsätze von nicht geschützten Datenträgern durch den Extraktorprozess ignoriert werden. Dann erzeugt die Startprozedur einen Ersatzprozess (Schritt 304). Dann wird eine Prüfpunktoperation durchgeführt, in der ein Übernahmeort zu dem Ersatzextraktorprozess übertragen wird (Schritt 306). Der Übernahmeort ist im Wesentlichen eine Programmadresse und in der bevorzugten Ausführungsform ist der Übernahmeort die Programmstelle, an der die Ausführung der flüchtigen Initialisierungsprozedur 310 beginnt. Schließlich ruft die Extraktorstartprozedur die Extraktor-flüchtige-Initialisierungsprozedur 310 auf (Schritt 308).
  • Die Extraktor-flüchtige-Initialisierungsprozedur 310 wird während eines Starts durch die Extraktorstartprozedur 300 aufgerufen, wenn der Extraktorprozess eine Fehlerantwortprozedur von dem Empfängerprozess empfängt, und wann immer es einen Extraktorprozessausfall gibt. Die Extraktor-flüchtige-Initialisierungsprozedur beginnt durch Zuweisung und Initialisierung aller von dem Extraktorprozess benutzten flüchtigen Datenstrukturen, einschließlich der Nachrichtenpuffer 142, des Nachrichtenpufferzustandsfelds 295 (Schritt 312) und der Nachrichtenfolgenummer (die auf einen Anfangswert wie etwa 1 initialisiert wird). Dann überträgt die Extraktor-flüchtige-Initialisierungsprozedur eine Resynchronisationsanforderungsnachricht an den Empfängerprozess (Schritt 314) und wartet auf eine Resynchronisationsantwortnachricht (Schritt 316). Die Resynchronisationsantwortnachricht wird einen MAT-Positionswert enthalten, welchen die Extraktor-flüchtige-Initialisierungsprozedur in die MAT-Position 296 speichert (Schritt 318). Schließlich ruft die Extraktor-flüchtige-Initialisierungsprozedur die Hauptextraktorprozedur 330 auf Schritt 320).
  • Die Hauptextraktorprozedur 330 beginnt mit der Initialisierung und dem Start eines Nachrichtenzeitglieds, das Message Timer (MsgTimer) genannt wird (Schritt 332). Das Nachrichtenzeitglied ist typisch programmiert, um nach einer Sekunde abzulaufen, obgleich die Ablaufzeitspanne auf fast jeden Wert konfigurierbar ist. Als Nächstes liest die Hauptextraktorprozedur einen Satz in der MAT (Schritt 334). Falls der MAT-Satz ein logischer Prüfsatz für einen RDF-geschützten Datenträger (z.B. Aktualisierung oder Rückabwicklung), ein Transaktionszustandssatz für eine Transaktion, ein TMP-Kontrollpunktsatz oder ein "StopUpdaters"-Satz ist, wird ein Prüfabbildsatz gebildet durch Kopieren des MAT-Satzes und Hinzufügen der MAT-Position des gegenwärtigen MAT-Satzes zum Prüfabbildsatz und durch Hinzufügen eines RTD-Zeitstempels zum Prüfabbildsatz (Schritt 336). Der hinzugefügte RTD-Zeitstempel ist der Zeitstempel der letzten Transaktion, die vor der Erzeugung des Prüfabbildsatzes abgeschlossen wurde. Jedesmal dann, wenn die Hauptextraktorprozedur einen Durchführungs- oder Stornierungsprüfabbildsatz antrifft, speichert sie eine Kopie des Zeitstempels in diesem Satz in sein lokales Zeitstempelregister 297. Der Wert des lokalen Zeitstempelregisters 297 ist der RTD-(relative Zeitverzögerungs)-Zeitstempel, der den Prüfabbildsätzen hinzugefügt wird, um so einen Prüfabbildsatz zu erzeugen, der auch als Abbildsatz bekannt ist.
  • Falls der gegenwärtig benutzte Nachrichtenpuffer Platz hat für den sich ergebenden Prüfabbildsatz (Schritt 338), wird er in den Nachrichtenpuffer gespeichert (Schritt 340). Dann setzt die Hauptextraktorprozedur die Verarbeitung mit dem nächsten Satz in der MAT bei Schritt 334 fort.
  • Falls der gegenwärtig benutzte Nachrichtenpuffer voll ist (Schritt 338), werden die Werte in dem Nachrichtenfolgenummerregister 297 in den Kopf 280 des Nachrichtenpuffers eingefügt (Schritt 342). Die Hauptextraktorprozedur überträgt dann den Nachrichtenpuffer an den Empfängerprozess (Schritt 344). Nach der Übertragung des Nachrichtenpuffers wird das Nachrichtenpufferzustandsfeld 294 aktualisiert, um anzuzeigen, dass der gerade übertragene Nachrichtenpuffer nicht mehr für die Benutzung verfügbar ist. Zusätzlich wird das Nachrichtenzeitglied zurückgesetzt und neu gestartet, und die Nachrichtenfolgenummer im Register 295 wird um 1 erhöht (Schritt 346). Schließlich wird der Prüfabbildsatz, der nicht mehr in den letzten Nachrichtenpuffer hinein passte, in den nächsten verfügbaren Nachrichtenpuffer gespeichert (Schritt 348). Falls ein nächster Nachrichtenpuffer nicht verfügbar ist, wartet die Hauptextraktorprozedur, bis ein solcher verfügbar wird, und speichert dann den Prüfabbildsatz in ihm hinein. Die Hauptextraktorprozedur setzt dann die Verarbeitung mit dem nächsten Satz in der MAT bei Schritt 334 fort.
  • Wenn der (in Schritt 334) aus der MAT 104 gelesene Prüfabbildsatz nicht ein Prüfabbildsatz für einen RDF-geschützten Datenträger, auch nicht ein Transaktionszustandssatz und ebenfalls nicht ein "StopUpdaters"-Satz und nicht ein TMP-Kontrollpunktsatz ist, wird der Prüfsatz ignoriert und der nächste Prüfabbildsatz in der MAT (falls vorhanden) wird gelesen (Schritt 334).
  • Der Zweck des Nachrichtenzeitglieds ist es, sicherzustellen, dass die Prüfabbildsätze zum Empfängerprozess auf zeitgerechte Weise übertragen werden, selbst wenn die Rate, mit der Prüfabbildsätze für RDF-geschützte Dateien erzeugt werden, niedrig ist. Mit Bezug auf 6D prüft die Nachrichtenzeitgliedprozedur 360 dann, wenn das Nachrichtenzeitglied abläuft, zuerst, ob der gegenwärtige Nachrichtenpuffer leer ist (d.h. keine Prüfabbildsätze enthält) (Schritt 362). Falls das zutrifft, wird ein Zeitstempel, der für die gegenwärtige Zeit bezeichnend ist, in den Kopf 280 des Nachrichtenpuffers eingefügt (Schritt 364). Falls das nicht zutrifft, wird der Zeitstempel von dem letzten Durchführungs-/Stornierungssatz, der im RTD-Zeitstempelregister 297 gespeichert ist, in den Kopf 280 des Nachrichtenpuffers eingefügt (Schritt 366). Dann wird die gegenwärtige Nachrichtenfolgenummer in den Kopf 280 des Nachrichtenpuffers eingefügt (Schritt 368) und der Nachrichtenpuffer wird zum Empfängerprozess übertragen (Schritt 370). Nach der Übertragung des Nachrichtenpuffers wird das Nachrichtenpufferzustandsfeld 294 aktualisiert, um anzuzeigen, dass der gerade übertragene Nachrichtenpuffer nicht mehr für die Benutzung verfügbar ist, das Nachrichtenzeitglied wird zurückgesetzt und neu gestartet, und die Nachrichtenfolgenummer im Register 295 wird um 1 erhöht (Schritt 372).
  • Wenn der Hauptextraktorprozess eine Antwort von dem Empfängerprozess empfängt, die den Empfang eines Nachrichtenpuffers bestätigt (Schritt 374), wird dann, wenn die Antwortnachricht anzeigt, dass der Nachrichtenpuffer fehlerfrei empfangen wurde, das Nachrichtenpufferzustandsfeld 294 aktualisiert, um anzuzeigen, dass der in der Antwortnachricht identifizierte Nachrichtenpuffer wieder für die Benutzung verfügbar ist (Schritt 376).
  • Falls die von dem Extraktorprozess empfangene Antwortnachricht von dem Empfängerprozess anzeigt, dass der Extraktorprozess einen Restart ausführen muss, dann müssen sich der Extraktorprozess und der Empfängerprozess resynchronisieren. Der Empfängerprozess teilt dem Extraktorprozess mit, einen Restart auszuführen, wenn (A) eine Nachricht mit einer Nachrichtenfolgenummer außerhalb der Folge empfangen wurde, (B) wann immer der Empfängerprozess nach einer Übernahme aufgrund eines Ausfalls oder nach einer Rückgabe der Steuerung zurück zum Hauptempfängerprozess vom Ersatzempfängerprozess (manchmal eine Prüfumschaltung genannt) startet. Wenn der Extraktorprozess eine Antwortnachricht mit Fehleranzeige von dem Empfängerprozess empfängt, die eine Notwendigkeit der Resynchronisation anzeigt, wartet er auf anstehende Nachrichtenbestätigungsantworten, die für andere Nachrichtenpuffer vor dem Empfang der Antwortnachricht mit Fehleranzeige zu empfangen sind, und ignoriert diese Antwortnachrichten (Schritt 378). Dann ruft der Extraktorprozess die Extraktor-flüchtige-Initialisierungsprozedur auf (Schritt 379), um so den Extraktorprozess mit dem Empfängerprozess zu resynchronisieren.
  • Detaillierte Beschreibung des Empfängerprozesses
  • Die von dem Empfängerprozess 132 in der bevorzugten Ausführungsform verwendeten Hauptdatenstrukturen sind in 7A – 7G gezeigt. Wie oben festgestellt, speichert der Empfängerprozess einen Empfängerkontextsatz 270 und eine Menge von Abbildspurkontextsätzen 271 dauerhaft auf einer nicht flüchtigen (Platten-) Speichervorrichtung 272 auf einer periodischen Basis. Der Empfängerkontextsatz 270 umfasst einen Zählerwert Receiver.StopUpdatersCnt 391, einen Übernahme-abgeschlossen-Merker 391A (der für die Anzeige verwendet wird, wenn eine RDF-Übernahmeoperation abgeschlossen ist), ein NumNode-Feld 391B und vorangegangene SysTxList 391C (das für das Löschen alter Abbildspurdateien verwendet wird).
  • Jeder Kontextsatz 271 einer Abbildspur umfasst eine MAT-Position, eine MIT-Position, die nächste Schreibposition. Unter einigen Umständen können der Empfängerkontextsatz 270 und die Menge der Abbildspurkontextsätze 271 zusammen der Empfängerkontextsatz oder Empfängerkontextsätze genannt werden, da diese Kontextsätze zusammen verwendet werden, um dem Empfängerprozess zu ermöglichen, sich selbst einem Restart zuzuführen und mit dem Extraktorprozess zu resynchronisieren.
  • Zwei Abbildspurpuffer 274 werden für jede Abbildspur verwendet, und diese Puffer werden auf abwechselnde Weise verwendet. Mit Bezug auf 7D besteht jeder Abbildspurpuffer 274 aus vierzehn Datenblöcken 393, wobei die Größe eines jeden Blocks 4 KByte beträgt. Jeder 4-KByte-Block 393 beginnt mit einem Blockkopf 394, der umfasst:
    • – den Dateispeicherort des Blocks, der aus der relativen Byte-Adresse (rba) des Beginns des Blocks hinsichtlich des Beginns der Abbildspurdatei besteht;
    • – einen Hauptabbildspur-(MIT)-Positionsbezeichner, der den Ort des MIT-Blocks bezeichnet, in den der Empfängerprozess zuletzt einen Durchführungs-/Stornierungssatz schrieb, bevor ein Prüfsatz in den gegenwärtigen Abbildspurblock 393 geschrieben wurde;
    • – einen Zeiger auf den ersten Prüfabbildsatz, der in dem Pufferblock beginnt (d.h. unter fast allen Umständen wird der erste Abbildsatz, der in dem Puffer beginnt, nicht am Beginn des Rumpfs des Pufferblocks beginnen);
    • – einen Zeiger auf das Ende des letzten Satzes, der im Block abschließt;
    • – einen Zeiger auf das nächste verfügbare Byte in dem Block (falls es eines gibt); und
    • – die MAT-Position des Prüfabbildsatzes am Beginn des Pufferblocks (der gewöhnlich in einem früheren Block beginnt).
  • Prüfabbildsätze stimmen selten exakt mit den Pufferblockgrenzen überein, und deshalb setzt sich der Prüfabbildsatz am Ende eines Pufferblocks gewöhnlich mit dem Beginn des nächsten Pufferblocks fort.
  • Ein typischer MIT-Positionswert würde "10, 8192" sein, wo "10" die Dateifolgenummer innerhalb der korrespondierenden Folge von Abbildspurdateien und die "8192" einen relativen Byte-Versatz vom Beginn der Abbildspurdatei bis zu einem Blockkopf repräsentiert.
  • Wie oben ausgeführt, hat jeder zum Empfängerprozess 132 übertragene Prüfsatz einen MAT-Positionswert, der in ihn durch den Extraktorprozess eingefügt wurde. Die MAT-Position in einem Abbildspurkontextsatz 271 bezeichnet die MAT-Position des letzten Prüfsatzes, der in der Abbildspurdatei dauerhaft gespeichert wurde.
  • Die MIT-Position in einem Abbildspurkontextsatz 271 bezeichnet eine MIT-Position, die dem letzten dauerhaft gespeicherten Abbildspurblock zugeordnet ist. Dies ist die MIT-Position in dem letzten 4-KByte-Blockkopf des letzten Abbildspurpuffers, der gespeichert wurde, bevor der Abbildspurkontextsatz 271 zuletzt gespeichert wurde.
  • Ferner wird jeder Abbildspurpuffer 274 nur dann in die korrespondierende Plattendatei gespeichert, wenn (A) der Abbildspurpuffer 274 voll ist (d.h. 52 KByte Daten enthält), oder wenn der Empfängerprozess periodisch eine Ausspüloperation durchführt. Jedesmal dann, wenn Daten von einem Abbildspurpuffer 274 auf die Platte geschrieben werden, wird die Plattendateiadresse für das nächste Schreiben in die Abbildspurdatei (d.h. die Plattenadresse für das gegenwärtige Ende der Abbildspurdatei) in einem geeigneten Feld des Abbildspurkontextsatzes 270 gespeichert. Jedoch wird der Abbildspurkontextsatz einmal alle M Sekunden dauerhaft gespeichert, wie im Folgenden beschrieben wird, wobei M die Anzahl der Sekunden ist zwischen der Ausführung der Empfängerkontextsicherungsprozedur.
  • Der Wert "Receiver.StopUpdatersCnt" 391 ist ein Zählwert, der jedesmal erhöht wird, wenn der Empfänger einen StopUpdaters-Satz in einem empfangenen Nachrichtenpuffer antrifft, dessen MAT-Wert höher als die MAT-Position für mindestens eine Abbildspur ist. Dies wird im Folgenden in größerem Detail erläutert.
  • Mit Bezug auf 7E wird in dem Abbildspurzustandsfeld 392 für jede Abbildspur eine Menge von Pufferpositionsinformation, der MAT-Wert des letzten in dieser Abbildspur gespeicherten Satzes, ein Mellow-Merker und die gegenwärtige Grenzposition (d.h. das logische Dateiende) gespeichert. Die Pufferpositionsinformation für eine Abbildspur umfasst Zeiger auf die zwei Puffer, die durch die Abbildspur verwendet werden, einen Index, der anzeigt, in welchen der zwei Puffer gerade geschrieben wird, einen Zeiger auf den gerade beschriebenen Block und einen Zeiger (oder Versatz) auf die Position innerhalb dieses Blocks, an welcher der nächste Abbildsatz für die Abbildspur geschrieben werden wird. Die Pufferpositionsinformation wird jedesmal aktualisiert, wenn ein Prüfsatz zu einem Abbildspurpuffer hinzugefügt wird. Der Mellow-Merker wird in Verbindung mit der dauerhaften Speicherung von Abbildspurkontextsätzen verwendet, wie im Folgenden mit Bezug auf 8C und 8J detaillierter beschrieben wird. Die Grenzposition bezeichnet den letzten Satz in der Abbildspur, der von einem Aktualisierer gelesen werden sollte, welcher die Prüfsätze in der Abbildspur verarbeitet.
  • Der Empfängerprozess speichert auch eine "Nächste Nachrichtenfolgenummer" 396, eine "Restart-MAT-Position" 398, einen "Erwarte-Stop-Aktualisierungs"-Merker 399 und einen "Übernahme-Mode"-Merker 399A. Die Nächste Nachrichtenfolgenummer 396 ist die Nachrichtenfolgenummer, die der Empfänger in dem nächsten Nachrichtenpuffer zu sehen erwartet, und sie wird normaler Weise um Eins erhöht, nachdem jeder Nachrichtenpuffer empfangen worden ist. Während normalem Betrieb wird die Restart-MAT-Position 398 gleich dem höchsten MAT-Wert der Prüfsätze in dem letzten Nachrichtenpuffer gesetzt, der eine passende Folgenummer hat und erfolgreich von dem Extraktorprozess empfangen wurde. Wenn der Empfängerprozess gestartet oder wieder gestartet wird, wird jedoch die Restart-MAT-Position 398 anfangs auf den niedrigsten der MAT-Positionswerte gesetzt, die in den Abbildspurkontextsätzen 271 gespeichert sind. Der Erwarte-Stop-Aktualisierung-Merker 399 ist ein Merker, der als Reaktion auf eine spezielle "Erwarte-Stop-Aktualisierung"-Nachricht von dem Monitorprozess gesetzt wird unmittelbar bevor ein StopUpdaters-Prüfsatz von dem Extraktorprozess in seinen gegenwärtigen Nachrichtenpuffer gespeichert wird.
  • Der Übernahme-Mode-Merker 399A wird gesetzt, wann immer der Ersatzabschnitt des RDF-Systems eine RDF-Übernahmeoperation durchführt. Wenn der Übernahme-Mode-Merker gesetzt ist, arbeiten der Empfängerprozess und die Aktualisierer anders als gewöhnlich, wie im folgenden detaillierter beschrieben wird.
  • Mit Bezug auf 7F wird eine Aktualisierertabelle 400 von dem Empfänger verwendet, um Aktualisierer auf ihre Abbildspuren abzubilden, und auch um zu verfolgen, welche Aktualisierer ihm Nachrichten gesendet haben.
  • Mit Bezug auf 7G verwendet der Empfängerprozess ein Paar von "Systemtransaktionslisten"-Datenstrukturen 410, um den Bereich von Transaktions-ID für aktive Transaktionen nachzuvollziehen, die von jedem Prozessor der Transaktionsverwaltungseinrichtung 102 geführt werden (siehe Hauptsystem 100, 1). Die Transaktionsverwaltungseinrichtung 102 kann mehrfache Knoten umfassen, und jeder Knoten kann bis zu sechzehn Prozessoren umfassen. Ferner weist jeder Prozessor in der Transaktionsverwaltungseinrichtung TMF unabhängig von einander den von ihm ausgeführten Transaktionen monoton aufsteigende Folgenummern zu. Während die Zahl der parallelen Prozessoren möglicher Weise hoch ist, übersteigt die Anzahl der Knoten in der TMF selten vier.
  • Zwei Zeiger 412, 414 werden verwendet, um auf die gegenwärtige und vorherige Versionen der Systemtransaktionsliste 410 zu verweisen. Die gegenwärtige Systemtransaktionsliste ist diejenige, die gegenwärtig von dem Empfängerprozess für die laufende TMP-Kontrollpunktperiode aktualisiert wird, während die vorherige Systemtransaktionsliste den Bereich von Transaktions-ID für aktive Transaktionen für die vorherige (d.h. abgeschlossene) TMP-Kon trollpunktperiode bezeichnet. Die aktuellen Werte, die in den Schlitzen der SysTxList gespeichert sind, sind einfach die niedrigste und die höchste Folgenummer aktiver Transaktionen für die relevante TMP-Kontrollpunktperiode. Der Knotenabschnitt und der Prozessorabschnitt der Transaktions-ID werden in der SysTxList nicht gespeichert, weil sie durch den Schlitz und Unterschlitz des SysTxList bezeichnet werden, in denen diese Werte gespeichert sind, zusammen mit dem NumNode-Eintrag, der auf den Schlitz zeigt.
  • Ein NumNode-Feld 416 wird verwendet, um die Knotennummern der Knoten in der TMF 102 auf Schlitze in der gegenwärtigen SysTxList abzubilden. Null-Einträge in NumNode werden durch einen vordefinierten Wert wie etwa –1 bezeichnet. Jeder Nicht-Null-Eintrag von NumNode bezeichnet den Schlitz der Systemtransaktionsliste 410, der für den korrespondierenden Knoten des Hauptsystems zu benutzen ist. Falls z.B. NumNode(15) = 2 ist, bezeichnet dies, dass der Knoten 15 des Hauptsystems auf Schlitz 2 der für die Zwecke der Verfolgung der Bereiche aktiver Transaktionen abgebildet ist.
  • Das Feld "Nächster Schlitz" 418 des NumNode-Felds bezeichnet den nächsten ungenutzten Schlitz der Systemtransaktionsliste 410.
  • Mit Bezug zurück auf 7A umfasst der Empfängerkontextsatz 270 eine Kopie 391B des NumNode-Felds 391C der vorangegangenen SysTxList. Der Löscherkontextsatz (nicht gezeigt) umfasst einen Merker, welcher der UndoListWritten-Merker genannt wird, dessen Zweck im folgenden erläutert wird.
  • Mit Bezug auf 7H hat jede Transaktions-ID drei Komponenten:
    • – TxID.Node, welche den TMF-Knoten identifiziert, auf dem die Transaktion ausgeführt wurde;
    • – TxID.Proc, welche in Verbindung mit TxID.Node den TMF-Prozessor identifiziert, auf dem die Transaktion ausgeführt wurde;
    • – TxID.Seq# welche die Folgenummer ist, die der Transaktion von dem TMF-Prozessor zugewiesen wurde, der die Transaktion ausführt.
  • Mit Bezug auf 8A – 8K arbeitet der Empfängerprozess 132 wie folgt.
  • Mit Bezug auf 8A wird die Empfängerstartprozedur 440 aufgerufen, wann immer der Empfängerprozess 132 oder sein Ersatzprozess gestartet wird, wie im Fall einer Übernahme nach Ausfall oder einer Übertragung der Kontrolle zurück zu dem Hauptempfängerprozess 132 von dem Ersatzempfängerprozess. Die Startprozedur beginnt mit der Durchführung einer "statischen Initialisierung" des Empfängerprozesses (Schritt 442), was bedeutet, dass alle vom Empfängerprozess benutzten, statischen Datenstrukturen zugewiesen und initialisiert werden. Dann wird eine Prüfpunktoperation durchgeführt, in der ein Übernahmeort zu dem Ersatzempfängerprozess übertragen wird (Schritt 446). Der Übernahmeort ist im Wesentlichen eine Programmadresse, und in der bevorzugten Ausführungsform ist der Übernahmeort die Programmadresse, an der die Ausführung der Empfänger-flüchtige-Initialisierungsprozedur 450 beginnt. Schließlich ruft die Empfängerstartprozedur die Empfänger-flüchtige-Initialisierungsprozedur 450 auf (Schritt 448).
  • Mit Bezug auf 8B wird die Empfänger-flüchtige-Initialisierungsprozedur 450 während des Starts durch die Empfängerstartprozedur 440 aufgerufen. Die Empfänger-flüchtige-Initialisierungsprozedur 450 beginnt mit dem Lesen des zuletzt gespeicherten Empfängerkontextsatzes und der zuletzt gespeicherten Abbildspurkontextsätze von der Platte und mit dem Verwenden dieser Kontextsätze als die gegenwärtigen Kontextsätze des Empfängers in flüchtigen Speicher (Schritt 452). Dann weist die Empfänger-flüchtige-Initialisierungsprozedur alle von dem Empfängerprozess verwendeten, flüchtigen Datenstrukturen zu und Initialisiert sie (Schritt 454), einschließlich der Abbildspurpuffer 274, des Abbildspurzustandsfelds 392, des Aktualisiererzustandsfelds 400, des NumNode-Felds 415 und der gegenwärtigen und vorangegangenen Systemtransaktionslisten 410. Dann setzt die Empfänger-flüchtige-Initialisierungsprozedur die vom Empfänger erwartete Nachrichtenfolgenummer auf "1" (Schritt 456). Dies wird den Empfängerprozess und den Extraktorprozess zwingen, sich zu synchronisieren, außer wenn der Extraktorprozess zur selben Zeit gestartet wird, wie als Reaktion auf ein "Start RDF"-Kommando. Schließlich ruft die Empfänger-flüchtige-Initialisierungsprozedur die Hauptempfängerprozedur 460 auf (Schritt 458).
  • Mit Bezug auf 8C bis 8K umfasst die Hauptempfängerprozedur 460 eine Unterprozedur 470 für das periodische Ausspülen von Abbildspurpuffern auf die Platte und das Sichern der Abbildspurkontextsätze. Diese Unterprozedur wird alle M Sekunden aufgerufen, wo M vorzugsweise ein Wert zwischen 5 und 15 ist und typisch auf 5 eingestellt wird. In Schritt 472 führt die Abbildspurkontextsicherungsprozedur ein "träges" Ausspülen der Abbildspurpuffer auf die Platte durch. Insbesondere prüft sie den Mellow-Merker für jede Abbildspur. Für jede Abbildspur mit einem gesetzten Mellow-Merker wird die FlushImageTrail-Prozedur aufgerufen. Für jede Abbildspur mit einem nicht gesetzten Mellow-Merker, für die aber seit der letzten Abbildspurkontextsicherung für diese Abbildspur ein Satz geschrieben worden ist, wird der Mellow-Merker gesetzt. Die FlushImageTrail-Prozedur wird im Folgenden mit Bezug auf 8H, 8I und 8J beschrieben.
  • Es wird bemerkt, dass der Empfängerkontextsatz dauerhaft auf der Platte gespeichert wird, wann immer der MIT-Kontextsatz durch die FlushImageTrail-Prozedur oder die Complete-WritelnProgress-Prozedur gesichert wird (im Folgenden mit Bezug auf 8H und 8J beschrieben).
  • Mit Bezug auf 8H verwendet die FlushImageTrail-Prozedur eine Schreiboperation ohne Warten, um den Inhalt eines Abbildspurpuffers auf die Platte zu schreiben. Wenn eine Schreiboperation ohne Warten aufgerufen wird, wird der Prozess, der diese Schreiboperation aufruft, nicht blockiert. Statt dessen setzt er die Ausführung des Programms (der Programme) fort, die er gegenwärtig ausführt, ohne dass er darauf wartet, dass die Schreiboperation abgeschlossen wird. Jedesmal dann, wenn die FlushImageTrail-Prozedur für eine bestimmte Abbildspur aufgerufen wird, wird zuerst die (in 8I gezeigte) CompleteWritelnProgress-Prozedur aufgerufen, um sicherzustellen, dass irgendwelche zuvor aufgerufene Schreiboperationen erfolgreich abgeschlossen worden sind (Schritt 475). Dann führt die FlushImageTrail-Prozedur mit dem Abbildspurpuffer eine Schreiboperation auf die Platte ohne Warten durch und setzt die Pufferpositionsinformation der Abbildspur zurück, um einen Bezug auf den Anfang des anderen Puffers 274 für die Abbildspur herzustellen (Schritt 476). Wegen der Operation der CompleteWritelnProgress-Prozedur ist bekannt, dass der andere Puffer 274 für die Abbildspur zur Benutzung verfügbar ist, wenn Schritt 476 ausgeführt wird.
  • Falls die gegenwärtige Abbildspurdatei auf oder über einer maximalen Dateigröße liegt, wird eine neue Abbildspurdatei erzeugt (Schritt 477). Mit Bezug auf 8I wird dann, wenn eine neue Abbildspurdatei zu erzeugen ist, eine Abbildspurdateifolgenummer erhöht und die neue Datei wird unter Benutzung der Folgenummer als Teil ihres Dateinamens erzeugt.
  • Dann wird eine Kopie der vorherigen SysTxList von dem Empfängerkontextsatz am Anfang der neuen Abbildspurdatei gespeichert.
  • Mit Bezug auf 8J wird die CompleteWritelnProgress-Prozedur sofort beendet, wenn für die spezifizierte Abbildspur keine Schreiboperation ansteht (Schritt 478-A). Falls eine zuvor begonnene Schreiboperation immer noch abläuft, wartet die Prozedur auch darauf, bis sie abgeschlossen ist (Schritt 478-B). Falls eine zuvor begonnene Schreiboperation versagt hat, wird die Schreiboperation unter Verwendung einer Schreiboperation mit Warten wiederholt, bis die Schreiboperation erfolgreich abgeschlossen ist (Schritt 478-C). Falls als Nächstes der Mellow-Merker der gerade bearbeiteten Abbildspur gesetzt ist, wird der Mellow-Merker zurückgesetzt, der Abbildspurkontextsatz dauerhaft gespeichert und die Grenzposition für die Abbildspur aktualisiert (Schritt 478-D).
  • Falls die gerade bearbeitete Abbildspur die MIT ist, werden das NumNode-Feld und die vorherige SysTxList in den Empfängerkontextsatz kopiert, und der Empfängerkontextsatz wird dauerhaft gespeichert (Schritt 478-D).
  • Schließlich wird der Abbildspurpuffer, welcher der Schreiboperation zugeordnet ist, die abgeschlossen wurde, als verfügbar markiert, so dass er durch den Empfängerprozess wieder benutzt werden kann (Schritt 478-E).
  • Der Empfängerkontextsicherungsprozedur und die FlushImageTrail-Prozedur, die in 8C, 8H, 8I und 8J gezeigt sind, sind sehr effizient und ermöglichen, dass der Empfängerprozess viele Abbildspuren und Kontextsicherungen zeitgerecht durchführt. Dies kann am besten durch Betrachten der Operation dieser Prozeduren in zwei beispielhaften Situationen erkannt werden. Für jede diskutierte Situation wird angenommen, dass es drei Abbildspurpuffer gibt: MIT, IT1 und IT2.
  • Situation A.
  • Das Kontextsicherungszeitglied läuft ab und die Empfängerkontextsicherungsprozedur wird aufgerufen. Weil die Mellow-Merker für die Abbildspuren nicht gesetzt sind, werden sie jetzt gesetzt und der Empfänger nimmt die Verarbeitung neuer, vom Extraktor gesendeten Prüfsätze sofort wieder auf.
  • Wenn das Kontextsicherungszeitglied erneut abläuft und die Kontextsicherungsprozedur aufgerufen wird, ruft sie die FlushImageTrail-Prozedur für jede Abbildspur auf, weil der Mellow-Merker für jede der Abbildspuren gesetzt ist. Da gegenwärtig keine Schreiboperationen für jede Abbildspurdatei ablaufen, kehrt die CompleteWritelnProgress-Prozedur unmittelbar zurück, und Schreiboperationen ohne Warten werden angestoßen, um die gegenwärtigen Abbildspurpuffer für jede Abbildspur auf die Platte zu schreiben. Der alternative Puffer für jede Abbildspur wird zum neuen gegenwärtigen Puffer. Weil diese Schreiboperationen Operationen ohne Warten sind, kehrt der Empfängerprozess sofort zur Verarbeitung neuer Daten vom Extraktorprozess zurück und speichert diese Abbildprüfsätze in den neuen gegenwärtigen Puffer.
  • Wenn das Kontextsicherungszeitglied des Empfängers wieder abläuft und die Empfängerkontextsicherungsprozedur aufgerufen wird, ist der Mellow-Merker für jede Abbildspur noch gesetzt. Deshalb wird die FlushImageTrail-Prozedur für jede Abbildspur aufgerufen, welche wiederum die CompleteWritelnProgress-Prozedur für jede Abbildspur aufruft. Weil diese Schreiboperationen zuvor begonnen wurden, braucht der Empfänger aktuell nicht zu warten. Unter der Annahme, dass jede zuvor angestoßene Pufferschreiboperation ohne Fehler abschließt, wird der Mellow-Merker nun für jede Abbildspur zurückgesetzt, und der Kontextsatz für die Abbildspuren werden unter Verwendung einer Schreiboperation mit Warten auf die Platte geschrieben. Da jedoch die Kontextsätze klein sind, werden diese Schreiboperationen fast sofort abgeschlossen. Der Kontextsatz einer jeden Abbildspur auf der Platte reflektiert nun alle gerade geschriebenen Daten. Die Programmsteuerung kehrt dann zu der Empfängerkontextsicherungsprozedur und dann zu der Empfängerhauptprozedur zurück, und nimmt die Verarbeitung neuer Daten von dem Extraktor wieder auf.
  • Die Kontextsicherungsprozedur und die FlushImageTrail-Prozedur warten fast nie auf den Abschluss von Plattenschreiboperationen, weil die Abbildspurpufferschreiboperationen zwischen den Ausführungen der Kontextsicherungsprozedur zum Abschluss kommen. Folglich ist die Verarbeitung von Daten vom Extraktorprozess nahezu ununterbrochen durch die Operationen des Abbildspurpufferausspülens und der Kontextsicherung. Dies bleibt wahr selbst dann, wenn der Empfängerprozess hundert Abbildspuren bedient.
  • Situation B.
  • In dieser Situation werden so viel Prüfsätze an den Empfänger gesendet, dass ein Abbildspurpuffer voll wird, bevor das Kontextsicherungszeitglied abläuft. Wenn eine Pufferschreiboperation für jede Abbildspur angestoßen wird, wird der alternative Puffer zum gegenwärtigen Puffer.
  • Wenn das Kontextsicherungszeitglied abläuft, wird die Kontextsicherungsprozedur aufgerufen. Weil der Mellow-Merker gegenwärtig nicht gesetzt ist, wird er jetzt gesetzt und der Empfängerprozess kehrt zur Verarbeitung neuer Daten von dem Extraktorprozess zurück. Die ermöglicht, dass mehr Sätze in dem gegenwärtigen Abbildspurpuffer gespeichert werden.
  • Falls der gegenwärtige Abbildspurpuffer vor der nächsten Kontextsicherung voll wird, wird die FlushImageTrail-Prozedur aufgerufen. Vor dem Start der Schreiboperation wird die CompleteWritelnProgress-Prozedur aufgerufen. Weil die vorangegangene Schreiboperation eine Schreiboperation ohne Warten und zuvor angestoßen worden war, wird jene Schreiboperation bereits abgeschlossen sein, und der Empfängerprozess braucht nicht auf den Abschluss jener Schreiboperation zu warten. Die CompleteWritelnProgress-Prozedur setzt den Mellow-Merker der Abbildspur zurück und speichert den Kontextsatz der Abbildspur dauerhaft. Dann stößt die FlushImageTrail-Prozedur eine neue Schreiboperation ohne Warten für den vollen Abbildspurpuffer an, macht den anderen Puffer zum neuen gegenwärtigen Puffer und kehrt sofort zurück, um neue Prüfsätze vom Extraktorprozess zu verarbeiten.
  • Wenn das Kontextsicherungszeitglied wieder abläuft und die Kontextsicherungsprozedur aufgerufen wird, wird der Mellow-Merker gesetzt und der Empfängerprozess kehrt sofort zurück, um neue Prüfsätze vom Extraktorprozess zu verarbeiten.
  • Wenn der gegenwärtige Abbildspurpuffer wieder voll wird und auf die Platte geschrieben werden muss, wird die CompleteWritelnProgress-Prozedur von der FlushImageTrail-Prozedur aufgerufen. Wieder gab es zuvor eine Schreiboperation, die aber bereits abgeschlossen wurde. Deshalb setzt die CompleteWritelnProgress-Prozedur den Mellow-Merker zurück, aktualisiert den Abbildspurkontextsatz und speichert ihn dauerhaft, der nun alle Prüfabbildsätze reflektiert, die von der gerade abgeschlossenen Schreiboperation auf die Platte geschrieben worden sind. Die FlushImageTrail-Prozedur stößt ein neues Schreiben für den vollen Abbildspurpuffer ohne Warten an, der Puffer, dessen Inhalt bereits auf die Platte geschrieben wurde, wird zum neuen gegenwärtigen Puffer gemacht und dann kehrt der Empfängerprozess sofort zurück, um neue Prüfsätze vom Extraktorprozess zu verarbeiten.
  • Wenn der Empfängerprozess unter dem Druck großer Mengen von den vom Extraktorprozess gesendeten Prüfsätzen steht, ist er somit in der Lage, seinen Kontext schnell zu aktualisieren und die Verarbeitung von Prüfabbildsätzen wieder aufzunehmen, muss dabei nur auf den Abschluss der Schreiboperation des Abbildspurkontextes warten, braucht aber nicht auf den Abschluss der Schreiboperation der Abbildspurpuffer zu warten. Dies ist effizient für hundert Abbildspuren wie es für eine ist.
  • Der Empfängerprozess 132 ist ein "passiver" Prozess, indem er keine Nachricht an andere Prozesse anstößt. Statt dessen reagiert er nur auf Nachrichten von dem Extraktorprozess 130, Nachrichten von den Aktualisiererprozessen 134 und Nachrichten von dem Monitorprozess 140.
  • Mit Bezug auf 8D, 8E und 8F bestimmt der Empfängerprozess dann, wenn eine Nachricht von dem Extraktorprozess empfangen wurde (Schritt 462) und falls diese Nachricht eine Resynchronisationsanforderungsnachricht ist, welche der in den Abbildspurkontextsätzen aufgeführten MAT-Positionen am niedrigsten ist (Schritt 464) und sendet eine Resynchronisationsantwortnachricht an den Extraktorprozess mit der bestimmten, niedrigsten MAT-Position, die in die Antwortnachricht eingefügt ist (Schritt 466).
  • Falls die empfangene Extraktornachricht eine Nachrichtenpuffernachricht ist, wird die Nachrichtenfolgenummer (bezeichnet mit Message. SequenceNumber) in der empfangenen Nachricht mit der lokal gespeicherten Nächsten-Nachrichtenfolgenummer verglichen (Schritt 468). Falls die empfangene Nachrichtenfolgenummer nicht gleich der lokal gespeicherten Nächste-Nachrichtenfolgenummer ist, wird die empfangene Nachricht verworfen (Schritt 480) und eine Fehlerantwortnachricht an den Extraktorprozess gesendet (Schritt 482), welche die Notwendigkeit anzeigt, die Synchronisation wieder herzustellen.
  • Falls die empfangene Nachrichtenfolgenummer in richtiger Reihenfolge ist, wird die lokal gespeicherte Nächste-Nachrichtenfolgenummer um Eins erhöht (Schritt 484) und eine Antwortnachricht "Message Buffer OK" an den Extraktorprozess gesendet (Schritt 486). Ein Nachrichtenpufferidentifikator ist der empfangenen Nachricht zugeordnet und wird der Antwortnachricht zugeordnet, so dass der Extraktorprozess seine Nachrichtenpufferzustandstabelle aktualisieren kann durch Markieren des bestätigten Nachrichtenpuffers als verfügbar.
  • Als Nächstes werden alle Prüfabbildsätze in dem empfangenen Nachrichtenpuffer in Reihenfolge verarbeitet (Schritt 490). Für jeden Satz wird die dem Satz zugeordnete Abbildspur bestimmt (durch Bestimmen des Datenbankdatenträgers, der auf dem Hauptsystem aktualisiert wurde, Bestimmen des für die Verdoppelung von RDF-geschützten Dateien auf diesem Datenträger verantwortlichen Aktualisierers und dann Bestimmen der diesem Aktualisierer zugeordneten Abbildspur) (Schritt 492). Als Nächstes wird die MAT-Position (AuditRecord.MATpsn) in dem Prüfsatz mit der MAT-Position (IT.MATpsn) für die identifizierte Abbildspur verglichen (Schritt 494). Falls die MAT-Position des Prüfsatzes nicht größer als die MAT-Position der Abbildspur ist, wird der Prüfsatz ignoriert (Schritt 496), weil er bereits von dem Empfänger verarbeitet worden ist. Sonst wird der Prüfsatz in den identifizierten Abbildspurpuffer geschrieben, und die zugeordnete gegenwärtige MAT-Position der Abbildspur (IT.MATpsn in dem Abbildspurzustandsfeld 392) wird auf die MAT-Position dieser Abbildspur aktualisiert (Schritt 498).
  • Falls der empfangene Satz ein "StopUpdaters"-Satz ist, wird in Schritt 492 bestimmt, dass der Satz allen Abbildspuren zugeordnet ist. Der StopUpdaters-Satz wird in alle Abbildspurpuffer für jede Abbildspur geschrieben, deren MAT-Position (d.h. die MAT-Position des zuletzt auf die Abbildspur geschriebenen Satzes) kleiner ist als die MAT-Position des StopUpdaters-Satzes (AuditRecord.MATpsn). Normalerweise, außer wenn kürzlich ein Empfängerfehler aufgetreten ist, wird der StopUpdaters-Satz auf jede Abbildspur geschrieben werden. Als Nächstes werden alle Abbildspurpufter, in die der StopUpdaters-Satz geschrieben wurde, auf die Platte ausgespült, und die korrespondierenden Abbildspurkontextsätze werden aktualisiert und auf Platte dauerhaft gespeichert. Sobald der Empfängerprozess erkennt, dass der Cache der Abbildspur ausgespült ist und die Kontextsatzsicherungen abgeschlossen sind, erhöht der Empfänger den Zählwert Receiver.StopUpdatersCnt 391 in seinem Kontextsatz und speichert den Empfängerkontextsatz dauerhaft auf Platte. Durch Folgen dieser Schritt sichert der Empfänger ab, dass (A) jeder StopUpdaters-Satz in alle Abbildspuren dauerhaft gespeichert wird, und dass (B) der Zählwert Receiver.StopUpdatersCnt 391 für jeden distinkten StopUpdaters-Satz einmal und genau einmal erhöht wird.
  • Falls der Satz ein Transaktionszustandssatz ist, wird er in der Hauptabbildspur gespeichert (Schritt 498). Falls der Satz ferner ein Transaktionszustandssatz anders als ein Durchführungssatz oder Stornierungssatz ist, aktualisiert der Empfängerprozess auch die gegenwärtige SysTxList durch Aufrufen der UpdateCurrentSysTxList-Prozedur (Schritt 498), die im Folgenden mit Bezug auf 8K in größerem Detail beschrieben wird. Diese Prozedur aktualisiert die gegenwärtige SysTxList, falls notwendig, um so den vollen Bereich der Transaktions-ID für aktive Transaktionen während der gegenwärtigen TMP-Kontrollpunktperiode anzuzeigen.
  • Falls der empfangene Satz ein TMP-Kontrollpunktsatz ist, wird in Schritt 492 bestimmt, dass der Satz der MIT zugeordnet ist, wohin er in Schritt 498 geschrieben wird. Falls ferner der empfangene Satz ein TMP-Kontrollpunktsatz ist, vertauscht der Empfängerprozess die SysTxList-Zeiger und macht damit die gegenwärtige SysTxList zur vorigen SysTxList, und macht die vorige SysTxList zur gegenwärtigen SysTxList. Ferner wird die gegenwärtige SysTxList gelöscht, um so nur Null-Werte zu speichern (Schritt 498).
  • Falls das Speichern eines Prüfsatzes in einen Abbildspurpuffer einen 4-KByte-Block in dem Abbildspurpuffer zum Überlauf bringen würde (Schritt 504), wird der gesamte Abbildspurpuffer bis zum letzten 4-KByte-Block in der zugeordneten Abbildspurdatei dauerhaft gespeichert (Schritt 508) durch Aufrufen der FlushImageTrail-Prozedur (siehe 8H, 8I und 8J).
  • Falls ein 4-KByte-Block gefüllt wurde, setzt die Prozedur einen neuen 4-KByte-Block entweder in demselben Puffer ein, falls Platz für einen anderen 4-KByte-Block ist, oder in dem anderen Puffer für die Abbildspur, falls der gegenwärtige Puffer voll ist. In jedem Fall wird die folgende Information in dem Blockkopf für den neuen Block gespeichert: die Position des Blocks in der Abbildspurdatei, die gegenwärtige MIT-Dateiposition (welche die MIT-Datei- und Blockkopfposition ist, die dem zuletzt zum MIT-Nachrichtenpuffer geschriebenen Satz zugeordnet ist), einen Zeiger auf den ersten Satz (falls es einen gibt), dessen Anfang in dem 4-KByte-Block liegt, und die MAT-Position des Satzes, der unmittelbar nach dem Blockkopf liegt (siehe frühere Diskussion von 7D). Dann ist der Prozess der Speicherung des gegenwärtigen Prüfsatzes in den Abbildspurpuffer abgeschlossen (Schritt 512) und die Verarbeitung des nächsten Prüfsatzes (falls vorhanden) in dem empfangenen Nachrichtenpuffer beginnt mit Schritt 490.
  • Falls der empfangen Nachrichtenpuffer leer war (Schritt 520), bestimmt der Empfängerprozess die höchste der MAT-Positionen, die in den Kontextsätzen für alle Abbildspuren gespeichert ist, welche gleich der MAT-Position des zuletzt von dem Extraktorprozess empfangenen Prüfsatzes in dem letzten Nachrichtenpuffer ist, welcher irgendwelche Prüfsätze enthielt. Dann wird ein "RDF-Kontrollsatz" in alle Abbildspurpuffer geschrieben (Schritt 524). Der RDF-Kontrollsatz bezeichnet (A) die bestimmte höchste MAT-Position und (B) den Zeitstempelwert in dem empfangenen Nachrichtenpufferkopf.
  • Falls der empfangene Nachrichtenpuffer nicht leer war (Schritt 520), aber falls eine oder mehrere Abbildspuren keine Prüfsätze von dem gegenwärtigen Nachrichtenpuffer erhielt (Schritt 526), bestimmt der Empfängerprozess die höchste der MAT-Positionen, die in den Kontextsätzen für alle anderen Abbildspuren gespeichert sind (Schritt 528), welche gleich der MAT-Position des zuletzt von dem Extraktorprozess empfangenen Prüfsatzes in dem gegenwärtigen Nachrichtenpuffer ist. Dann wird ein "RDF-Kontrollsatz" in jeden Abbildspurpuffer geschrieben, der keinen Prüfsatz erhielt (Schritt 530). Der RDF-Kontrollsatz bezeichnet (A) die bestimmte höchste MAT-Position und (B) den Zeitstempelwert in dem empfangenen Nachrichtenpufferkopf.
  • Falls das Ersatzsystem im StopUpdatersAtTimestamp-Mode ist und der letzte Prüfsatz in dem Puffer einen Zeitstempel hat, der größer oder gleich dem Wert StopTS ist, dann führt der Empfängerprozess die folgende Folge von Aufgaben durch (Schritt 532). Er spült alle Abbildspurpuffer auf die Platte und sichert dauerhaft die Abbildspurkontextsätze. Er kopiert das NumNode-Feld und die vorige SysTxList (d.h. für das letzte abgeschlossene TMP-Kontrollintervall) in den Empfängerkontextsatz und speichert den Empfängerkontextsatz dauerhaft auf die Platte. Schließlich wird der Empfänger eine Anforderungsnachricht von dem Löscher empfangen haben, und der Empfänger antwortet auf die Anforderung mit einer Nachricht, welche die Dateiende-Positionen für alle Abbildspuren umfasst und welche den Löscherprozess befähigt, die Rückabwicklungsliste zu erzeugen (siehe 12).
  • Mit Bezug auf 8G sendet der Empfängerprozess dann, wenn eine Grenzposition von einem der Aktualisiererprozesse empfangen wurde (Schritt 540), eine Antwortnachricht an den anfordernden Aktualisiererprozess mit der Grenzpositionsadresse für die Abbildspur des Aktualisierers (Schritt 544).
  • Aktualisierung der SysTxList-Tabelle
  • Mit Bezug auf 7G und 8K wird die UpdateCurrentSysTxList-Prozedur 550 durch den Empfängerprozess aufgerufen, um jeden logischen Prüfsatz und jeden Transaktionszustandssatz anders als ein Durchführungssatz oder ein Stornierungssatz zu verarbeiten. Der Empfängerprozess übergibt gerade die Transaktions-ID (TxID) des gerade verarbeiteten Satzes an diese Prozedur (Schritt 551). Die Prozedur verwendet das Knotenfeld der empfangenen TxID, um in dem NumNode-Feld den Schlitz der SysTxList aufzufinden, der diesem Knoten zugeordnet ist. (Schritt 552). Falls dem Knoten kein Schlitz zugewiesen ist (Schritt 553-Ja), wird dem Knoten ein Schlitz zugewiesen durch Speichern des Nächster-Schlitz-Wertes in dem passenden Eintrag des NumNode-Felds und dann durch Erhöhen von des Wertes von Nächster-Schlitz (Schritt 554).
  • Die niedrigen und hohen Folgenummern für den Knoten und Prozessor, die der empfangenen Transaktions-ID zugeordnet sind, wird aus der SysTxList ausgelesen (Schritt 555), (d.h. in einem Schlitz und Unterschlitz von SysTxList für diesen Knoten und Prozessor), und wird dann mit dem Wert des Seq#-Felds der empfangenen Transaktions-ID verglichen. Falls das Seq#-Feld der empfangenen Transaktions-ID kleiner als die niedrige Folgenummer ist, die in der SysTxList für diesen Knoten und Prozessor gespeichert ist, wird die niedrige Folgenummer ersetzt durch den Wert des Seq#-Felds der empfangenen Transaktions-ID (Schritt 556). Falls auf ähnliche Weise das Seq#-Feld der empfangenen Transaktions-ID größer als die hohe Folgenummer ist, die in der gegenwärtigen SysTxList für diesen Knoten und Prozessor gespeichert ist, wird die hohe Folgenummer ersetzt durch den Wert des Seq#-Felds der empfangenen Transaktions-ID (Schritt 557). Falls die niedrige Folgenummer und die hohe Folgenummer, die in der SysTxList gespeichert sind, Null sind, wird das Seq#-Feld der empfangenen Transaktions-ID in beide Felder gespeichert (Schritt 558).
  • Detaillierte Beschreibung des Aktualisiererprozesses
  • Die von jedem Aktualisiererprozess 134 in der bevorzugten Ausführungsform verwendeten Hauptdatenstrukturen sind in 9 gezeigt. Jeder Aktualisiererprozess speichert einen Kontextsatz 570 auf einer periodischen Basis (z.B. einmal alle 2 bis 10 Minuten, wobei 5 Minuten bevorzugt sind) dauerhaft auf einer nicht flüchtigen (Platten-)Speichervorrichtung. Wie in 9 gezeigt, umfasst der Aktualisiererkontextsatz:
    • – eine Redo-Restartposition 571, welche die Position des Satzes bezeichnet, der dem letzten, von dem Aktualisierer verarbeiteten Abbildspursatz unmittelbar folgt, vor der letzten Aktualisiererkontextsatzsicherungsoperation während eines Redo-Passes;
    • – eine Undo-Restartposition 572, welche den nächsten Abbildspursatz bezeichnet, der während eines Undo-Passes nach der letzten Aktualisiererkontextsatzsicherungsoperation zu verarbeiten ist;
    • – einen StopUpdaterCompleted-Merker 573, welcher gesetzt wird, wenn der Aktualisierer die Operationen als Reaktion auf das Lesen eines StopUpdaters-Satzes angehalten hat;
    • – einen StopUpdateToTimeCompleted-Merker 574A, welcher gesetzt wird, wenn der Aktualisierer die Operationen als Reaktion auf das Lesen eines StopUpdatersAtTimestamp-Satzes angehalten hat;
    • – einen Übernahme-abgeschlossen-Merker 574B, welcher gesetzt wird, wenn der Aktualisierer die Verarbeitung aller Sätze in seiner Abbildspur während einer RDF-Übernahmeprozedur abgeschlossen hat;
    • – ein Pass-Typ-Indikator 574C, der anzeigt, ob die Aktualisierer einen Redo-Pass oder einen Undo-Pass durchführen (wie im Folgenden erläutert);
    • – eine Endzeit-Position 574D, welche den letzten Satz am Ende eines Redo-Passes anzeigt, während eine StopUpdatersAtTimestamp-Operation durchgeführt wird; und
    • – eine Startzeit-Position 574E, welche den letzten Satz anzeigt, der während eines Undo-Passes rückabzuwickeln ist, und somit den ersten Satz anzeigt, der (für eine Redo-Operation) zu verarbeiten ist, wenn der Aktualisierer nach Abschluss einer StopUpdatersAtTimestamp-Operation einen Restart durchführt.
  • Jeder Aktualisierer speichert auch in flüchtigem Speicher:
    • – eine gegenwärtige Abbildspurposition 575;
    • – eine lokale Transaktionszustandstabelle;
    • – einen letzten RTD-(relative Zeitverzögerung)-Zeitstempelwert 577, der gleich ist dem letzten RTD-Zeitstempel eines von dem Aktualisierer verarbeiteten Abbildspursatzes;
    • – eine Grenzposition 578, eine Abbildspurdateiposition;
    • – ein Notizfeld 579 für die Verarbeitung von Prüfsätzen;
    • – einen Übernahme-Mode-Merker 579A für die Anzeige, ob sich das RDF-System in Übernahme-Mode befindet;
    • – einen Stopp-Zeitstempel 579B für die Bezeichnung der Zeitstempelgrenze bei Transaktionsaktualisierungen, die von dem Aktualisierer einzubringen sind;
    • – einen Pass-Typ-Wert 579C, der anzeigt, ob der Aktualisierer einen Redo-Pass oder einen Undo-Pass durchführt; und
    • – eine Endzeit-Position 579D und eine Startzeit-Position 579E für die Markierung der Endposition und der Startposition in der Abbildspur für einen Undo-Pass.
  • Der RTD-Zeitstempelwert 577 wird von der im Folgenden diskutierten StopUpdatersAtTimestamp-Prozedur ausgegeben. Zusätzlich ist er zugänglich für Prozeduren, die im Auftrag des Monitorprozesses 140 ausgeführt werden für die Überwachung, wie weit die Aktualisierer dem TM/MP 202 nachlaufen, und somit zur Abschätzung, wie lang das RDF-System 220 brauchen würde, damit die Ersatzdatenbank 124 zur Hauptdatenbank 108 aufschließen würde, wenn alle Transaktionen auf dem Hauptsystem stoppen würden.
  • Mit Bezug auf 10A bis 10F arbeiten die Aktualisiererprozesse 134 wie folgt.
  • Mit Bezug auf 10A wird die Aktualisierer-Startprozedur 600 aufgerufen, wann immer ein Aktualisiererprozess 134 gestartet wird. Die Aktualisierer-Startprozedur beginnt mit der Durchführung einer "statischen Initialisierung" des Aktualisiererprozesses (Schritt 602), was bedeutet, dass alle vom Aktualisiererprozess verwendeten, statischen Datenstrukturen (wie einer Umwertetabelle von Hauptdatenträgern auf Ersatzdatenträger) zugewiesen und initialisiert werden. Die Startprozedur erzeugt dann einen Ersatzprozess (Schritt 604). Dann wird eine Prüfpunktoperation durchgeführt, in der ein Übernahmeort an den Ersatzaktualisierer prozess übertragen wird (Schritt 606). Der Übernahmeort ist im Wesentlichen eine Programmadresse und in der bevorzugten Ausführungsform ist der Übernahmeort die Programmadresse, an der die Ausführung der Aktualisierer-flüchtige-Initialisierungsprozedur 610 beginnt. Schließlich ruft die Aktualisierer-Startprozedur die Aktualisierer-flüchtige-Initialisierungsprozedur 610 auf (Schritt 608).
  • Mit Bezug auf 10B wird die Aktualisierer-flüchtige-Initialisierungsprozedur 610 während des Starts durch die Aktualisierer-Startprozedur 600 aufgerufen. Die Aktualisierer-flüchtige-Initialisierungsprozedur beginnt mit Lesen des letzten gespeicherten Aktualisiererkontextsatzes von Platte und seiner Verwendung als der gegenwärtige Aktualisiererkontextsatz in flüchtigem Speicher (Schritt 612). Dann weist die Aktualisierer-flüchtige-Initialisierungsprozedur alle vom Aktualisiererprozess verwendeten, flüchtigen Datenstrukturen zu und initialisiert sie, einschließlich dem Notizfeld 579 (Schritt 614). Dann sendet die Aktualisierer-flüchtige-Initialisierungsprozedur eine Grenzpositionsanforderungsnachricht an den Empfänger und speichert den Grenzpositionswert in der sich ergebenden Antwortnachricht in seinem lokalen Grenzpositionsregister 578 (Schritt 616).
  • Falls der StopUpdateToTimeCompleted-Merker in dem Aktualisiererkontextsatz gesetzt ist (Schritt 617), wird der Merker zurückgesetzt, die Redo-Restartposition wird auf die Startzeit-Position in dem Aktualisiererkontextsatz gesetzt und Plattenfehler werden unterdrückt, bis der Aktualisierer die Endzeit-Position in der Abbildspur des Aktualisierers erreicht (Schritt 618).
  • Schließlich ruft die Aktualisierer-flüchtige-Initialisierungsprozedur die Hauptaktualisiererprozedur 620 auf (Schritt 619).
  • Aktualisierer-Redo-Pass
  • Die Aktualisierer haben zwei Operationstypen: einen Redo-Pass (Aktualisierung) und einen Undo-Pass (Stornierung, Rückabwicklung). Der Redo-Pass ist der normale Operationsmode, in dem Aktualisierungsprüfsätze und Rückabwicklungsprüfsätze auf einen Ersatzdatenträger eingebracht werden. Der Undo-Pass wird benutzt für die Beseitigung aller Daten bankveränderungen, die durch unvollständige Transaktionen verursacht wurden. Der Redo-Pass (d.h. die normale Operation) wird zuerst erläutert.
  • Beim Einbringen von Datenbankaktualisierungen und Rückabwicklungen auf einem Ersatzdatenträger führt die Hauptaktualisierungsprozedur 620 Transaktionen aus, die unterschiedlich sind von den Transaktionen, welche auf dem Hauptsystem durchgeführt werden. Insbesondere behandelt der Aktualisierer alle Operationen, die er während einer eingestellten Zeitperiode durchführt, als eine Transaktion. Ein Zeitglied wird am Beginn einer jeden Aktualisierertransaktion eingestellt. Wenn das Zeitglied abläuft, wird die Aktualisierertransaktion durchgeführt, was bewirkt, dass alle Aktualisierungen auf dem Ersatzdatenträger, die während der Transaktion eingebracht wurden, permanent gemacht werden.
  • Die Datenbankveränderungen, die durch die Aktualisierer auf die Ersatzdatenbank eingebracht wurden, werden in derselben Verarbeitungsumgebung durchgeführt wie Transaktionen auf dem Hauptsystem. Somit werden alle Datenbankveränderungen, die durch einen Aktualisierer eingebracht werden, in Prüfsätzen reflektiert, die durch das TMF-System auf der Ersatzdatenbank erzeugt werden. Wann immer ein Aktualisierer eine Aktualisierung mit einem Prüfsatz durchführt, ersetzt er auch die Transaktions-ID in dem Prüfsatz mit der Transaktions-ID für die Aktualisierertransaktion, so dass der Plattenprozess, welcher die Datenbankaktualisierung durchführt, konventionelle Durchführungs-/Stornierungslogik auf die Aktualisierertransaktionen anwenden kann.
  • Mit Bezug auf 10C bis 10F umfasst die Hauptaktualisiererprozedur 620 eine Unterprozedur 630 für das Sichern des Aktualisiererkontextsatzes. Diese Unterprozedur wird aufgerufen, (A) wann immer eine vordefinierte Zeitspanne seit dem Start der gegenwärtigen Aktualisierertransaktion verstrichen ist, und (B) zu verschiedenen anderen Zeiten wie dann, wenn die Operation des Aktualisierers gestoppt wird. In einer bevorzugten Ausführungsform läuft das Aktualisierertransaktionszeitglied einmal alle fünf Minuten ab.
  • Der erste Schritt 632 der Aktualisiererkontextsicherungsprozedur 630 ist, die gegenwärtige Aktualisierertransaktion durchzuführen. Dies macht alle Datenbankveränderungen permanent, die in die Ersatzdatenbank während der gegenwärtigen Aktualisierertransaktion eingebracht wurden. Dann speichert die Prozedur die gegenwärtige Abbildspurposition in der Redo-Restartposition im Aktualisiererkontextsatz, falls der Aktualisierer einen Redo-Pass durchführt. Falls der Aktualisierer einen Undo-Pass durchführt, speichert er die gegenwärtige Abbildspurposition in der Undo-Restartposition im Aktualisiererkontextsatz (Schritt 633). Der Aktualisiererkontextsatz 570 wird dann auf der Platte unter Verwendung einer Schreiboperation mit Warten dauerhaft gespeichert, um so sicherzustellen, dass der Kontextsatz dauerhaft gesichert ist, bevor eine weitere Operation von dem Aktualisierer durchgeführt werden kann. Auch sendet der Aktualisierer eine Löschanforderung an den Löscherprozess, falls mindestens eine vorbestimmte Zeitspanne (z.B. 5 Minuten) verstrichen ist, seit die letzte Anforderung gesendet wurde (Schritt 635). Die Löschanforderung umfasst die SysTxList von der Abbildspurdatei, welche gegenwärtig von dem Aktualisierer verarbeitet wird, und fordert den Löscherprozess auf, Abbildspurdateien zu löschen, die von dem Aktualisierer nicht länger benötigt werden.
  • Mit Bezug auf 10D und 10E ist die Hauptaufgabe der Hauptaktualisiererprozedur 620, Prüfabbildsätze in seiner Abbildspur zu verarbeiten. Wenn die Hauptaktualisiererprozedur zuerst eine Redo-Operation beginnt, setzt sie das Aktualisierertransaktionszeitglied zurück und startet es, und startet eine neue Aktualisierertransaktion (Schritt 621). Die Transaktions-ID für die Aktualisierertransaktion wird einem Prüfpunkt im Ersatzaktualisiererprozess unterzogen. Falls der Hauptaktualisierer ausfällt, verwendet der Ersatzaktualisierer die Transaktions-ID, um zu bestimmen, wann der Plattenprozess den Abbruch der Aktualisierertransaktion beendet hat, welche zuletzt von dem Hauptaktualisiererprozess durchgeführt wurde. Wenn der Plattenprozess die Rückabwicklung aller durch die Aktualisierertransaktion eingebrachten Datenbankveränderungen abgeschlossen hat, nimmt dann der Ersatzaktualisiererprozess die Verarbeitung von Prüfsätzen in der Abbildspur an der Redo-Restartposition (oder der Undo-Restartposition im Fall eines Undo-Passes) wieder auf.
  • In Schritt 622 liest die Hauptaktualisiererprozedur den nächsten Prüfabbildsatz in der Abbildspur, falls vorhanden, und aktualisiert ihren lokal gespeicherten "letzten RTD-Zeitstempel"-Wert 577 mit dem RTD-Zeitstempel aus dem Prüfabbildsatz. Falls der Stop-Zeitstempelwert 579B nicht Null ist, was anzeigt, dass der Aktualisierer eine StopUpdatersAt-Timestamp-Operation durchführt, und der RTD-Zeitstempel in dem Prüfabbildsatz gleich oder größer als der Stop-Zeitstempel ist (Schritt 623), dann führt die Aktualisiererprozedur eine Menge von Schritten zum Stoppen des Aktualisierers aus (Schritt 625). Insbesondere wird:
    • – die Endzeit-Position auf die gegenwärtige Abbildspurposition eingestellt;
    • – das Pass-Typ-Feld (579C, 9) in dem Aktualisiererkontextfeld auf Undo gesetzt;
    • – der Aktualisiererkontextsatz gesichert (siehe 10C); und
    • – führt der Aktualisierer den Aktualisierer-Undo-Pass durch (im Folgenden mit Bezug auf 14A und 14B beschrieben.
  • Falls der Stop-Zeitstempelwert Null ist oder der RTD-Zeitstempel des gegenwärtigen Prüfsatzes kleiner als der Stop-Zeitstempel ist (Schritt 623-Nein), dann beginnt die Hauptaktualisiererprozedur mit der normalen Verarbeitung des in Schritt 622 gelesenen Abbildspursatzes.
  • Falls der gerade gelesene Prüfsatz ein "RDF-Kontroll"-Satz ist, ist keine weitere Verarbeitung dieses Satzes erforderlich, und die Verarbeitung wird mit dem nächsten Prüfsatz wieder aufgenommen (Schritt 622).
  • Falls der Prüfsatz ein "StopUpdaters"-Satz ist, wird der StopUpdaterCompleted-Merker 574 in dem Aktualisiererkontextsatz 570 auf TRUE gesetzt (Schritt 640), und die Aktualisiererkontextsicherungsprozedur 620 aufgerufen (Schritt 642). Der StopUpdaterCompleted-Merker 574 wird von dem Monitorprozess bei der nächsten Start-RDF- oder Start-Aktualisierer-Operation gelesen, um sicherzustellen, dass alle Aktualisierer gestoppt sind und dass alle ihre Abbildspuren bis zum StopUpdaters-Satz verarbeitet haben (im Gegensatz zum Stoppen aufgrund eines Fehlers). Dann wird der Ersatzaktualisiererprozess beendet und der Aktualisiererprozess beendet sich ebenfalls (Schritt 644). Der Aktualisiererprozess wird wieder starten, nachdem der Bediener des RDF-Systems auf dem fernen Ersatzsystem die DDL-Operation durchführt, welche den StopUpdaters-Prüfsatz erzeugte, und dann entweder das "Start-Aktualisierer"-Kommando oder das Übernahme-Kommando eingibt.
  • Falls der gerade gelesene Prüfsatz ein Aktualisierungssatz oder ein Rückabwicklungssatz ist, wird eine Wiederholung der Aktualisierungs- oder der Rückabwicklungsoperation gegenüber der Ersatzdatenbankdatei initiiert (Schritt 646).
  • Wenn der Versuch des Lesens eines nächsten Prüfsatzes (Schritt 622) einen Prüfsatz an dem oder jenseits des Grenzpositionswertes im Grenzpositionsregister 578 antrifft, wird eine Grenzpositionsanforderungsnachricht an den Empfänger gesendet (Schritt 660), um zu bestimmen, ob die Grenzposition für den Aktualisierer vorgeschoben wurde. Wenn eine Antwortnachricht empfangen wird, wird der Grenzpositionswert in der empfangenen Nachricht mit dem lokal gespeicherten Grenzpositionswert verglichen (Schritt 662). Falls der empfangene Grenzpositionswert nicht größer als der zuvor gespeicherte Grenzpositionswert ist, kann der Aktualisierer keine weiteren Prüfabbildsätze verarbeiten. Folglich wartet der Aktualisierer W Sekunden (Schritt 664), wobei W vorzugsweise ein Wert zwischen 1 und 10 ist und typisch auf 10 gesetzt wird, und sendet dann eine andere Grenzpositionsanforderungsnachricht an den Empfänger (Schritt 660). Dies wird fortgesetzt, bis ein Grenzpositionswert größer als die gegenwärtige Grenzposition vom Empfänger empfangen wird. An diesem Punkt wird der lokal im Grenzpositionsregister 578 gespeicherte Grenzpositionswert durch Grenzpositionswert in der empfangenen Antwortnachricht ersetzt (Schritt 666), und dann wird die Verarbeitung der Prüfabbildsätze in Schritt 622 wieder aufgenommen.
  • RDF-Übernahmeprozedur
  • Mit Bezug auf 11 beginnt die Übernahmeprozedur, wenn ein Bediener des Systems den Übernahme-Merker (399A, 7A und 579A, 9) in dem Empfängerprozess, in den Aktualisierenprozessen und in dem Löscherprozess setzt. Es wird verhindert, dass die RDF-Übernahmeprozedur ausgeführt wird, wenn das Hauptsystem noch arbeitet. Wenn die RDF-Übernahmeprozedur ausgeführt wird, gibt es somit keine weiteren Nachrichtenpuffer mit Prüfabbildsätzen, die der Empfängerprozess vom Extraktorprozess empfängt.
  • Als Reaktion auf die Übernahme-Benachrichtigung schließt der Empfänger alle Verarbeitung zuvor empfangener Nachrichtenpuffer ab (Schritt 720), spült alle Abbildspurpufter auf die Platte, aktualisiert die Grenzpositionen für alle Abbildspuren dementsprechend (Schritt 722) und speichert den Empfängerkontextsatz und die Abbildspurkontextsätze dauerhaft auf die Platte (Schritt 724). Der Löscherprozess reagiert auf die Übernahmebenachrichtigung durch Senden einer Anforderung der Erlaubnis zur Erzeugung einer Rückabwicklungslistendatei an den Empfänger. Wenn die Aktualisierer die Verarbeitung aller Prüfsätze in ihren jeweiligen Abbildspuren beenden, reagieren sie auf ähnliche Weise auf die Übernahmebe nachrichtigung mit dem Senden einer Anforderung der Erlaubnis, einen Undo-Pass durchzuführen.
  • Nach dem Abschluss der Schritte 720, 722 und 724 antwortet der Empfänger auf die Anforderung des Löscherprozesses und ermöglicht ihm, die Undo-Liste zu erzeugen (Schritt 725). Der Löscherprozess erzeugt die Undo-Listendatei (Schritt 726) und gewährt dann die Erlaubnis an die Aktualisierer, einen Undo-Pass durchzuführen (Schritt 727). Die Aktualisierer reagieren durch Umkehrung der Wirkungen aller Aktualisierungsprüfsätze für die Transaktionen in der Undo-Liste. Nach Abschluss des Undo-Passes setzt jeder Aktualisierer seinen Übernahme-abgeschlossen-Merker (574C, 9), speichert seinen Kontextsatz dauerhaft und beendet sich (Schritt 728). Der Aktualisierer-Undo-Pass wird im Folgenden mit Bezug auf 14A und 14B detaillierter diskutiert.
  • Wenn alle Aktualisierer beendet sind, liest der Empfänger die Aktualisiererkontextsätze. Falls jeder Aktualisierer seinen Übernahme-abgeschlossen-Merker gesetzt hat, dann setzt der Empfänger seinen Übernahme-abgeschlossen-Merker (391A, 7A), speichert seinen Kontextsatz dauerhaft und erzeugt eine "RDF-Übernahme-abgeschlossen"-Journalnachricht (die in der Journaldatei für das RDF-System gespeichert wird), welche die MAT-Position des zuletzt gespeicherten Prüfabbildsatzes anzeigt (Schritt 730).
  • Wenn jedoch einer der Aktualisierer vor dem Setzen seines Übernahme-abgeschlossen-Merkers ausfällt, wird der Empfänger dieses erkennen und wird eine korrespondierende RDF-Übernahme-Fehler-Journalnachricht erzeugen, in welchem Fall der Bediener des Systems das RDF-Übernahme-Kommando wieder ausführen muss.
  • Erzeugen der Undo-Liste
  • Es wird bemerkt, dass eine Undo-Liste nicht nur während einer Übernahmeoperation erzeugt wird, sondern auch dann, wenn eine StopUpdatersAtTimestamp-Operation durchgeführt wird.
  • Mit Bezug auf 12 kann die Undo-Liste entweder durch den Empfängerprozess oder durch einen anderen Prozess erzeugt werden. Für den Zweck dieser Erläuterung wird an genommen, dass die Undo-Liste erzeugt wird durch einen Prozess, der hier der Löscherprozess genannt wird. In anderen Ausführungsform jedoch könnte die Undo-Liste durch den Empfängerprozess oder einen anderen Prozess erzeugt werden. Ferner könnte in einigen Ausführungsformen ein Prozess wie der Empfängerprozess die Undo-Liste während einer Übernahmeoperation erzeugen, während ein anderer Prozess wie der Löscherprozess die Undo-Liste während einer StopUpdatersAtTimestamp-Operation erzeugen könnte.
  • In der bevorzugten Ausführungsform fordert der Löscherprozess vom Empfängerprozess die Erlaubnis an, die Undo-Liste zu erzeugen, und wartet dann, bis der Empfängerprozess diese Erlaubnis gewährt (Schritt 749). Der Empfängerprozess gewährt dem Löscherprozess diese Erlaubnis nur nachdem er sicher ist, dass alle vom Löscherprozess benötigte Information dauerhaft gespeichert worden ist.
  • Der Löscherprozess beginnt mit der Erzeugung einer Transaktionszustandstabelle (TST), auf die unter Verwendung einer Hash-Tabelle zugegriffen wird (Schritt 750). Mit Bezug auf 13 ist in der TST für jede Transaktion, für die Information in der Tabelle gespeichert ist, die Transaktions-ID 744 und der Endzustand 746 der Transaktion – soweit bekannt – gespeichert. Insbesondere wird der Transaktionsidentifikator (TxID) einer Transaktion durch eine Hash-Funktion 749 in einen Hash-Tabellenindex gewandelt, und dann enthält ein Eintrag in der Hash-Tabelle entweder an der Index-Position oder nach der Index-Position einen Zeiger auf den TST-Eintrag für diese Transaktion. Die TST 742 wird vorzugsweise mit Einträgen in sequantieller Reihenfolge gefüllt, wobei entweder oben oder unten in der TST begonnen wird.
  • Rückwärtslauf durch die MIT und Einfüllen in die Transaktionszustandstabelle
  • Als Nächstes durchläuft der Löscherprozess die Hauptabbildspur (MIT) rückwärts (Schritt 751). Falls eine Übernahmeoperation durchgeführt wird, liest der Löscherprozess die MIT von ihrem Dateiende aus rückwärts. Falls eine StopUpdatersAtTimestamp-Operation durchgeführt wird, findet der Löscherprozess den Startpunkt für den Rückwärtslauf durch Lesen der MIT rückwärts, bis er einen Prüfsatz liest, dessen Zeitstempel kleiner ist als der Stop-Zeitstempel. Dann beginnt er den Rückwärtslauf mit diesen Satz.
  • In jedem Fall setzt der Löscherprozess mit dem Lesen rückwärts fort, bis er durch ein vollständiges TMP-Kontrollintervall rückwärts gelesen hat. Allgemein bedeutet dies, dass er rückwärts liest, bis er zwei TMP-Kontrollpunktsätze gelesen hat. Die MAT-Position des TMP-Kontrollpunktsatzes, der den Rückwärtslauf abschließt, wird als "EndMAT"-Position gespeichert.
  • Für jeden Transaktionszustandssatz in der MIT, der während dieses Rückwärtslaufs gelesen wird, wird der Transaktionszustand in der Transaktionstabelle als der Endzustand für diese Transaktion nur dann gespeichert, wenn keine Information über die Transaktion zuvor in der Transaktionstabelle gespeichert worden ist (Schritt 751). Mit anderen Worten: nur der letzte Transaktionszustandswert in der MIT wird in der Transaktionstabelle gespeichert. Auch wird dann, wenn der letzte bekannte Zustand für eine Transaktion nicht Durchführen oder Stornieren ist, wird er in der Tabelle als "unbekannt" bezeichnet. Da der Zustand einer jeden aktiven Transaktion durch einen Transaktionszustandssatz während jedes TMP-Kontrollintervall repräsentiert werden muss, außer für Transaktionen, die während dieses TMP-Kontrollintervalls begonnen wurden, wird der Rückwärtslauf alle Transaktionen identifizieren, deren Zustand zu dem Zeitpunkt in dem Hauptsystem bekannt ist, der repräsentiert wird durch den letzten der von dem Ersatzsystem empfangenen Prüfsätze.
  • Als Nächstes durchläuft der Löscherprozess jede der anderen Abbildspuren rückwärts von ihren Enden, bis er einen Satz erreicht, dessen MAT-Position kleiner als die EndMAT-Position ist. Für jeden Abbildspursatz wird bestimmt, ob die korrespondierende Transaktion in der Transaktionszustandstabelle repräsentiert ist. Falls das zutrifft, wird für diesen Satz nichts Weiteres getan. Sonst wird ein neuer Eintrag in der Transaktionszustandstabelle angelegt, und der Zustand der korrespondierenden Transaktion wird in der Tabelle als "unbekannt" eingetragen (Schritt 752). Wenn alle Abbildspurdateien auf diese Weise verarbeitet worden sind, wird die Transaktionszustandstabelle Einträge enthalten für alle Transaktionen, für die (A) mindestens ein Prüfsatz in den Abbildspurdateien ist, und (B) der Ausgang der Transaktion (Durchführen oder Stornieren) unbekannt ist. Der Löscherprozess konstruiert als Nächstes eine kompakte Liste aller Transaktionen in der Transaktionszustandstabelle, deren Zustand als "unbekannt" bezeichnet ist (Schritt 754). Dies wird vorzugsweise erreicht durch Speichern dieser Einträge oben in der Transaktionszustandstabelle, und die sich ergebende Tabelle der Transaktionen wird hier als "komprimierte Transaktions zustandstabelle" benannt. Die Hash-Tabelle für die Transaktionszustandstabelle wird neu aufgebaut, um nur Einträge für Transaktionen zu umfassen, deren Zustand als unbekannt bezeichnet ist, und um auf die restlichen Transaktionen an ihren neuen Stellen zu zeigen.
  • Als Nächstes bestimmt der Löscherprozess die LowWaterMIT-Position (Schritt 756). Dazu liest der Löscherprozess die MIT rückwärts, bis er ein TMP-Kontrollintervall findet, in dem es keine Transaktionszustandssätze für Transaktionen in der komprimierten Transaktionszustandstabelle gibt. Die LowWaterMIT-Position wird auf die MIT-Position des TMP-Kontrollpunktsatzes am Beginn des ersten TMP-Kontrollintervalls gesetzt, das diese Bedingung erfüllt. Alternativ könnte die MAT-Position für diesen TMP-Kontrollpunktsatz behalten werden.
  • Der Löscherprozess erzeugt eine Undo-Datei, hier Undo-Liste oder Undo-Listendatei genannt (Schritt 758), die umfasst:
    • – die LowWaterMIT-Position;
    • – einen Parameter, der die Anzahl der Transaktionen anzeigt, die in der Undo-Liste umfasst werden (welche dieselbe ist wie die Anzahl der Transaktionen, die in der komprimierten Transaktionszustandstabelle bezeichnet sind) und
    • – eine Liste der Transaktions-ID aller Transaktionen in der komprimierten Transaktionszustandstabelle
  • In einer Ausführungsform kann die Undo-Liste als eine Menge von Blöcken gespeichert sein, deren jeder bis zu N (z.B. 510) Transaktions-ID wie auch die LowWaterMIT-Position und einen Indikator der Anzahl der in dem Block aufgeführten Transaktions-ID enthält.
  • Wenn der Löscherprozess die Erzeugung der Undo-Liste beendet hat, setzt er einen UndoListWritten-Merker in seinem Kontextsatz auf TRUE, und speichert seinen Kontextsatz dauerhaft (Schritt 760). Auch reagiert er auf anstehende Anforderungen von den Aktualisierern, um ihnen Erlaubnis zu gewähren, einen Undo-Pass durchzuführen Schritt (762).
  • Falls der Löscherprozess versagt und im Übernahmemode oder im StopUpdatersAtTimestamp-Mode einen Restart ausführt und der UndoListWritten-Merker auf FALSE gesetzt ist, löscht er die Undo-Listendatei (falls eine existiert) und beginnt die Undo-Liste von Neuem aufzubauen.
  • Aktualisierer-Undo-Pass
  • Mit Bezug auf 14A und 14B fordert ein Aktualisierer dann, wenn jeder Aktualisierer seinen Redo-Pass beendet hat, eine Erlaubnis von dem Löscherprozess an, einen Undo-Pass durchzuführen (Schritt 770). Der Löscherprozess reagiert auf diese Anforderung nur nachdem er die Erzeugung der Undo-Liste abgeschlossen hat.
  • Nach dem Empfang solch einer Erlaubnis prüft der Aktualisierer, ob die Undo-Liste leer ist (Schritt 772). Falls die Undo-Liste leer ist, hält er an und beendet den Undo-Pass. Sonst speichert er alle Einträge in einer lokalen Transaktionszustandstabelle (lokale TST), welche im Wesentlichen dieselbe Struktur haben kann wie die in 13 gezeigte Transaktionszustandstabelle, außer dass die Spalte mit dem Endzustand nicht benötigt wird, weil von a n in der Tabelle aufgeführten Transaktionen angenommen wird, dass ihr Endzustand unbekannt ist.
  • Als Nächstes wickelt der Aktualisierer alle den unvollständigen Transaktionen zugeordneten Aktualisierungen rückwärts ab (Schritt 776). Dies wird im Folgenden mit Bezug auf 14B detaillierter beschrieben. Falls als Nächstes das Ersatzsystem im Übernahmemode ist, setzt der Aktualisierer seinen Übernahme-abgeschlossen-Merker (Schritt 777). Falls das Ersatzsystem im StopUpdatersAtTimestamp-Mode ist, setzt der Aktualisierer das Pass-Typ-Feld im Kontextsatz auf Redo-Pass, setzt den StopUpdateToTimeCompleted-Merker auf TRUE und setzt das Startzeitpositionsfeld auf einen Zeiger auf den letzten Abbildspursatz, der durch den Undo-Pass verarbeitet wurde (Schritt 778). Dann speichert der Aktualisierer seinen Kontextsatz (Schritt 779) und beendet den Aktualisiererprozess und den Ersatzaktualisiererprozess (Schritt 779).
  • Mit Bezug auf 14B beginnt der Undo-Pass mit Schritt 780, wobei der Aktualisierer ein Transaktionszeitglied (z.B. ein 5-Minuten-Zeitglied) startet und eine neue Aktualisierertransaktion startet. Dann liest der Aktualisierer seine Prüfabbildspurdatei rückwärts (Schritt 781) und beginnt mit dem letzten Satz, den der Aktualisierer in die Ersatzdatenbank eingebracht hat, bis er einen Blockkopf mit einer in dem Kopf bezeichneten MIT-Position liest (Schritt 782), die kleiner oder gleich der LowWaterMIT ist (Schritt 783).
  • Alle vollständigen Sätze in dem Block mit dieser MIT-Position werden verarbeitet, aber keine früheren Blöcke in der Abbildspur. Für jeden Prüfsatz, der eine Aktualisierung repräsentiert, prüft der Aktualisierer die lokale TST (Schritt 784). Falls die Transaktions-ID für die Transaktion nicht in der lokalen TST ist, wird der Prüfsatz nicht weiter verarbeitet (Schritt 784-Nein). Falls andererseits die Transaktions-ID für die Transaktion in der lokalen TST ist, wird die durch den Prüfsatz repräsentierte Aktualisierung rückgängig gemacht (Schritt 785), und ein korrespondierender Ausnahmesatz in ein Ausnahmejournal geschrieben. Es werden so viele Undo-Operationen ausgeführt, wie während jeder Transaktionszeitgliedperiode als eine einzige Aktualisierertransaktion durchgeführt werden kann. Wenn das Transaktionszeitglied abläuft (Schritt 786), wird die gegenwärtige Aktualisierertransaktion durchgeführt (Schritt 787). Zusätzlich sichert der Aktualisierer seine gegenwärtige Abbildspur-Position in dem Undo-Positionsfeld seines Kontextsatzes und sichert seinen Kontextsatz dauerhaft (Schritt 787).
  • Wenn der Aktualisierer die Verarbeitung aller vollständigen Sätze in einem Abbildspurblock abschließt, dessen Kopf eine MIT-Position bezeichnet, die kleiner oder gleich der LowWaterMIT-Position ist (Schritt 783), wird die gegenwärtige Aktualisierertransaktion durchgeführt und der Undo-Pass beendet (Schritt 788).
  • Detaillierte Erläuterung der StopUpdatersAtTimestamp-Prozedur
  • Falls das Hauptsystem in aktiver Benutzung ist und die Aktualisierer auf dem Ersatzsystem aktiv sind, werden die Datenträger auf dem Ersatzsystem nicht in einem vollständig konsistenten Zustand sein, weil einige Transaktionen nur teilweise auf Platte gespeichert sind. Weil die Aktualisierer in Bezug zueinander asynchron arbeiten, können einige Aktualisierer Prüfsätze, die einigen Transaktionen zugeordnet sind, bereits eingebracht haben, während andere Aktualisierer bisher keine Prüfsätze eingebracht haben, die derselben Menge von Transaktionen zugeordnet sind. Während dieses Problem des "inkonsistenten Zustands" ohne Konsequenz ist für die meisten gelegentlichen Datenbankabrufe (z.B. Durchsuchungen oder nur lesende Abfragen über die Anzahl der Sitzplätze, die auf einem bestimmten Luftlinienflug verfügbar sind), ist das nicht tolerierbar für Aufgaben, die einen konsistenten oder stabilen Zugriff verlangen, wie die Erzeugung monatlicher Berichte und andere wichtige Managementdatenzusammenfassungen, die intern vollständig konsistent sein müssen.
  • Das "StopUpdatersAtTimestamp"-Merkmal der vorliegenden Erfindung bringt die Ersatzdatenbank auf einen konsistenten Zustand, ohne dass der Betrieb des Hauptsystems auf irgendeine Weise betroffen ist. Mit Bezug auf die Schritte 623 und 625 in 10D stoppt der Aktualisierer dann, wenn das StopUpdatersAtTimestamp-Merkmal benutzt wird, das Einbringen von Aktualisierungen, wenn er einen Prüfsatz erreicht, dessen Zeitstempel größer oder gleich dem Stop-Zeitstempel (StopTS) ist. Er setzt auch das Endzeit-Positionsfeld in seinem Kontextsatz auf die gegenwärtige Position in der Abbildspur (d.h. den ersten Satz in der Abbildspur, der nicht in die Ersatzdatenbank eingebracht ist), und setzt das Pass-Typ-Feld auf Undo-Pass. Dann sichert er seinen Kontextsatz, welcher das Ende des Redo-Passes markiert, und führt dann einen Undo-Pass durch.
  • Der Löscherprozess arbeitet im StopUpdatersAtTimestamp-Mode während der Erzeugung der Undo-Liste geringfügig anders als im Übernahmemode. Insbesondere wird beim Rückwärtslauf über die MIT (Schritt 751, 12) jede Transaktion, deren Endzustand einen Zeitstempel hat, der größer als (d.h. später als) der StopTS ist, ein Endzustand von "unbekannt" in der Transaktionszustandstabelle zugeordnet. Dies geschieht, weil der Endzustand dieser Transaktionen wegen des StopTS unbekannt ist.
  • Der Undo-Pass der Aktualisierer wurde oben bereits mit Bezug auf 14A und 14B detailliert beschrieben. Wenn ein Undo-Pass im StopUpdatersAtTimestamp-Mode statt im Übernahmemode durchgeführt wird, beginnt der Rückwärtslauf mit dem letzten Prüfsatz, der in die Ersatzdatenbank eingebracht wurde (welches der Prüfsatz vor der Endzeit-Position ist) statt mit dem Ende der Abbildspur. Auch setzt der Aktualisierer im StopUpdatersAtTimestamp-Mode am Ende des Undo-Passes das Pass-Typ-Feld und das Endzeitfeld, um den Aktualisierer für den Start an der passenden Position und im passenden Mode zu starten, wenn der Systembediener die Aktualisierer einen Restart durchführen lässt.
  • Insbesondere werden dann, wenn der Aktualisierer einen Prüfsatz mit dem RTD-Zeitstempel auf oder nach dem Stop-Zeitstempel zum ersten Mal liest, die folgende Menge von Aktionen durchgeführt:
    • – die Endzeit-Position in dem Aktualisiererkontextsatz wird auf den ersten, nicht verarbeiteten Prüfsatz in der Abbildspur gesetzt; und
    • – das Pass-Typ-Feld im Aktualisiererkontextsatz wird auf Undo-Pass gesetzt.
  • Es wird bemerkt, dass der StopUpdatersAtTimestamp-Mode nur bewirkt, dass die Aktualisierer stoppen, während der Extraktorprozess und der Empfängerprozess weiter Prüfsatzinformation verarbeiten. Auch sichert der Aktualisierer Information in seinem Kontextsatz, um zu garantieren, dass keine Abbildspursätze von den Aktualisierern als Folge einer StopUpdatersAtTimestamp-Operation vermisst werden. die StopUpdatersAtTimestamp-Operation belässt die Aktualisierer vor dem Ausschalten der Aktualisierer bereit, die Verarbeitung aller Prüfabbildsätze zu beginnen, die noch nicht in die Ersatzdatenbank eingebracht sind.
  • Restart von Empfängerprozess und Aktualisiererprozess
  • Wann immer der Empfängerprozess einen Restart durchführt, wie nach einem Systemausfall und nach RDF-Abschalten oder nach einer RDF-Übernahme, wird der Empfängerprozess initialisiert. Nach einem vollständigen RDF-Abschalten führt der Empfängerprozess immer einen Restart aus bevor die Aktualisierer einen Restart ausführen.
  • Jedesmal dann, wenn die Aktualisierer in einem Ersatzsystem einen Restart ausführen, wie nach der Durchführung eines Stop-RDF, StopUpdatersAtTimestamp oder einer RDF-Übernahme, wird jeder Aktualisiererprozess initialisiert und beginnt die Verarbeitung von Abbildspursätzen mit dem Satz, der durch die Redo-Restart-Position (571, 9) in dem Aktualisiererkontextsatz (Schritt 790).
  • Falls der StopUpdateToTimeCompleted-Merker gesetzt ist, dann unterdrückt der Aktualisierer die Erzeugung der Fehlernachrichten, die der Wiederausführung von Aktualisierungen zugeordnet sind, welche bereits in die Ersatzdatenbank eingebracht wurden, bis er einen Prüfsatz liest, dessen MAT-Position größer als die Endzeit-Position ist, und an diesem Punkt wird die Erzeugung von solchen Fehlern freigegeben.
  • Löschen von Abbildspurdateien
  • Allgemein kann eine Abbildspurdatei gelöscht (d.h. permanent entfernt) werden, wenn absolut sicher ist, dass die Datei keine Prüfsätze enthält, die jemals wieder benötigt werden, selbst wenn ein Ausfall in einem Hauptsystem, ein Ausfall in einem Ersatzsystem oder beides vorkommt. Insbesondere darf eine Abbildspur nicht gelöscht werden, wenn sie einen Prüfsatz für eine Transaktion enthält, die nicht vollständig zum Speicher auf dem Ersatzsystem durchgeführt wurde im Fall eines Systemausfalls.
  • Der Zweck der in 7G gezeigten und im Kopf einer jeden Abbildspurdatei gespeicherten Systemtransaktionsliste ist es, den Prozess der Bestimmung zu erleichtern, welche Abbildspurdatei gelöscht werden kann. Dies wird nun detaillierter erläutert.
  • Periodisch, wie etwa alle 5 Minuten, sendet jeder Aktualisierer dem Löscherprozess eine "Löscheranforderungs"-Nachricht, welche eine Kopie der SysTxList am Beginn der Abbildspurdatei umfasst, die gegenwärtig verarbeitet wird (Schritt 633, 10C).
  • Mit Bezug auf 15 wird die Abbildspurlöscherprozedur 800 periodisch aktiviert (Schritt 802), wie etwa einmal jede Stunde. Alternativ kann die Zeit zwischen aufeinander folgenden Aktivierungen der Löscherprozedur von der Menge der Prüfinformation abhängen, die von dem Hauptsystem empfangen wird. Z.B. kann der Löscher aktiviert werden, je früher (A) N Minuten vergangen sind und (B) M Nachrichtenpuffer von dem Hauptsystem empfangen wurden.
  • Der Löscherprozess liest die letzte SysTxList, die von einem jeden Aktualisierer gesendet wurde (Schritt 804), wählt die älteste SysTxList dieser SysTxList aus durch Bestimmen, welche die niedrigsten Transaktions-ID hat, und verwendet die ausgewählte SysTxList als eine globale SysTxList (Schritt 806). Die globale SysTxList kann dieselbe Struktur wie die in 7G haben, oder es kann das hohe Transaktions-ID-Feld weggelassen sein, weil das hohe Transaktions-ID-Feld für jede CPU nicht gebraucht wird.
  • Als Nächstes liest der Löscherprozess jede Abbildspur, beginnt mit der ältesten Datei (Schritt 810) und löscht alle Dateien für diese Abbildspur, welche die vordefinierten Lösch kriterien erfüllen (Schritt 808). Der Löscherprozess ist vorzugsweise konfiguriert, einen vordefinierte minimale Anzahl (RetainCount) von Dateien in jeder Abbildspur zu belassen. Mit anderen Worten: selbst wenn eine Abbildspurdatei sonst verfügbar für das Löschen wäre, wird sie beibehalten, wenn eine Anzahl (RetainCount) oder weniger Dateien in der Abbildspur verbleiben (Schritt 812). In einer bevorzugten Ausführungsform kann die Anzahl RetainCount auf keinen kleineren Wert als 2 gesetzt werden.
  • Der Löscherprozess bestimmt, ob für alle CPU der hohe Transaktions-ID-Wert in der SysTxList in dem Abbildspurdateikopf kleiner ist als der niedrige Transaktions-ID-Wert in der globalen SysTxList (Schritt 814). Wenn das zutrifft und die Abbildspur mindestens die Anzahl RetainCount an Dateien enthält, wird die Datei gelöscht (Schritt 816), und dann wird die nächste Datei in der Abbildspur verarbeitet (Schritt 818). Falls für eine CPU der hohe Transaktions-ID-Wert in der SysTxList in dem Abbildspurdateikopf größer ist als der korrespondierende niedrige Transaktions-ID-Wert in der globalen SysTxList oder ihm gleich ist, kann die Abbildspurdatei Prüfsätze enthalten, die bei einer Übernahmeoperation oder einer StopUpdatersAtTimestamp-Operation benötigt würden, und deshalb kann diese Abbildspurdatei nicht gelöscht werden und die Verarbeitung dieser Abbildspur ist abgeschlossen.
  • Alternativ und dies würde viel mehr Rechenkapazität verbrauchen, werden in Schritt 814 die Prüfsätze in der Abbildspurdatei untersucht, ob einer der Prüfsätze in der Datei eine Transaktions-ID hat, die kleiner ist als die niedrige Transaktions-ID, welche in der globalen SysTxList für die korrespondierende CPU des Hauptsystems spezifiziert ist. Falls die Abbildspurdatei keine solche Prüfsätze enthält, und die Abbildspur mindestens die Anzahl RetainCount an Dateien enthält, wird die Abbildspurdatei entfernt (Schritt 816). Sonst wird die Datei nicht entfernt und die Verarbeitung für diese Abbildspur ist abgeschlossen.
  • Alternative Ausführungsformen
  • Die Aufgaben, die von dem Empfängerprozess, den Aktualisiererprozessen und dem Löscherprozess der bevorzugten Ausführungsform durchgeführt werden, können in anderen Ausführungsformen durch Prozesse ausgeführt werden, die auch andere Aufgaben ausführen oder durch eine unterschiedliche Menge von Prozessen.
  • Die vorliegende Erfindung kann verwirklicht werden als ein Computerprogrammprodukt, welches einen Computerprogrammmechanismus umfasst, der in einem Computer-lesbaren Speichermedium eingebettet ist. Z.B. könnte das Computerprogrammprodukt die Programmmodule für einen oder mehrere Empfängerprozesse, Aktualisiererprozesse und Löscherprozesse enthalten. Diese Programmmodule könnten auf einem CD-ROM, einem magnetischen Plattenspeicherprodukt oder auf irgendeinem Computer-lesbaren Daten- oder Programmspeicherprodukt gespeichert sein. Die Softwaremodule in dem Computerprogrammprodukt können auch elektronisch, über das Internet oder sonstwie durch Übertragung eines Computerdatensignals (in das die Softwaremodule eingebettet sind) auf einer Trägerwelle verteilt werden.
  • Während die vorliegende Erfindung mit Bezug auf einige wenige spezifische Ausführungsformen beschrieben wurden, ist die Beschreibung nur zur Veranschaulichung der Erfindung gedacht, und ist nicht so zu verstehen, dass sie die Erfindung begrenzt. Verschiedene Modifikationen können von den in der Technik bewanderten Personen vorgenommen werden, ohne dass von dem wahren Umfang der Erfindung abgewichen wird, wie durch die angefügten Ansprüche definiert.

Claims (12)

  1. Verfahren zum Betrieb eines Sicherungssystems, um so Datenbankaktualisierungen zu verdoppeln, welche auf einem Primärsystem durchgeführt werden, und das Verfahren umfasst die folgenden Schritte: – Empfangen (132) eines Stroms von Audit-Sätzen von dem Primärsystem (110), wobei die Audit-Sätze umfassen: Audit-Aktualisierungssätze, die Datenbankaktualisierungen bezeichnen, welche durch Transaktionen erzeugt werden, die auf dem Primärsystem ausgeführt werden, und Transaktionszustandssätze, wobei mindestens eine Untermenge der Transaktionszustandssätze ein Durchführungs-/Stornierungsergebnis für eine spezifizierte Transaktion bezeichnet; wobei jeder Audit-Aktualisierungssatz und jeder Transaktionszustandssatz einen Transaktionsidentifikator umfasst, der eine korrespondierende Transaktion auf dem Primärsystem (110) identifiziert; – Speichern der Audit-Aktualisierungssätze in einer oder mehrerer Abbildspuren (136, 138); – Speichern einer jeden der Abbildspuren (136, 138) als eine Sequenz von Abbildspurdateien einschließlich dem Generieren einer neuen Abbildspur jedesmal dann, wenn eine vorangehende Abbildspurdatei einen vordefinierten Zustand erreicht, und dem Speichern einer Kopie der vorangehenden Transaktionstabelle in jeder neuen Abbildspurdatei zu dem Zeitpunkt, an dem die neue Abbildspurdatei erzeugt wird; – für jede Abbildspur (136, 138): Zugreifen auf die und Verarbeiten der Audit-Sätze in der Reihenfolge der Abbildspurdateien für diese Abbildspur; dadurch gekennzeichnet, dass – der Schritt des Empfangs eines Stroms von Audit-Sätzen ferner den Empfang von Zeitintervallsteuerungssätzen umfasst und – das Verfahren ferner die folgenden Schritte umfasst: – Untersuchen der empfangenen Transaktionszustandssätze in einer vordefinierten chronologischen Reihenfolge und für jede Abbildspur Erzeugen einer gegenwärtigen Transaktionstabelle (392), welche einen Bereich von Transaktionsidentifikatoren für Transaktionen repräsentiert, für die es mindestens einen Transaktionszustandssatz zwischen aufeinanderfolgenden Zeitintervallsteuerungssätzen in dem Strom der Audit-Sätze gibt; – Sichern der gegenwärtigen Transaktionstabelle (392) als eine vorangehende Transaktionstabelle und Erzeugen einer neuen gegenwärtigen Transaktionstabelle immer dann, wenn ein Zeitintervallsteuerungssatz empfangen wird; – periodisches Ausführen einer Dateilöschprozedur (808) für das Löschen von nicht länger benötigten Abbildspurdateien, welches umfasst: – Identifizieren einer ältesten Transaktionstabellenkopie (810) aus einer Menge von Transaktionstabellenkopien, deren jede die Transaktionstabellenkopie in der letzten Abbildspurdatei umfasst, auf die für jede der Abbildspuren zugegriffen wird; – Zugreifen auf eine Abbildspurdatei für eine der Abbildspuren (136, 138); – Vergleichen (814) eines ersten Satzes neuester Transaktionsidentifikatoren in der Transaktionstabellenkopie in der zugegriffenen Abbildspurdatei mit einem zweiten Satz ältester Transaktionsidentifikatoren in der identifizierten ältesten Transaktionstabellenkopie und bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  2. Verfahren nach Anspruch 1, wobei der Schritt des periodischen Ausführens einer Dateilöschprozedur umfasst: – Speichern von Information in einer globalen Transaktionstabelle, welche den zweiten Satz ältester Transaktionsidentifikatoren in der identifizierten ältesten Transaktionstabellenkopie umfasst; – für jede Abbildspur (136, 138), für die es mehr als eine vordefinierte (RetainCount) Anzahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind: Ausführen der Schritte des Zugreifens auf eine Abbildspurdatei, des Vergleichens des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren und des bedingten Löschens (816) der zugegriffenen Abbildspurdatei.
  3. Verfahren nach Anspruch 2, wobei der Schritt des periodischen Ausführens einer Dateilöschprozedur umfasst: – für jede Abbildspur (136, 138), für die es mehr als eine vordefinierte (RetainCount) Anzahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind: – Zugreifen auf die Abbildspurdateien in chronologischer Reihenfolge mit Ausnahme der RetainCount Abbildspurdateien, die am wenigsten weit zurückliegen; – für jede zugegriffene Abbildspur: Vergleichen des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren; und – bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  4. Verfahren nach Anspruch 3, wobei der Schritt des periodischen Ausführens einer Dateilöschprozedur umfasst: – für jede Abbildspur (136, 138), für die es mehr als eine vordefinierte (RetainCount) Anzahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind: – Zugreifen auf die Abbildspurdateien in chronologischer Reihenfolge mit Ausnahme der RetainCount Abbildspurdateien, die am wenigsten weit zurückliegen; – für jede zugegriffene Abbildspur: Vergleichen des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren; und – bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz; und – Stoppen des Zugreifens auf die Abbildspurdateien für die Abbildspur, wenn irgendeine der Transaktionsidentifikatoren in dem ersten Satz nicht älter ist als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  5. Computerprogrammprodukt für die Verwendung in einem Verfahren zum Betrieb eines Sicherungssystems, um so Datenbankaktualisierungen zu verdoppeln, welche auf einem Primärsystem durchgeführt werden, und das Computerprogrammprodukt umfasst: – einen Empfängermodul (132), der Instruktionen umfasst für das Empfangen und das Speichern in einem oder mehreren Abbildspuren eines Stroms von Audit-Sätzen, die von dem Primärsystem (110) empfangen werden, wobei die Audit-Sätze umfassen: Audit-Aktualisierungssätze, die Datenbankaktualisierungen bezeichnen, welche durch Transaktionen erzeugt werden, die auf dem Primärsystem ausgeführt werden, und Transaktionszustandssätze, wobei mindestens eine Untermenge der Transaktionszustandssätze ein Durchführungs-/Stornierungsergebnis für eine spezifizierte Transaktion bezeichnet; wobei jeder Audit-Aktualisierungssatz und jeder Transaktionszustandssatz einen Transaktionsidentifikator umfasst, der eine korrespondierende Transaktion auf dem Primärsystem (110) identifiziert; – wobei der Empfängermodul Instruktionen umfasst für das Speichern der Audit-Aktualisierungssätze in einer oder mehrerer Abbildspuren (136, 138); – und wobei der Empfängermodul Instruktionen umfasst für: – das Speichern einer jeden der Abbildspuren (136, 138) als eine Sequenz von Abbildspurdateien einschließlich dem Generieren einer neuen Abbildspur jedesmal dann, wenn eine vorangehende Abbildspurdatei einen vordefinierten Zustand erreicht, und dem Speichern einer Kopie der vorangehenden Transaktionstabelle in jeder neuen Abbildspurdatei zu dem Zeitpunkt, an dem die neue Abbildspurdatei erzeugt wird; – mindestens einen Aktualisierungsmodul (134), der Instruktionen umfasst für das sequentielle Anwenden der durch die Audit-Aktualisierungssätze bezeichneten Datenbankaktualisierungen auf die Sicherungsdatenbank in der Reihenfolge, in der die Audit-Aktualisierungssätze in den Abbildspurdateien (136, 138) gespeichert sind; dadurch gekennzeichnet, dass – der Empfängermodul ferner Instruktionen umfasst für das Empfangen von Zeitintervallsteuerungssätzen und – der Empfängermodul ferner umfasst: – Instruktionen für das Untersuchen der empfangenen Transaktionszustandssätze in einer vordefinierten chronologischen Reihenfolge und für jede Abbildspur Instruktionen für das Erzeugen einer gegenwärtigen Transaktionstabelle (392), welche einen Bereich von Transaktionsidentifikatoren für Transaktionen repräsentiert, für die es mindestens einen Transaktionszustandssatz zwischen aufeinanderfolgenden Zeitintervallsteuerungssätzen in dem Strom der Audit-Sätze gibt; – Instruktionen für das Sichern der gegenwärtigen Transaktionstabelle (392) als eine vorangehende Transaktionstabelle und Erzeugen einer neuen gegenwärtigen Transaktionstabelle immer dann, wenn ein Zeitintervallsteuerungssatz empfangen wird; – wobei das Computerprogrammprodukt eine Dateilöschprozedur (808) für das Löschen von nicht länger benötigten Abbildspurdateien umfasst, wobei die Dateilöschprozedur umfasst: – Instruktionen für das Identifizieren einer ältesten Transaktionstabellenkopie (810) aus einer Menge von Transaktionstabellenkopien, deren jede die Transaktionstabellenkopie in der letzten Abbildspurdatei umfasst, auf die für jede der Abbildspuren zugegriffen wird; – Instruktionen für das Zugreifen auf eine Abbildspurdatei für eine der Abbildspuren (136, 138); – Instruktionen für das Vergleichen (814) eines ersten Satzes neuester Transaktionsidentifikatoren in der Transaktionstabellenkopie in der zugegriffenen Abbildspurdatei mit einem zweiten Satz ältester Transaktionsidentifikatoren in der identifizierten ältesten Transaktionstabellenkopie und bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  6. Computerprogrammprodukt nach Anspruch 5, wobei die Dateilöschprozedur umfasst: – Instruktionen für das Speichern von Information in einer globalen Transaktionstabelle, welche den zweiten Satz ältester Transaktionsidentifikatoren in der identifizierten ältesten Transaktionstabellenkopie umfasst; – für jede Abbildspur (136, 138), für die es mehr als eine vordefinierte (RetainCount) Anzahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind: Instruktionen für das Ausführen der Schritte des Zugreifens auf eine Abbildspurdatei, des Vergleichens des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren und des bedingten Löschens (816) der zugegriffenen Abbildspurdatei.
  7. Computerprogrammprodukt nach Anspruch 6, wobei die Dateilöschprozedur umfasst: – für jede Abbildspur (136, 138), für die es mehr als eine vordefinierte (RetainCount) Anzahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind: – Instruktionen für das Zugreifen auf die Abbildspurdateien in chronologischer Reihenfolge mit Ausnehmen der RetainCount Abbildspurdateien, die am wenigsten weit zurückliegen; – für jede zugegriffene Abbildspur: Instruktionen für das Vergleichen des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren; und – Instruktionen für das bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  8. Computerprogrammprodukt nach Anspruch 7, wobei die Dateilöschprozedur umfasst: für jede Abbildspur (136, 138), für die es mehr als eine vordefinierte (RetainCount) Anrahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind: – Instruktionen für das Zugreifen auf die Abbildspurdateien in chronologischer Reihenfolge mit Ausnehmen der RetainCount Abbildspurdateien, die am wenigsten weit zurückliegen; – für jede zugegriffene Abbildspur: Instruktionen für das Vergleichen des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren; und – Instruktionen für das bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz; und – Instruktionen für das Stoppen des Zugreifens auf die Abbildspurdateien für die Abbildspur, wenn irgendwelche der Transaktionsidentifikatoren in dem ersten Satz nicht älter ist als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  9. Sicherungscomputersystem für die Verdoppelung von Datenbankaktualisierungen, welche auf einem Primärsystem (110) durchgeführt werden, und das Sicherungscomputersystem umfasst: – eine Sicherungsdatenbank (124); – einen Empfängermodul (132), der Instruktionen umfasst für das Empfangen und das Speichern eines Stroms von Audit-Sätzen, die von dem Primärsystem empfangen werden, in einem oder mehreren Abbildspuren, wobei die Audit-Sätze umfassen: Audit-Aktualisierungssätze, die Datenbankaktualisierungen bezeichnen, welche durch Transaktionen erzeugt werden, die auf dem Primärsystem ausgeführt werden, und Transaktionszustandssätze, wobei mindestens eine Untermenge der Transaktionszustandssätze ein Durchführungs-/Stornierungsergebnis für eine spezifizierte Transaktion bezeichnet; wobei jeder Audit-Aktualisierungssatz und jeder Transaktionszustandssatz einen Transaktionsidentifikator umfasst, der eine korrespondierende Transaktion auf dem Primärsystem (110) identifiziert; – wobei der Empfängermodul Instruktionen umfasst für das Speichern der Audit-Aktualisierungssätze in einer oder mehrerer Abbildspuren (136, 138); – und wobei der Empfängermodul umfasst: – Instruktionen für das Speichern einer jeden der Abbildspuren (136, 138) als eine Sequenz von Abbildspurdateien einschließlich Instruktionen für das Generieren einer neuen Abbildspur jedesmal dann, wenn eine vorangehende Abbildspurdatei einen vordefinierten Zustand erreicht, und Instruktionen für das Speichern einer Kopie der vorangehenden Transaktionstabelle in jeder neuen Abbildspurdatei zu dem Zeitpunkt, an dem die neue Abbildspurdatei erzeugt wird; – mindestens einen Aktualisierungsmodul (134), der Instruktionen umfasst für das sequentielle Anwenden der durch die Audit-Aktualisierungssätze bezeichneten Datenbankaktualisierungen auf die Sicherungsdatenbank (124) in der Reihenfolge, in der die Audit-Aktualisierungssätze in den Abbildspurdateien (136, 138) gespeichert sind; dadurch gekennzeichnet, dass – der Empfängermodul ferner Instruktionen umfasst für das Empfangen von Zeitintervallsteuerungssätzen und – der Empfängermodul ferner umfasst: – Instruktionen für das Untersuchen der empfangenen Transaktionszustandssätze in einer vordefinierten chronologischen Reihenfolge und für jede Abbildspur Instruktionen für das Erzeugen einer gegenwärtigen Transaktionstabelle (392), welche einen Bereich von Transaktionsidentifikatoren für Transaktionen repräsentiert, für die es mindestens einen Transaktionszustandssatz zwischen aufeinanderfolgenden Zeitintervallsteuerungssätzen in dem Strom der Audit-Sätze gibt; – Instruktionen für das Sichern der gegenwärtigen Transaktionstabelle (392) als eine vorangehende Transaktionstabelle und Instruktionen für das Erzeugen einer neuen gegenwärtigen Transaktionstabelle immer dann, wenn ein Zeitintervallsteuerungssatz empfangen wird; – das System ferner Einrichtungen umfasst für die Ausführung einer Dateilöschprozedur (808) für das Löschen von nicht länger benötigten Abbildspurdateien, wobei die Dateilöschprozedur umfasst: – Instruktionen für das Identifizieren einer ältesten Transaktionstabellenkopie (810) aus einer Menge von Transaktionstabellenkopien, deren jede die Transaktionstabellenkopie in der letzten Abbildspurdatei umfasst, auf die für jede der Abbildspuren zugegriffen wird; – Instruktionen für das Zugreifen auf eine Abbildspurdatei für eine der Abbildspuren (136, 138); – Instruktionen für das Vergleichen (814) eines ersten Satzes neuester Transaktionsidentifikatoren in der Transaktionstabellenkopie in der zugegriffenen Abbildspurdatei mit einem zweiten Satz ältester Transaktionsidentifikatoren in der identifizierten ältesten Transaktionstabellenkopie und Instruktionen für das bedingte Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  10. Sicherungscomputersystem nach Anspruch 9, wobei die Dateilöschprozedur umfasst: – Instruktionen für das Speichern von Information in einer globalen Transaktionstabelle, welche den zweiten Satz ältester Transaktionsidentifikatoren in der identifizierten ältesten Transaktionstabellenkopie umfasst; – für jede Abbildspur (136, 138), für die es mehr als eine vordefinierte (RetainCount) Anzahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind: Instruktionen für das Ausführen der Schritte des Zugreifens auf eine Abbildspurdatei, des Vergleichens des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren und des bedingten Löschens (816) der zugegriffenen Abbildspurdatei.
  11. Sicherungscomputersystem nach Anspruch 10, wobei die Dateilöschprozedur umfasst: – für jede Abbildspur (136, 138), für die es mehr als eine vordefinierte (RetainCount) Anzahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind: – Instruktionen für das Zugreifen auf die Abbildspurdateien in chronologischer Reihenfolge mit Ausnahme der RetainCount Abbildspurdateien, die am wenigsten weit zurückliegen; – für jede zugegriffene Abbildspur: Instruktionen für das Vergleichen des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren; und – Instruktionen für das bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
  12. Sicherungscomputersystem nach Anspruch 11, wobei die Dateilöschprozedur umfasst: für jede Abbildspur (136, 138), für die es mehr als eine vordefinierte (RetainCount) Anzahl von Abbildspurdateien gibt, die noch nicht gelöscht worden sind: – Instruktionen für das Zugreifen auf die Abbildspurdateien in chronologischer Reihenfolge mit Ausnahme der RetainCount Abbildspurdateien, die am wenigsten weit zurückliegen; – für jede zugegriffene Abbildspur: Instruktionen für das Vergleichen des ersten Satzes von Transaktionsidentifikatoren mit dem zweiten Satz von Transaktionsidentifikatoren; und – Instruktionen für das bedingtes Löschen der zugegriffenen Abbildspurdatei, wenn alle Transaktionsidentifikatoren in dem ersten Satz älter sind als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz; und – Instruktionen für das Stoppen des Zugreifens auf die Abbildspurdateien für die Abbildspur, wenn irgendeiner der Transaktionsidentifikatoren in dem ersten Satz nicht älter ist als die korrespondierenden Transaktionsidentifikatoren in dem zweiten Satz.
DE60018872T 1999-10-14 2000-10-16 System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen Expired - Lifetime DE60018872T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/418,425 US6553392B1 (en) 1999-02-04 1999-10-14 System and method for purging database update image files after completion of associated transactions
US418425 1999-10-14

Publications (2)

Publication Number Publication Date
DE60018872D1 DE60018872D1 (de) 2005-04-28
DE60018872T2 true DE60018872T2 (de) 2005-07-28

Family

ID=23658065

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60018872T Expired - Lifetime DE60018872T2 (de) 1999-10-14 2000-10-16 System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen

Country Status (3)

Country Link
US (1) US6553392B1 (de)
EP (1) EP1093055B1 (de)
DE (1) DE60018872T2 (de)

Families Citing this family (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE295736T1 (de) * 1997-02-21 2005-06-15 Vlaams Interuniv Inst Biotech Verwendung von interleukin-15
US7000144B2 (en) * 1999-12-27 2006-02-14 Canon Kabushiki Kaisha Information management apparatus, information management system, and information management software
US7117197B1 (en) * 2000-04-26 2006-10-03 Oracle International Corp. Selectively auditing accesses to rows within a relational database at a database server
JP3851493B2 (ja) * 2000-06-12 2006-11-29 株式会社日立製作所 データベース検索方法及びデータベース検索システム並びにデータベース検索プログラムを記録したコンピュータ読み取り可能な記録媒体
WO2002013068A1 (en) * 2000-08-04 2002-02-14 Carr Scott Software Incorporated Automatic transaction management
US6701456B1 (en) * 2000-08-29 2004-03-02 Voom Technologies, Inc. Computer system and method for maintaining an audit record for data restoration
US7016920B2 (en) * 2001-05-25 2006-03-21 International Business Machines Corporation Method for tracking relationships between specified file name and particular program used for subsequent access in a database
US6640291B2 (en) * 2001-08-10 2003-10-28 Hitachi, Ltd. Apparatus and method for online data migration with remote copy
US9659292B1 (en) * 2001-08-30 2017-05-23 EMC IP Holding Company LLC Storage-based replication of e-commerce transactions in real time
JP4420325B2 (ja) * 2001-11-01 2010-02-24 ベリサイン・インコーポレイテッド トランザクションメモリ管理装置
US20030088814A1 (en) * 2001-11-07 2003-05-08 Campbell Ralph B. Method and apparatus for logging file system operations
US20040201689A1 (en) * 2002-03-21 2004-10-14 Angelica Quintana Method and system for recording a history of an image file history
US7844577B2 (en) * 2002-07-15 2010-11-30 Symantec Corporation System and method for maintaining a backup storage system for a computer system
US7103619B1 (en) * 2002-09-26 2006-09-05 Unisys Corporation System and method for automatic audit data archiving within a remote database backup system
US20050131969A1 (en) * 2002-10-01 2005-06-16 Fujitsu Limited Database duplicating method, database duplicating apparatus, database creating method, and database creating apparatus
US7827362B2 (en) 2004-08-24 2010-11-02 Symantec Corporation Systems, apparatus, and methods for processing I/O requests
US7730222B2 (en) * 2004-08-24 2010-06-01 Symantec Operating System Processing storage-related I/O requests using binary tree data structures
US7904428B2 (en) 2003-09-23 2011-03-08 Symantec Corporation Methods and apparatus for recording write requests directed to a data store
US7725760B2 (en) 2003-09-23 2010-05-25 Symantec Operating Corporation Data storage system
US7239581B2 (en) * 2004-08-24 2007-07-03 Symantec Operating Corporation Systems and methods for synchronizing the internal clocks of a plurality of processor modules
US7631120B2 (en) * 2004-08-24 2009-12-08 Symantec Operating Corporation Methods and apparatus for optimally selecting a storage buffer for the storage of data
US7991748B2 (en) 2003-09-23 2011-08-02 Symantec Corporation Virtual data store creation and use
US7287133B2 (en) * 2004-08-24 2007-10-23 Symantec Operating Corporation Systems and methods for providing a modification history for a location within a data store
US7409587B2 (en) * 2004-08-24 2008-08-05 Symantec Operating Corporation Recovering from storage transaction failures using checkpoints
US7577806B2 (en) 2003-09-23 2009-08-18 Symantec Operating Corporation Systems and methods for time dependent data storage and recovery
US7296008B2 (en) * 2004-08-24 2007-11-13 Symantec Operating Corporation Generation and use of a time map for accessing a prior image of a storage device
US7818745B2 (en) 2003-09-29 2010-10-19 International Business Machines Corporation Dynamic transaction control within a host transaction processing system
CN1922622A (zh) * 2004-02-26 2007-02-28 西门子医疗健康服务公司 处理审计记录的系统和方法
US20050216532A1 (en) * 2004-03-24 2005-09-29 Lallier John C System and method for file migration
US7373554B2 (en) * 2004-09-24 2008-05-13 Oracle International Corporation Techniques for automatic software error diagnostics and correction
US7499954B2 (en) 2004-11-01 2009-03-03 International Business Machines Corporation Consistent reintegration of a failed primary instance
US7424499B2 (en) * 2005-01-21 2008-09-09 Microsoft Corporation Lazy timestamping in transaction time database
US7506202B1 (en) 2005-02-08 2009-03-17 Symantec Operating Corporation Compression of temporal dimension in a temporal storage device
US8005795B2 (en) * 2005-03-04 2011-08-23 Emc Corporation Techniques for recording file operations and consistency points for producing a consistent copy
WO2006096339A2 (en) * 2005-03-04 2006-09-14 Emc Corporation Checkpoint and consistency markers
US7310716B2 (en) * 2005-03-04 2007-12-18 Emc Corporation Techniques for producing a consistent copy of source data at a target location
US7613743B1 (en) * 2005-06-10 2009-11-03 Apple Inc. Methods and apparatuses for data protection
CN101313279A (zh) * 2005-10-14 2008-11-26 塞门铁克操作公司 一种在数据存储器中用于时间线压缩的技术
US7467169B2 (en) 2005-10-31 2008-12-16 Network Appliance, Inc. Circular and bi-directional mirroring of flexible volumes
US20070113031A1 (en) * 2005-11-16 2007-05-17 International Business Machines Corporation Memory management system and method for storing and retrieving messages
US8799882B2 (en) * 2005-12-07 2014-08-05 Microsoft Corporation Compiler support for optimizing decomposed software transactional memory operations
US7747565B2 (en) * 2005-12-07 2010-06-29 Microsoft Corporation Garbage collector support for transactional memory
US9009115B2 (en) 2006-08-04 2015-04-14 Apple Inc. Restoring electronic information
US8060482B2 (en) * 2006-12-28 2011-11-15 Intel Corporation Efficient and consistent software transactional memory
US8069141B2 (en) * 2007-03-12 2011-11-29 Microsoft Corporation Interfaces for high availability systems and log shipping
US7631214B2 (en) * 2007-05-31 2009-12-08 International Business Machines Corporation Failover processing in multi-tier distributed data-handling systems
US8307004B2 (en) 2007-06-08 2012-11-06 Apple Inc. Manipulating electronic backups
US20080307017A1 (en) 2007-06-08 2008-12-11 Apple Inc. Searching and Restoring of Backups
US8010900B2 (en) 2007-06-08 2011-08-30 Apple Inc. User interface for electronic backup
US8140483B2 (en) * 2007-09-28 2012-03-20 International Business Machines Corporation Transaction log management
US20090204648A1 (en) * 2008-02-11 2009-08-13 Steven Francie Best Tracking metadata for files to automate selective backup of applications and their associated data
US8458146B2 (en) * 2008-09-11 2013-06-04 International Business Machines Corporation Accessing data remotely
US8910054B2 (en) 2010-04-14 2014-12-09 Bank Of America Corporation Audit action analyzer
US8984029B2 (en) 2011-01-14 2015-03-17 Apple Inc. File system management
US8943026B2 (en) 2011-01-14 2015-01-27 Apple Inc. Visual representation of a local backup
KR20130040462A (ko) * 2011-10-14 2013-04-24 삼성전자주식회사 휴대용 단말기의 시스템 복원 장치 및 방법
US8949664B2 (en) * 2011-11-18 2015-02-03 Nokia Corporation Method and apparatus for providing information consistency in distributed computing environments
US9251018B2 (en) * 2012-12-19 2016-02-02 International Business Machines Corporation Enhanced recovery of highly available computing systems
GB2514563A (en) * 2013-05-28 2014-12-03 Ibm Selective purging of a log structure
TWI517137B (zh) * 2013-06-05 2016-01-11 晨星半導體股份有限公司 將影像寫入記憶體的方法及其裝置
US9747356B2 (en) * 2014-01-23 2017-08-29 Oracle International Corporation Eager replication of uncommitted transactions
US9633094B2 (en) 2014-04-25 2017-04-25 Bank Of America Corporation Data load process
US10013447B2 (en) 2014-05-29 2018-07-03 Splice Machine, Inc. Transaction execution commitment without updating of data row transaction status
CN107623703B (zh) * 2016-07-13 2021-08-17 中兴通讯股份有限公司 全局事务标识gtid的同步方法、装置及系统
JP7181663B2 (ja) * 2019-01-11 2022-12-01 富士通株式会社 通信装置、通信プログラム、および分散処理方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590274A (en) * 1995-01-23 1996-12-31 Tandem Computers Incorporated Multi-volume audit trails for fault tolerant computers
US5799323A (en) * 1995-01-24 1998-08-25 Tandem Computers, Inc. Remote duplicate databased facility with triple contingency protection
US5740433A (en) * 1995-01-24 1998-04-14 Tandem Computers, Inc. Remote duplicate database facility with improved throughput and fault tolerance
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
US5813009A (en) * 1995-07-28 1998-09-22 Univirtual Corp. Computer based records management system method
US5758150A (en) * 1995-10-06 1998-05-26 Tele-Communications, Inc. System and method for database synchronization

Also Published As

Publication number Publication date
US6553392B1 (en) 2003-04-22
EP1093055A2 (de) 2001-04-18
EP1093055B1 (de) 2005-03-23
DE60018872D1 (de) 2005-04-28
EP1093055A3 (de) 2002-04-03

Similar Documents

Publication Publication Date Title
DE60018872T2 (de) System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen
DE60312746T2 (de) Wiederherstellung nach fehlern in datenverarbeitungsanlagen
DE69917333T2 (de) Übertragung einer Ressource von einem ersten Zwischenspeicher an einen zweiten Zwischenspeicher
US5835915A (en) Remote duplicate database facility with improved throughput and fault tolerance
DE602004006404T2 (de) Flashback-datenbank
US5740433A (en) Remote duplicate database facility with improved throughput and fault tolerance
DE60213867T2 (de) Vorrichtung zur verwaltung von datenreplikation
DE602004005344T2 (de) Verfahren, system und programm zur handhabung eines failover zu einem fernspeicherort
DE69923621T2 (de) Verfahren und Vorrichtung zu korrekten und vollständigen Übertragungen in einem fehlertoleranten verteilten Datenbanksystem
US5794252A (en) Remote duplicate database facility featuring safe master audit trail (safeMAT) checkpointing
DE112010004947B4 (de) Wiederherstellung einer vollständigen Systemsicherung und inkrementeller Sicherungen unter Verwendung von mehreren gleichzeitigen Datenströmen von Einheiten
DE602005001041T2 (de) Speicherauszugssystem
DE60317383T2 (de) Datenwiederherstellungsvorrichtung unter Verwendung von Journaldaten und Identifikationsinformation
DE112005002481T5 (de) Rekonfigurierung einer redundanten Datenspeicherung
DE69724834T2 (de) System für hochverfügbare datenspeicherung mit allgemein-adressiertem speicher
DE602005000819T2 (de) Aufrechterhaltung der konsistenz einer fernkopie unter verwendung von virtualisierung
DE4220198C2 (de) Transaktionsverarbeitungsverfahren für einen digitalen Computer und Transaktionsverarbeitungssystem
DE69911930T2 (de) Hochverfügbare dateiprozessoren
DE602005004166T2 (de) Vorrichtung, system und verfahren zur reinitialisierung einer serialisierung von dateisystemen
US5745753A (en) Remote duplicate database facility with database replication support for online DDL operations
KR100271342B1 (ko) 데이터 베이스에 있어서의 백업실행장치
DE4216871C2 (de) Ausführungsordnen zum Sicherstellen der Serialisierbarkeit verteilter Transaktionen
CA2422176C (en) Method and apparatus for interrupting updates to a database to provide read-only access
DE602005002024T2 (de) Fernkopiersystem und Fernkopierverfahren
DE112011100112B4 (de) Pufferspeicher-platte in blitzkopie-kaskade

Legal Events

Date Code Title Description
8364 No opposition during term of opposition