DE69325004T2 - Verteiltes Datenverarbeitungssystem mit Vervielfältigung von Daten über das System - Google Patents

Verteiltes Datenverarbeitungssystem mit Vervielfältigung von Daten über das System

Info

Publication number
DE69325004T2
DE69325004T2 DE69325004T DE69325004T DE69325004T2 DE 69325004 T2 DE69325004 T2 DE 69325004T2 DE 69325004 T DE69325004 T DE 69325004T DE 69325004 T DE69325004 T DE 69325004T DE 69325004 T2 DE69325004 T2 DE 69325004T2
Authority
DE
Germany
Prior art keywords
data
processor
copy
responsibility
primary copy
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 - Fee Related
Application number
DE69325004T
Other languages
English (en)
Other versions
DE69325004D1 (de
Inventor
Geoffrey C. H. Sharman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB9225435A external-priority patent/GB2262703B/en
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE69325004D1 publication Critical patent/DE69325004D1/de
Application granted granted Critical
Publication of DE69325004T2 publication Critical patent/DE69325004T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2308Concurrency control
    • G06F16/2315Optimistic concurrency control
    • G06F16/2322Optimistic concurrency control using timestamps

Landscapes

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

Description

  • Die vorliegende Erfindung befaßt sich mit verteilten Datenverarbeitungssystemen.
  • Ein verteiltes Datenverarbeitungssystem besteht normalerweise aus einer Reihe von datenverarbeitenden Rechnern, die untereinander über ein Kommunikationsnetzwerk verbunden sind. Eine wichtige Klasse von verteilten Systemen ist jene, in der auf Daten auf einem Rechner transparent durch Datenverarbeitungsprogramme, die auf anderen Rechnern durchgeführt werden, zugegriffen wird. Eine allgemeine Beschreibung einer solchen verteilten Datenbank wird in dem Artikel "What is a Distributed Database System", Teil 1 und 2 (C. J. Date, The Relational Journal, Nr. 1 und 2 1987) gegeben.
  • In einem verteilten Datenbanksystem können Daten aufgeteilt und auf mehreren Rechnern gespeichert werden, um diese Daten in der Nähe derjenigen Prozessen anzuordnen, die auf diese Daten zugreifen, um den Datenverkehr im Kommunikationsnetzwerk zu verringern. Es ist jedoch meistens die Situation gegeben, daß einige der Rechner auf Daten zugreifen müssen, die sich auf einem anderen Rechner befinden. Dieser entfernte Zugriff steigert die Kosten und den Zeitaufwand für die Datenverarbeitungsprozesse, so daß die Leistung dieser Rechner sich gegenüber einem vergleichbaren, allein arbeitenden System mit eigenen Daten in hohem Maße verschlechtern kann.
  • Ein zusätzliches Problem ist es, daß Störungen in den Kommunikationsverbindungen oder bei den Rechnern zur Datenverarbeitung auftreten können, so daß der Zugriff auf die Daten zu bestimmten Zeiten nicht erfolgen kann. Die Verfügbarkeit der Daten ist dann schlechter als bei alleinstehenden Systemen. Obwohl es das Ziel eines verteilten Systems ist, Datenressourcen gemeinsam zu nutzen, können diese negativen Effekte dazu führen, daß der Benutzer dazu neigt, sich auf entfernten Datenzugriff nicht mehr zu verlassen. Dies wiederum führt dazu, daß der Wert eines verteilten Systems gegenüber einem zentralisierten System sinkt.
  • Ein ständiges Ziel im Bereich der verteilten Systeme ist es deshalb, Zugriff auf entfernte Daten mit größtmöglicher Leistung und Verfügbarkeit zu gewährleisten, die mit der von lokalen Daten vergleichbar ist. Eine Lösung ist es, Daten über das System zu replizieren, so daß die meisten Datenzugriffe mit einer lokalen oder beinahe identischen Kopie der erforderlichen Daten bedient werden können. Dieser Ansatz wurde in einem Artikel von Sang Hyuk Son, SIGMOD Record, Bd. 17, Nr. 4 (1988) beschrieben. Bei dieser Technik muß eine Balance gefunden werden zwischen der Verringerung des Netzwerkverkehrs (sowie dessen Kosten) bei Datenzugriffen und dem zusätzlichen Netzwerkverkehr, der erforderlich ist, um Aktualisierungen der vielen Datenkopien über das Netz zu verteilen.
  • Datenreplizierung wird bei verschiedenen Arten der verteilten Systeme verwendet, von LAN-Dateiservern mit Hilfe von Cachespeicherung bis hin zu verteilter Datenbankverwaltung mit Hilfe von replizierten Daten. Eine wichtige Klasse der replizierten Datensysteme ist diejenige, in der eine primäre Kopie eines Datenobjekts gespeichert wird, wobei alle weiteren Kopien dieses Objekts als sekundäre Kopien bezeichnet werden. Aktualisierungen werden zuerst an der primären Kopie vorgenommen, um sicherzustellen, daß die korrekte Reihenfolge bei der Aktualisierung eingehalten wird. Änderungen an den sekundären Kopien werden dann auf der Grundlage der geänderten primären Kopien vorgenommen.
  • Die Replizierung eines Datenobjekts ist vor allem dann hilfreich, wenn für das Objekt sehr viele Lesezugriffe und weniger Schreibzugriffe vorliegen. Der Grund dafür ist, daß ein Lesezugriff auf einer einzigen sekundären Kopie ausgeführt werden kann, während der Schreibzugriff auf der primären Kopie ausgeführt werden muß und dann an alle anderen sekundären Kopien weitergeleitet werden muß. Die Kosten eines Schreibzugriffs sind deshalb höher als für einen Lesezugriff. In einem verteilten System führt das Aktualisieren eines Datenobjekts dazu, daß die entfernten sekundären Kopien des Objekts ungültig und durch neue Kopien ersetzt werden, die über das gesamte Netzwerk gesendet werden, so daß die Kosten für das Netzwerk zu den weiteren Kosten für eine Aktualisierung hinzugefügt werden müssen.
  • Ein extremes Beispiel für diese Methode ist die Verwendung von "Schnappschüssen", die als Nur-Lesen-Replizierungen gedacht sind, zur Verwendung durch entscheidungsunterstützte Anwendungen. Lindsay et al beschreibt im IBM-Forschungsbericht RJ4992 "Snapshot Differential Refresh Algorithm" (B. Lindsay et al. 1986), wie die Schnappschüsse in regelmäßigen Abständen aktualisiert werden, um möglichst genau dem aktuellen Stand der primären Daten zu entsprechen. Schnappschüsse haben jedoch keine garantierte Integrität und können nicht für Aktualisierungen von Transaktionsdaten verwendet werden.
  • Dort, wo eine große Zahl von Benutzern eine gemeinsam genutzte Datei oder Datenbank aktualisieren, werden sekundäre Kopien schnell ungültig, so daß ein umfangreicher Netzwerkverkehr nötig wird. Dieser zusätzliche Verkehr kann sogar die Verringerung des Netzwerkverkehrs wieder aufheben, die durch die Replizierung zuvor erreicht werden sollte. Die praktische Konsequenz daraus war, wie in dem Artikel "Structures for Systems of Network" (A. L. Scherr, IBM Systems Journal, Bd. 25, Nr. 1, 1987) beschrieben, daß Replizierungsmethoden bei großen gemeinsam genutzten Dateien und Datenbanken, die fast immer zentralisiert werden, als nicht sinnvoll erachtet wurden.
  • Ein wichtiges Problem bei dem Stand der Technik ist es deshalb, daß die Datenreplizierung zwar als wünschenswert angesehen werden kann, aber daß dies sehr schwer zu erreichen war in der komplizierten Situation, in der die Daten von Benutzern an mehreren Rechnern gleichzeitig aktualisiert werden können. In vielen Situationen in der Praxis benötigen jedoch viele Anwendungen auf verteilten Systemen keinen Zugriff auf die aktuellsten Daten und können auch zufriedenstellend mit Daten arbeiten, die bereits in einem bekannten Umfang und Maße veraltet sind. Beispiele dafür sind Anwendungen, die Kurstabellen verwenden, welche regelmäßig aktualisiert werden und automatische Schaltersysteme, die bei der Autorisierung von Kontoabhebungen einen veralteten Kontostand verwenden.
  • Ein Problem kann auftreten, wenn ein bestimmter Rechner so eingerichtet ist, daß er die primäre Kopie eines Datenelements speichert, ein anderer Rechner jedoch dringender Zugriff zum Aktualisieren auf das Element benötigt als der Rechner, auf dem sich die primäre Kopie befindet. Dies würde dann bedeuten, daß der entfernte Rechner eine Aktualisierungsanfrage für die primäre Kopie ausgeben und dann auf Änderungen warten müßte, die wieder auf seine sekundäre Kopie übertragen werden.
  • Die vorliegende Erfindung bietet einen Apparat der verteilten Datenverarbeitung und eine Methode der verteilten Datenverarbeitung, wobei die Methode folgendes umfaßt: Speichern von replizierten Kopien eines Datensatzes auf einer Mehrzahl an Prozessoren; Bezeichnen einer ersten der genannten Kopien auf einem ersten der genannten Datenprozessoren als primäre Kopie zu Aktualisierungszwecken; Weitergeben von Aktualisierungen der genannten primären Kopie an die anderen Prozessoren mit den sekundären Kopien des Datensatzes und Weitergeben der Zuständigkeit für die primäre Kopie vom genannten ersten Prozessor an einen anderen der genannten Prozessoren, wobei die sekundäre Kopie des genannten anderen Prozessors dann als die primäre Kopie des Datensatzes zu Aktualisierungszwecken bezeichnet wird. Die Methode der vorliegenden Erfindung ermöglicht in erster Linie die dynamische Übermittlung von Zuständigkeit beim normalen Weiterleitungsvorgang.
  • Durch eine dynamische Übermittlung des Besitzes oder der Zuständigkeit für die Verwaltung der primären Kopie kann die primäre Kopie jederzeit auf demjenigen Rechner gespeichert werden, auf dem dies am sinnvollsten ist.
  • Vorzugsweise kann ein entfernter Prozessor mit einer sekundären Kopie eines Datensatzes die Zuständigkeit für die primäre Kopie mit Hilfe eines Deskriptors anfragen. Eine Liste mit Deskriptoren von Datensätzen wird auf einem zentralen Rechner gespeichert, deren Zuständigkeiten an einen entfernten Datenprozessor weitergegeben wurden, damit bei der Vergabe von Zuständigkeiten keine Konflikte entstehen.
  • Damit die vorliegende Erfindung verständlich wird, wird nun ein bevorzugtes Ausführungsbeispiel mit Bezug auf die dazugehörigen Zeichnungen beschrieben:
  • 1. Fig. 1 zeigt einen Teil eines verteilten Datenverarbeitungssystems, das für die Ausführung der vorliegenden Erfindung geeignet ist.
  • Fig. 2 zeigt schematisch Daten und verbundene Steuerungstabellen, die zur Verwendung in dem System von Fig. 1 geeignet sind.
  • Fig. 3 ist ein Flußdiagramm, das eine 'Nachrichten'- oder 'Pulldown'-Strategie zeigt, mit der Aktualisierungen in einem verteilten Datenverarbeitungssystem weitergeleitet werden können, was Teil eines Ausführungsbeispiels der vorliegenden Erfindung ist.
  • Fig. 4 ist ein Flußdiagramm, das eine 'Auf Anfrage'- oder 'Pulldown'-Strategie zeigt, mit der Aktualisierungen in einem verteilten Datenverarbeitungssystem weitergeleitet werden können, was Teil eines Ausführungsbeispiels der vorliegenden Erfindung ist.
  • Fig. 5 zeigt eine konventionelle Strategie zum Erstellen von Aktualisierungen in einer primären Kopie.
  • Fig. 6 zeigt einen Teil eines verteilten Datenverarbeitungssystems mit einer Datei mit verteilten primären Kopien, in dem die vorliegende Erfindung integriert ist.
  • Fig. 7 ist ein Flußdiagramm, das eine im System von Fig. 6 angewendete Aktualisierungsstrategie zeigt, bei der der entfernte Prozessor die Aktualisierung vornimmt, und
  • Fig. 8 ist ein Flußdiagramm, das die Übermittlung von Zuständigkeit für die primäre Kopie eines Datensatzes von einem zentralen an einen entfernten Rechner entsprechend der vorliegenden Erfindung zeigt.
  • Fig. 1 stellt einen Teil des Netzwerks mit datentverarbeitenden Rechnern dar, in dem die Datenprozessoren 100, 200 und 250 über ein Datenkommunikationsnetzwerk 260 miteinander verbunden sind. Die Datenprozessoren 100 und 200 können eine Zentrale Datenverarbeitungseinheit (Central Processing Unit = CPU) 110, 210 mit zugeordneten Terminals 120, 220 und Geräten zur Datenspeicherung 130, 230 umfassen. Die Datenprozessoren können auch über zusätzliche periphere Geräte verfügen, wie etwa automatische Schaltermaschinen (ATMs) oder Drucker. Diese zusätzlichen Geräte werden allgemein als 140, 240 dargestellt. Jeder der Prozessoren 100 bis 250 führt eine Datenbank/Datenkommunikationssystem aus, bekannt als CICS, um Verarbeitungsanwendungen zur Online-Übertragung zu unterstützen. Das CICS-Programm wird im CICS General Informationen Manual (GC33-0155-3), erhältlich bei IBM, beschrieben.
  • Die Verbindung von Datenprozessoren über ein Datennetzwerk wird im IBM Handbuch "CICS Inter-Product Communication" (SC33-0824- 0) beschrieben, wobei jeder Datenprozessor, der CICS Inter System Communication-Funktionen nutzt, auf Daten zugreifen kann, die auf einem anderen Prozessor gespeichert sind. Wenn beispielsweise ein bestimmter Datensatz vom CPU 210 benötigt wird, aber auf dem Speichergerät 130 gespeichert ist, sendet das CICS-Programm eine Zugriffsanfrage über das Netzwerk 260 vom Datenprozessor 200 zum Datenprozessor 100, der dann wiederum den angeforderten Datensatz zurücksendet. Diese Methode zum Zugriff auf entfernte Dateien ist bekannt als Funktionsverlagerung.
  • Im allgemeinen ist die Installation von Datennetzwerken wie dem Netzwerk 260 teuer, so daß bereits des öfteren Anstrengungen unternommen wurden, um den Netzwerkverkehr so weit wie möglich einzuschränken. Eine Möglichkeit ist es, die Datendateien zwischen mehreren Rechnern im Netzwerk aufzuteilen, so daß die Daten entweder direkt auf dem betreffenden Prozessor oder physisch nahe bei dem Prozessor gespeichert sind, der die Daten am meisten nutzt. Dies kann jedoch den Netzwerkverkehr nicht verringern, wenn die Datendatei von einer Vielzahl an Datenprozessoren genutzt wird, da alle außer einem Prozessor mit Hilfe des Netzwerks auf die einzelne Datei zugreifen müssen, unabhängig von ihrem Speicherort.
  • Ein zweiter Lösungsansatz ist es deshalb, mehrere Kopien der Datendatei zu erstellen und diese Kopien auf mehreren Prozessoren auf dem Netzwerk zu speichern. Auf diese Weise können Kopien bestimmter Dateien auf jedem Prozessor, bzw. auf den Prozessoren, die diese Dateien normalerweise nutzen, gespeichert werden. Durch Replizieren von Dateien auf jedem Prozessor kann gewährleistet werden, daß Zugriffe auf Daten lokal sind und diese Dateien nicht über das Netzwerk verschickt werden müssen.
  • Eine der replizierten Kopien wird als "Masterkopie" oder "primäre Kopie" bezeichnet. Sobald eine Aktualisierung an einer Datei vorgenommen wurde, wird diese Aktualisierung zuerst auf die Masterkopie angewendet. Die Aktualisierung der sekundären Kopien werden dann auf Grundlage der Masterkopie vorgenommen. Dadurch, daß die Aktualisierung zuerst auf die Masterkopie angewendet wird, kann gewährleistet werden, daß die Aktualisierungen in der richtigen Reihenfolge erfolgen. Die Masterkopien müssen nicht alle auf einem einzigen Datenprozessor gespeichert werden. Der Ort der Masterkopie einer bestimmten Datei kann auf oder nahe bei einem Prozessor gewählt werden, der am häufigsten Zugriff auf diese Datei benötigt.
  • Sobald eine Aktualisierung der Masterkopie vorgenommen wurde, kann dieser aktualisierte Datensatz oder auch eine vollständige Kopie der aktualisierten Datei an alle sekundären Kopien weitergeleitet werden. Dies kann jedoch eventuell zu einem umfangreichen Netzwerkverkehr führen, womit die Vorteile der Replikation aufgehoben würden. In dem aufgeführten Ausführungsbeispiel wurde dieses Problem gelöst, indem ein gewisser Grad an Unsicherheit in jeder der sekundären Kopien zugelassen wurde. Dazu verfügt jede der sekundären Kopien über einen Gültigkeitszeitraum, deren Ablaufzeitpunkt in einer CICS- Kontrolldatei gespeichert wird, die dieser Datei zugeordnet ist. Innerhalb dieses Gültigkeitszeitraums gilt die sekundäre Datei als gültig, unabhängig davon, ob die Masterkopie in der Zwischenzeit aktualisiert wurde. Es ist nicht nötig, daß die sekundäre Kopie alle Datensätze der primären Kopie umfaßt; sie kann auch nur diejenigen Datensätze enthalten, die häufig auf dem sekundären Rechner benötigt werden. Somit können sekundäre Kopien unterschiedliche Datensätze umfassen.
  • Fig. 2 ist ein Schemadiagramm, das die Zuordnung eines Gültigkeitszeitraums zu den gespeicherten Datensätzen einer sekundären Kopie darstellt. In der Abbildung werden die Datensätze in einer CICS-Datendatei 300 angeordnet dargestellt.
  • Jedem Datensatz in der Datei 300 ist ein Gültigkeitszeitraum (T) 320 und ein Gültigkeits-Flag (V) 330 zugeordnet, die in einer Tabelle zur Dateisteuerung 340 gespeichert sind. Der Ursprung des Gültigkeitszeitraums wird weiter unten beschrieben. Wenn versucht wird, einen Datensatz 310 zu lesen, wird zuvor das Gültigkeits-Flag 330 überprüft. Wenn das Gültigkeits-Flag 330 keinen Status 'ungültig' anzeigt, wird der Gültigkeitszeitraum überprüft, um zu ermitteln, ob der Gültigkeitsraum überschritten 320 wurde. Wenn der Gültigkeitszeitraum 320 nicht überschritten wurde, kann der Datensatz 310 gelesen werden und der Vorgang ordnungsgemäß weitergeführt werden. Wenn der Gültigkeitszeitraum überschritten wurden, kann der Datensatz 310 nicht gelesen werden, und das dem Datensatz zugeordnete Gültigkeits-Flag 330 wird auf 'ungültig' gesetzt. Es wird dann eine Aktualisierung der sekundären Kopie angefordert. Es können auch weitere Maßnahmen, beschrieben in Fig. 4, ergriffen werden.
  • Der Gültigkeitszeitraum T wird einzelnen Datensätzen oder einer gesamten Datei zugeordnet. Er kann von dem Rechner mit der Masterkopie zusammen mit der Aktualisierung eines Datensatzes weitergeleitet werden. Alternativ dazu kann der Gültigkeitszeitraum vom Rechner mit einer sekundären Kopie zurückgesetzt werden, wann immer eine Aktualisierung der Masterkopie empfangen wird, indem ein vordefinierter Gültigkeitszeitraum zu dem Zeitpunkt hinzugefügt wird, zu dem die Aktualisierung der Masterkopie erfolgte.
  • Der tatsächliche Gültigkeitszeitraum (die Differenz zwischen dem Zeitpunkt, zu dem die Ungültigkeit eintritt und dem Zeitpunkt, zu dem der Master-Datensatz aktualisiert wurde) eines Datensatzes wird vom Benutzer unter Berücksichtigung der Art der Daten und wahlweise des aktuellen Zeitpunkts und Datums, festgelegt. Das wichtigste Kriterium bleibt jedoch die Art der Daten. Als Beispiel können gespeicherte Daten in einem verteilten System genannt werden, die sich auf Kontostände einer Bank beziehen. Um kleinere Abhebungen von einem Konto zu bewilligen (beispielsweise mit Hilfe einer Schaltermaschine (ATM)), betrachtet der Benutzer, also die Bank, die zusätzlichen Netzwerk- und Verarbeitungskosten möglicherweise als unnötig, die für eine Aktualisierung des auf einer lokalen sekundären Kopie befindlichen Kontostandes öfter als beispielsweise alle 24 Stunden nötig wären.
  • Wie oben erklärt, können die Gültigkeitszeiträume je nach Uhrzeit oder Datum variieren. Der Gültigkeitszeitraum muß beispielsweise an einem Montagmorgen (dem Start der Geschäftswoche) kürzer sein, wenn Aktualisierungen zu diesem Zeitpunkt besonders häufig vorgenommen werden. Gleichzeitig kann der Gültigkeitszeitraum am Wochenende verlängert werden, wenn nur wenige Aktualisierungen der Daten vorgenommen werden.
  • Fig. 3 ist ein Flußdiagramm, das eine Strategie zur Weiterleitung von Aktualisierungen von einem oder mehreren Datensätzen von der primären Kopie an die sekundären Kopien darstellt. Diese Strategie, die als 'Nachrichten'- oder 'Pushdown'-Strategie bezeichnet wird, ist abhängig davon, daß dem Besitzer der Masterkopie der Zeitpunkt, zu dem die Ungültigkeit der sekundären Kopien eintritt, bekannt ist, unabhängig davon, ob eine Anforderung auf Lesezugriff gemacht wurde.
  • Einige der gezeigten Schritte im Flußdiagramm werden vom Besitzer der primären Kopie, und die restlichen Schritte werden von den Besitzern der sekundären Kopien ausgeführt. Die Kommunikation zwischen dem Besitzer der primären Kopie und den Besitzern der sekundären Kopien erfolgt über die CICS InterSystem Communication-Funktionen oder eine ähnliche Vorrichtung, wie etwa ein zuverlässiges Nachrichtensystem.
  • Der Vorgang beginnt in Schritt 400 damit, daß der Besitzer der primären Kopie feststellt, welche Datensätze der primären Kopie seit der Weiterleitung der letzten Aktualisierung an die sekundären Kopien aktualisiert wurden. Im vorliegenden Ausführungsbeispiel wird Schritt 400 ausgeführt, bevor das Ende des Gültigkeitszeitraums der sekundären Kopien erreicht wird. In Schritt 410 wird ein neuer Gültigkeitszeitraum T für die Folge von Datensätzen auf der Grundlage des aktuellen Zeitpunkts und der vordefinierten Informationen über die Art der Datensätze errechnet. Ein Datensatz mit dem Zeitpunkt, zu dem der Datensatz ungültig wird, wird beim Besitzer der primären Kopie gespeichert.
  • In Schritt 420 werden die aktualisierten Datensätze zusammen mit den Zeitpunkten, an denen die ungültig werden, an die Besitzer der sekundären Kopien weitergeleitet. Der erste Schritt, den ein Besitzer einer sekundären Kopie ausführt, ist der Empfang der Aktualisierungen 430 und deren Anwendung 440 auf die sekundäre Kopie der Datei. In Schritt 450 werden die neuen Zeitpunkte gespeichert, an denen die Ungültigkeit eintritt und die diesen Datensätzen zugeordnet wurden. Zuletzt werden in Schritt 460 die den Datensätzen zugeordneten Flags, die möglicherweise auf 'ungültig' gesetzt wurden, um anzuzeigen, daß der Gültigkeitszeitraum für diesen Datensatz überschritten wurde, wieder zurückgesetzt. Mit dieser Strategie wird gewährleistet, daß jede sekundäre Kopie ständig verwendbar ist, wenn die Aktualisierungen stets vor Ablauf der Gültigkeit auf sekundäre Kopien angewendet werden.
  • Fig. 4 ist ein Flußdiagramm, das eine zweite Strategie zur Weiterleitung von Aktualisierungen von der primären Kopie der Datei an die sekundären Kopien darstellt. Diese Strategie wird als 'Auf Anfrage'- oder 'Pulldown'-Strategie bezeichnet. Wieder werden einige der beschriebenen Schritte vom Besitzer der primären Kopie und die verbleibenden Schritte von jedem der Besitzer der sekundären Kopien ausgeführt.
  • Der Vorgang in Fig. 4 beginnt damit, daß der Besitzer der sekundären Kopie einen Lesevorgang für einen Datensatz einleitet, der sich auf einer sekundären Kopie befindet. Das zum Datensatz gehörige Gültigkeits-Flag wird in Schritt 500 überprüft. Falls das Gültigkeits-Flag auf 'ungültig' gesetzt wurde, wird der Vorgang direkt bei Schritt 530 weitergeführt, wo eine Aktualisierung des Datensatzes angefordert wird. Unter diesen Umständen wird durch das ungültige Gültigkeits-Flag jede weitere Überprüfung der Gültigkeit des Datensatzes überflüssig gemacht. Wenn jedoch das Gültigkeits-Flag auf 'gültig' gesetzt ist, wird eine weitere Überprüfung in Schritt 510 vorgenommen, um zu ermitteln, ob die aktuelle Uhrzeit später liegt als der dem Datensatz zugeordnete Zeitpunkt, zu dem die Ungültigkeit eintritt. Wenn die aktuelle Uhrzeit vor dem Zeitpunkt T liegt, kann der Datensatz der sekundären Kopie in Schritt 540 gelesen und der Vorgang erfolgreich beendet werden.
  • Wenn in Schritt 510 festgestellt wird, daß der Gültigkeitszeitraum überschritten wurde, wird der Vorgang bei Schritt 520, wo das Gültigkeits-Flag auf 'ungültig' gesetzt wird, und bei Schritt 530, wo eine Aktualisierung des Datensatzes beim Besitzer der primären Kopie angefordert wird, weitergeführt. Es können sich jedoch Situationen ergeben, wo dieser Aufforderung keine Folge geleistet wird. Dies kann der Fall sein, wenn beispielsweise der Besitzer der primären Kopie ausfällt oder das Kommunikationsnetzwerk nicht zur Verfügung steht. Wenn der Aufforderung zur Aktualisierung Folge geleistet werden kann, dann wird der Vorgang in Schritt 550 weitergeführt, bei dem der Besitzer der primären Kopie versucht, den angeforderten Datensatz in Schritt 560 abzurufen. Wenn der Datensatz gefunden werden konnte, errechnet der Besitzer der primären Kopie einen neuen Zeitpunkt, zu dem die Ungültigkeit eintritt und übermittelt in Schritt 570 sowohl den aktualisierten Datensatz als auch den neuen Zeitpunkt an den Besitzer der sekundären Kopie. Wenn die primäre Kopie des Datensatzes seit der letzten Versendung an den Besitzer der sekundären Kopie nicht wieder aktualisiert wurde, wird statt dessen ein positives Signal und der neue Zeitpunkt, zu dem die Ungültigkeit eintritt, versendet.
  • Wenn in Schritt 550 festgestellt wird, daß der Aufforderung zur Aktualisierung nicht Folge geleistet werden kann, wird der Vorgang ohne Ergebnis beendet. Diese Situation (nicht verfügbare Daten) wird auf herkömmliche Weise von dem Programm behandelt, das die ursprüngliche Anfrage zum Lesen des Datensatzes ausgegeben hat.
  • Die Aktualisierung wird vom Rechner mit der sekundären empfangen und in Schritt 580 auf die sekundäre Kopie angewendet. In Schritt 590 wird der neue Zeitpunkt T, zu dem die Ungültigkeit eintritt, gespeichert, und das dem Datensatz zugeordnete Gültigkeits-Flag V wird auf 'gültig' gesetzt. Die lokale Kopie des Datensatzes wird dann in Schritt 540 gelesen, und der Vorgang wird erfolgreich beendet. Diese Strategie minimiert den Netzwerkverkehr dadurch, daß Datensätze nur dann übermittelt werden, wenn sie ausdrücklich von einer Anwendung angefordert werden und keine gültige lokale Kopie vorhanden ist, wobei das Risiko besteht, daß diese Daten zu manchen Zeitpunkten nicht verfügbar sind.
  • Es ist möglich, eine kombinierte Aktualisierungsstrategie zu verwenden, in der die Funktionen der 'Auf Anfrage'- und der 'Nachrichten'-Strategie vereint werden. In diesem Fall wird die sekundäre Kopie auf einem entfernten Rechner als leere Datei ohne Daten initiiert. Diese Datei kann dann mit den Datensätzen bestückt werden, die der entfernte Rechner benötigt und über die 'Auf Anfrage'-Strategie angefordert hat. Nachdem der Arbeitssatz an Datensätzen erstellt wurde (wenn die 'Auf Anfrage'-Strategie genügend lange durchgeführt wurde), kann die Verarbeitung zur 'Nachrichten'-Strategie wechseln. Alternativ dazu können beide Strategien nebeneinander verwendet werden, wobei in diesem Fall die sekundäre Kopie auf einem entfernten Rechner aus Datensätzen, die vom entfernten Rechner benötigt werden und aus Datensätzen, die jüngst in der primären Kopie aktualisiert wurden, bestehen würde. Die kombinierte Strategie kann bei der Erstellung der sekundären Kopie zu zusätzlichen Arbeitsvorgängen führen, dann jedoch arbeitet diese Strategie ebenso gut wie die 'Nachrichten'-Strategie. Sie bietet den Vorteil, daß eine automatische Wiederherstellung erfolgt, falls die sekundäre Kopie aus irgendeinem Grund verlorengehen sollte.
  • Wenn eine Aktualisierung an einem Datensatz in einem verteilten, replizierten System vorgenommen wird, wird die Aktualisierung auf die primäre Kopie angewendet, bevor sie auf irgendeine der anderen Kopien des Datensatzes angewendet wird. Dies geschieht, um zu gewährleisten, daß Aktualisierungen in der richtigen Reihenfolge vorgenommen werden. In vielen verteilten Datenverarbeitungssystemen (wie etwa in einem Verarbeitungssystem zur Übermittlung) jedoch werden Daten auf einem entfernten Rechner erfaßt und dann an die primäre Kopie geleitet. Wenn also ein einzelner Rechner die primäre Kopie für alle Daten besitzt, und diese Datenerfassungsvorgänge die primäre Kopie aktualisieren müssen, ist die Leistung nicht besser als bei einem nichtreplizierten System. Der Aktualisierungsfluß wird in Fig. 5 gezeigt, wo ein entfernter Datenprozessor eine Aktualisierung an einer primären Kopie vornimmt, unter Zuhilfenahme der vorhandenen CICS InterSystem Communication-Funktionen. In Schritt 600 bearbeitet der entfernte Datenprozessor den Datensatz zur Aktualisierung und leitet ihn in Schritt 610 an den zentralen Datenprozessor weiter. In Schritt 620 wird dieser Datensatz empfangen, und die Aktualisierung wird auf die primäre Kopie der Datei angewendet. In Schritt 630 wird eine Bestätigung der Aktualisierung generiert und an den entfernten Rechner übermittelt und in Schritt 640 empfangen. Es ist dabei zu beachten, daß die Aktualisierung in Schritt 610 vollständig fehlschlagen kann, wenn eine Störung im Netzwerk auftritt.
  • Eine Lösung dieser Leistungs- und Verfügbarkeitsprobleme wird in Fig. 6 gezeigt, in der die primäre Kopie selbst über das Netzwerk verteilt wird. Mit anderen Worten ist möglichst jeder Rechner im Besitz der primären Kopien für die Datensätze, die er am häufigsten aktualisieren muß. Der zentrale Rechner besitzt nun sekundäre Kopien dieser Datensätze, so daß eine vollständige Datei anderen Rechnern und dem Rechner zur zentralen Datenverarbeitung zur Replizierung zur Verfügung steht.
  • Fig. 6 zeigt ein verteiltes Datenverarbeitungssystem, das dem in Fig. 1 ähnelt. Die gespeicherten Daten in Speichergerät 130, 230 werden schematisch mit vier Partitionen A, B, C und D dargestellt. Der Datenprozessor 100, der der zentrale Rechner sein kann, verfügt über die primäre Kopie 670 der Partition C, und der Datenprozessor 200 verfügt über die primäre Kopie 680 der Partition B. Jeder Prozessor kann über sekundäre Kopien von anderen Partitionen verfügen, wenn dies dem Zugriffsbedarf dieses Prozessors entspricht. Es ist wichtig, daß die Partitionen als nicht-überlappend definiert sind, so daß nur eine primäre Kopie für jeden gegebenen Datensatz vorhanden sein kann. Dies kann erreicht werden, indem die Datensätze nach Hauptbereich oder einer ähnlichen Methode partitioniert werden. Im allgemeinen verfügt jede Partition über einen zugeordneten Deskriptor 650, 660, mit dem der Datenprozessor bestimmen kann, ob sich ein bestimmter Datensatz in dieser Partition befindet oder nicht.
  • Der geänderte Aktualisierungsfluß wird in Fig. 7 gezeigt, in dem ein Datenprozessor einen Datensatz aktualisiert. In Schritt 700 bearbeitet der Datenprozessor den Datensatz zur Aktualisierung und in Schritt 710 testet er den Deskriptor der lokalen Partition, um festzustellen, ob sich der Datensatz in der Partition der primären Kopie befindet, die sich auf diesem Rechner befindet. Wenn dies der Fall ist, wird die Aktualisierung in Schritt 720 auf diese Partition angewendet und in Schritt 730 eine Bestätigung der Aktualisierung generiert. Wenn sich der aktualisierte Datensatz nicht in der lokalen Partition auf diesem Rechner befindet, wird er in Schritt 740 an den zentralen Rechner weitergeleitet und in Schritt 750 in der zentralen Datei (sowie in der primären Kopie, wenn diese nicht identisch sind) empfangen und angewendet. Es wird in Schritt 760 eine Bestätigung generiert und an den entfernten Rechner weitergeleitet. Wenn die lokale Partition ausgewählt wurde, um einen Großteil der aktualisierten Datensätze auf diesem Rechner zu speichern, kann diese Methode den Netzwerkverkehr erheblich verringern. Weiterhin wird die Verfügbarkeit erhöht, da nur bei den Aktualisierungen Störungen aufgrund von Netzwerkfehlern auftreten können, die an den zentralen Rechner übermittelt werden müssen.
  • In einigen Situationen kann es vorkommen, daß ein entfernter Rechner als Besitzer der primären Kopie für eine Folge von Datensätzen initialisiert wurde, später jedoch ein anderer entfernter Rechner eine große Zahl an Aktualisierungen an diesen Datensätzen vornehmen muß. Die Möglichkeit einer Unterbrechung aufgrund einer Störung im Netzwerk und der zusätzliche Netzwerkverkehr, der durch diese Änderung im Aktualisierungsbedarf der datenverarbeitenden Rechnern hervorgerufen wird, kann einige der Vorteile wieder aufheben, die durch die Verwendung einer verteilten primären Kopie gegeben sind. Eine Lösung für dieses Problem ist es, die dynamische Übermittlung der Zuständigkeit für die primäre Kopie zwischen Rechnern zuzulassen. Eine solche Organisation wird 'Zurückübertragen/Auslagern'-Strategie genannt und wird im folgenden anhand von Fig. 8 beschrieben.
  • In Schritt 800 fordert der Datenprozessor des entfernten Rechners die Zuständigkeit für eine bestimmte Partition der Datei an, indem der Deskriptor der Partition an den zentralen Rechner gesendet wird. Diese Partition befindet sich auf dem Prozessor, der Schritt 810 ausführt und wird in Schritt 820 mit den Deskriptoren verglichen, die bereits ausgelagert wurden, was in einer Steuerdatei festgehalten wurde. Wenn die angeforderte Partition auf einen anderen Rechner ausgelagert wurde oder eine Partition überlappt, die bereits ausgelagert wurde, schlägt die Anforderung fehl. Es wird eine Fehlermeldung generiert und in Schritt 830 an den anfordernden Rechner übermittelt. In Schritt 840 wird diese Meldung vom Rechner empfangen, und der Vorgang wird erfolglos beendet. Wenn jedoch die angeforderte Partition nicht ausgelagert wurde, wird ihr Deskriptor in Schritt 850 in der Steuerdatei gespeichert. Eine Bestätigungsmeldung wird in Schritt 860 erstellt und an den entfernten Rechner übermittelt, der nun über die primäre Kopie verfügt. Die Meldung wird in Schritt 870 empfangen, und der Vorgang wird erfolgreich beendet. Später kann der entfernte Datenprozessor die Zuständigkeit für diese Partition für diese Partition wieder abgeben, indem er sie wieder an den zentralen Prozessor zurücküberträgt.
  • Diese dynamische Übermittlung der Zuständigkeit für die primäre Kopie kann in die oben beschriebene kombinierte Aktualisierungsstrategie integriert werden. Bei Inbetriebnahme eines Netzwerks mit Datenprozessoren kann die primäre Kopie aller Daten auf einem einzigen Rechner gespeichert werden, der als zentraler Rechner bezeichnet wird. Wenn die Datenverarbeitung stattfindet, werden Kopien der Daten über das Netzwerk mit Hilfe der 'Nachrichten'- oder 'Auf Anfrage'- Verarbeitung verteilt. Nach einer bestimmen Zeit kann ein verteilter Rechner den Besitz einer bestimmten Partition anfordern, und die Zuständigkeit für die primäre Kopie dieser Partition kann dynamisch auf den entsprechenden Rechner übertragen werden. Später kann die Zuständigkeit bei sich mit der Zeit verlagernder Auslastung wieder zurück an den zentralen Rechner oder an einen anderen Rechner übertragen werden.

Claims (12)

1. Eine Methode der verteilten Datenverarbeitung, folgendes umfassend: Speichern von vervielfältigten Kopien eines Datensatzes (310) auf mehreren Datenprozessoren (100, 200, 250); Bezeichnen einer ersten Kopie auf einem ersten Datenprozessor als primäre Kopie zu Aktualisierungszwecken; Weitergeben (420, 570) von Aktualisierungen der genannten primären Kopie an die anderen Datenprozessoren, die über sekundäre Kopien des Datensatzes verfügen, wobei die Methode dadurch gekennzeichnet ist, daß die Zuständigkeit für die primäre Kopie vom genannten ersten Prozessor zu einem zweiten der genannten mehreren Prozessoren weitergegeben (850) wird, wobei die zweite Kopie des genannten zweiten Prozessors des Datensatzes als primäre Kopie zu Aktualisierungzwecken bezeichnet wird.
2. Eine Methode der verteilten Datenverarbeitung nach Anspruch 1, bei der die Zuständigkeit für die erste Kopie auf Anfrage (800) des genannten zweiten Prozessors weitergegeben wird.
3. Eine Methode der verteilten Datenverarbeitung nach Anspruch 2, folgenden Schritt umfassend: Prüfen (820), ob ein zentraler Datenprozessor für die primäre Kopie zuständig ist, oder ob die Zuständigkeit an einen der anderen Datenprozessoren weitergegeben wurde, wobei die Zuständigkeit an den anfragenden Prozessor nur weitergegeben (850) wird, wenn der zentrale Prozessor über diese Zuständigkeit verfügt.
4. Eine Methode der verteilten Datenverarbeitung nach jedem der Ansprüche 1 bis 3, folgenden Schritt umfassend: Zuordnen von Deskriptoren (650, 660) zu spezifischen nicht-überlappenden Gruppen (670, 680) gespeicherter Datensätze und Übermitteln (800) des Deskriptors für eine spezifische Gruppe von einem entfernten Datenprozessor zu einem zentralen Datenprozessor, wobei eine Weitergabe der Zuständigkeit für die genannten gespeicherten primären Datensätze an den entfernten Prozessor angefragt wird.
5. Eine Methode der verteilten Datenverarbeitung nach Anspruch 4, folgende Schritte umfassend: Erstellen (850) auf einem zentralen Datenprozessor einer Liste mit Deskriptoren für Gruppen von Datensätzen, für die die Zuständigkeit für deren primäre Kopie an einen entfernten Datenprozessor weitergegeben wurde; Aktualisieren der genannten Liste, sobald eine Weitergabe der Zuständigkeit erfolgt und Prüfen der genannten Liste (820) bei Erhalt einer Anfrage zur Weitergabe der Zuständigkeit, um zu bestimmen, ob die Anfrage abgelehnt werden sollte oder nicht.
6. Eine Methode der verteilten Datenverarbeitung nach Anspruch 5, einschließlich der Übermittlung eines Deskriptors an einen zentralen Datenprozessor von einem entfernten Datenprozessor mit der Zuständigkeit für die primäre Kopie, wobei die Zuständigkeit des entfernten Datenprozessors für die Gruppe der primären Kopien entfällt.
7. Eine Methode der verteilten Datenverarbeitung nach jedem der vorangegangenen Ansprüche, folgende Schritte umfassend: Speichern eines Gültigkeitszeitraums (320), der mit einer sekundären, auf einem Datenprozessor gespeicherten Kopie verbunden ist und auf Anfrage für Datenzugriff bei dem genannten Datenprozessor Prüfen (510), ob der Gültigkeitszeitraum überschritten wurde.
8. Ein Gerät zur verteilten Datenverarbeitung, folgendes umfassend: einen ersten Datenprozessor (100) mit Mitteln zum Speichern (130) einer primären Kopie eines Datensatzes, einen oder mehrere Datenprozessoren (200) mit Mitteln zum Speichern (230) sekundärer Kopien des Datensatzes; Mittel zum Weitergeben (420, 570) von Aktualisierungen der primären Kopien an die sekundären Kopien, wobei das Gerät dadurch gekennzeichnet ist, daß es Mittel zur Weitergabe der Zuständigkeit (850) für die primäre Kopie vom ersten Prozessor zu einem der entfernten Datenprozessoren auf dessen Anfrage umfaßt, wobei die sekundäre Kopie auf einem der genannten entfernten Datenprozessoren dann als primäre Kopie des Datensatzes zu Aktualisierungszwecken bezeichnet wird.
9. Ein Gerät zur verteilten Datenverarbeitung nach Anspruch 8, wobei der genannte entfernte, anfragende Datenprozessor ein Mittel zur Anfrage (800) nach Zuständigkeit für die primäre Kopie umfaßt.
10. Ein Gerät zur verteilten Datenverarbeitung nach Anspruch 9, einen zentralen Datenprozessor umfassend, der die folgenden Mittel verfügt: ein Mittel zum Speichern einer Kopie eines Datensatzes, ein Mittel zum Prüfen, ob der zentrale Datenprozessor über die Zuständigkeit für die primäre Kopie verfügt und ein Mittel zur Weitergabe der Zuständigkeit für die primäre Kopie zum genannten anfragenden Prozessor, wenn der genannte zentrale Datenprozessor über die genannte Zuständigkeit verfügt.
11. Ein Gerät zur verteilten Datenverarbeitung nach einem jeden der Ansprüche 8 bis 10, folgende Mittel umfassend: ein Mittel zum Zuordnen von Deskriptoren (650, 660) zu spezifischen, nicht-überlappenden Gruppen (670, 680) von gespeicherten primären Datensätzen; Mittel auf einem zentralen Prozessor zum Speichern einer Liste mit Deskriptoren für Datensatzgruppen, für die die Zuständigkeit für deren primäre Kopie an einen entfernten Prozessor weitergegeben wurde, ein Mittel zum Aktualisieren der genannten Liste, wenn eine Weitergabe der Zuständigkeit erfolgt ist und ein Mittel zum Prüfen der genannten Liste (820) bei Erhalt einer Anfrage für eine Weitergabe der Zuständigkeit, um zu bestimmen, ob die Anfrage abgelehnt werden soll oder nicht.
12. Eine Methode der verteilten Datenverarbeitung nach einem jeden der Ansprüche 1 bis 3, bei der in einem Netzwerk zur verteilten Datenverarbeitung gespeicherte Datensätze in spezifische, unabhängige, nicht-überlappende Gruppen (670, 680) partitioniert werden, so daß die Zuständigkeiten für die primäre Kopie jeder einzelnen Gruppe zwischen den Prozessoren des verteilten Netzwerks unabhängig voneinander weitergegeben werden können.
DE69325004T 1992-12-04 1993-12-01 Verteiltes Datenverarbeitungssystem mit Vervielfältigung von Daten über das System Expired - Fee Related DE69325004T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB9225435A GB2262703B (en) 1991-12-28 1992-12-04 Front panel for drawers

Publications (2)

Publication Number Publication Date
DE69325004D1 DE69325004D1 (de) 1999-06-24
DE69325004T2 true DE69325004T2 (de) 1999-12-09

Family

ID=10726159

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69325004T Expired - Fee Related DE69325004T2 (de) 1992-12-04 1993-12-01 Verteiltes Datenverarbeitungssystem mit Vervielfältigung von Daten über das System

Country Status (2)

Country Link
EP (1) EP0600458B1 (de)
DE (1) DE69325004T2 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5649158A (en) * 1995-02-23 1997-07-15 International Business Machines Corporation Method for incrementally archiving primary storage to archive storage by utilizing both a partition archive status array and a partition map
SE9702015L (sv) * 1997-05-28 1998-11-29 Ericsson Telefon Ab L M Metod vid distribuerad databas, samt ett system anpassat att verka enligt metoden
US7636868B2 (en) 2006-06-27 2009-12-22 Microsoft Corporation Data replication in a distributed system

Also Published As

Publication number Publication date
EP0600458B1 (de) 1999-05-19
EP0600458A3 (en) 1995-11-02
DE69325004D1 (de) 1999-06-24
EP0600458A2 (de) 1994-06-08

Similar Documents

Publication Publication Date Title
DE69614383T2 (de) Kontinuierlich verfügbarer datenbankserver mit mehreren knotengruppen mit sich minimal überschneidenden sätzen von datenbankteilkopien
DE69802437T2 (de) Feinkörniger übereinstimmungsmechanismus für optimistische parallelsteuerung mit verriegelungsgruppen
DE69031926T2 (de) Instandhaltung von Dateiattributen in einem verteilten Datenverarbeitungssystem
DE69322549T2 (de) Verteilte Transaktionsverarbeitung mit einem Zwei-Phasen-Bindungsprotokoll mit erwarteter Bindung ohne Aufzeichnungspflicht
DE69528338T2 (de) Verfahren zur Verwaltung von schwachkonsistenten replizierten Datenbanken
DE112010004947B4 (de) Wiederherstellung einer vollständigen Systemsicherung und inkrementeller Sicherungen unter Verwendung von mehreren gleichzeitigen Datenströmen von Einheiten
DE69528339T2 (de) Applikationspezifische Konfliktlösung für schwachkonsistente replizierte Datenbanken
DE69710578T2 (de) Verfahren zum unabhängigen und gleichzeitigen zugriff auf eine gemeinsame datensammlung
DE3689664T2 (de) Verfahren und Gerät zur Verwaltung von veralteten Datenobjekten.
DE69327679T2 (de) Nachrichtenübertragung zwischen Prozessoren und einer Koppeleinrichtung
DE60001460T2 (de) Datenfernkopieren unter verwendung von potentiellen aufhebungsbefehlen
JP3066693B2 (ja) 分散データ処理システム
DE60312746T2 (de) Wiederherstellung nach fehlern in datenverarbeitungsanlagen
DE68928546T2 (de) Dateisystem für eine vielzahl von speicherklassen
DE69032337T2 (de) Multiprozessorsystem verwendendes Datenbasisverarbeitungssystem
DE69126066T2 (de) Verfahren und Gerät zur Optimierung des Logbuchaufhebungsgebrauchs
DE69917333T2 (de) Übertragung einer Ressource von einem ersten Zwischenspeicher an einen zweiten Zwischenspeicher
DE69636330T2 (de) Verfahren für On-line- und Echzeit-Datenmigration
DE602005002024T2 (de) Fernkopiersystem und Fernkopierverfahren
DE69807077T2 (de) Verfahren und vorrichtung zur wiederherstellung in einem verteilten datenbanksystem mit nicht global erreichbaren daten unter verwendung von gemeinsam genutzten virtuellen platten
DE69221259T2 (de) Verwaltung von Datenbankwiederherstellung nach Fehler
DE69119222T2 (de) Datensicherung und Beseitigung in einem Datenverarbeitungssystem
DE602005002532T2 (de) Cluster-datenbank mit ferndatenspiegelung
DE69714344T2 (de) Vorrichtung und Verfahren für die Verfügbarkeit und Wiedergewinnung von Dateien unter Verwendung von Sammlungen von Kopierspeicher
DE60018872T2 (de) System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee