DE3786956T2

DE3786956T2 - Verwaltung von registrierungsdaten in einem transaktionsorientierten System.

Info

Publication number: DE3786956T2
Application number: DE87107475T
Authority: DE
Inventors: Kenneth Michael Kapulka; Holly Anne Rader; Jimmy Paul Strickland
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1986-06-30
Filing date: 1987-05-22
Publication date: 1994-03-17
Anticipated expiration: 2007-05-23
Also published as: DE3786956D1; JPS6310252A; EP0250847B1; EP0250847A2; US4878167A; JPH0560617B2; EP0250847A3

Description

Die vorliegende Erfindung betrifft ein Verfahren zur Reduzierung der Anzahl und zur Verwaltung von Registrierungsdaten, auf die in einem transaktionsorientierten System, in dem gleichzeitig ablaufende, fehlerunabhängige Prozesse ein gemeinsames Protokoll benutzen, zugegriffen werden muß und die in diesem verarbeitet werden müssen.
Wie von C. J. Date in "An Introduction to Data Base Systems", Vol. 1, 4th Edition, Addison-Wesley Publishing Co., Copyright 1986, in Kapitel 18 dargelegt, stellt eine "Transaktion" eine logische Arbeitseinheit dar, die sich auf eine Abfolge von Operationen bezieht, mit der ein konsistenter Zustand einer wiederherstellbaren Ressource in einen anderen konsistenten Zustand umgewandelt wird, ohne daß dabei unbedingt in allen Zwischenstadien die Konsistenz gewahrt bleibt. Für die Belange dieser Erörterung soll eine Datenbank als typisches Beispiel für eine wiederherstellbare Ressource herangezogen werden.
Ein System, daß die Verarbeitung von Transaktionen unterstützt, stellt sicher, daß für den Fall, daß die Transaktion Aktualisierungen für die Datenbank ausführt und eine Störung auftritt, bevor die Transaktion zu ihrem normalen Abschluß kommt, diese Aktualisierungen rückgängig gemacht werden. Folglich wird die Transaktion entweder in ihrer Ganzheit ausgeführt oder sie wird vollständig rückgängig gemacht. Da eine Transaktion die Ausführung einer anwendungsspezifischen Abfolge von Operationen umfaßt, wird sie durch eine spezielle BEGIN-Transaktionsoperation eingeleitet und endet mit einer COMMIT-Operation oder einer ABORT-Operation. Die Operationen COMMIT und ABORT bilden den Schlüssel zur Schaffung einer Atomizität.
Die COMMIT-Operation bezeichnet mehrere Attribute. Erstens zeigt sie an, daß eine Transaktion erfolgreich beendet wurde. Zweitens zeigt sie an, daß sich die Datenbank in einem Zustand der Konsistenz befindet. Schließlich zeigt die COMMIT-Operation an, daß alle von dieser Arbeitseinheit vorgenommenen Aktualisierungen jetzt festgeschrieben bzw. in den Zustand der Dauerhaftigkeit überführt werden können. Im Gegensatz dazu bezeichnet die ABORT- Operation einen nicht erfolgreichen Abschluß einer Transaktion. Das heißt, der ABORT (Abbruch) bedeutet, daß ein Fehler aufgetreten ist, daß sich die Datenbank möglicherweise in einem Zustand der Inkonsistenz befindet und daß sämtliche Aktualisierungen, die von der Transaktion vorgenommen wurden, "zurückgesetzt" oder rückgängig gemacht werden müssen.
Transaktionen werden auf gespeicherten, programmgesteuerten Systeme ausgeführt, deren logische und physische Attribute allgemein als "Ressourcen" bezeichnet werden. Ferner kann von diesen Systemen gesagt werden, daß sie in verschiedenen Modi wie beispielsweise einem "Verarbeitungsmodus" oder, im Falle einer Störung, in einem oder mehreren "Wiederherstellungsmodi" arbeiten. Der Zugriff auf die Ressourcen und auch deren Einsatz wird über die Betriebssystemsoftware gesteuert. Dies sind die sogenannten "Ressourcen-Manager". In ähnlicher Weise werden die transaktionsorientierten Verarbeitungs- und Wiederherstellungsoperationen von der Betriebssystemsoftware gesteuert, was als "Transaktionsverarbeitung" und "Wiederherstellungs-Manager" bezeichnet wird.
Wie von Deitel in "An Introduction to Operating Systems", Revised Ist Edition, Addison-Wesley Publishing Co., Copyright 1984, auf den Seiten 103-108 dargestellt, kann man sich Ressourcen-Manager wie "Monitorprogramme" vorstellen. Ein Monitorprogramm ist ein auf gemeinsamen Zugriff ausgerichtetes Gebilde, das sowohl Daten als auch Prozeduren enthält, die dazu benötigt werden, eine Zuordnung für eine bestimmte gemeinsam benutzte Ressource oder Gruppe von gemeinsam benutzten Ressourcen vorzunehmen. Das heißt, ein Monitorprogramm stellt einen Mechanismus dar, der die sichere und effektive gemeinsame Benutzung abstrakter Datenarten durch verschiedene Prozesse zuläßt.
In einem transaktionsorientierten Datenbanksystem werden alle Änderungen an der Datenbank in ein Protokoll geschrieben, um die Wiederherstellung im Falle einer Unterbrechung zu unterstützen. Jede Transaktion verwendet die Grundelemente BEGIN (Beginn), COMMIT (Festschreibung), ABORT (Abbruch) und END (Ende) zur Begrenzung des Abschlusses (COMPLETION), des Widerrufs (UNDO) oder der Wiederholung (REDO) der einzelnen Transaktion.
Es sei bemerkt, daß ein Prüfpunktsatz eine Liste aller Transaktionen darstellt, die zum Zeitpunkt des Prüfpunktes aktiv waren, und darüber hinaus die Registrierungsadresse des jeweils neuesten Protokollsatzes einer jeden Transaktion enthält. Eine Transaktion, deren Datensätze zur Wiederholung (REDO) derselben verwendet werden, ist eine Transaktion, die zwischen dem letzten Prüfpunkt und dem Auftreten eines Fehlers beendet (festgeschrieben) wurde, wohingegen eine Transaktion, deren Datensätze für den Widerruf (UNDO) derselben verwendet werden, eine Transaktion ist, die zum Zeitpunkt des Auftretens eines Fehlers nicht beendet war. Daher ist es bei einem REDO erforderlich, mit der Transaktion zu dem am kürzesten zurückliegenden COMMIT-Punkt zurückzukehren und Änderungen in das Protokoll zu schreiben, wohingegen es bei einem UNDO erforderlich ist, zum BEGIN-Punkt der Transaktion zurückzukehren.
Es ist zu beachten, daß Transaktionen nicht nur die Arbeitseinheit definieren, sondern auch eine Wiederherstellungseinheit. Das System muß zum Zeitpunkt des Wiederanlaufs oder der Wiederherstellung wissen, für welche Transaktion ein UNDO und für welche ein REDO auszuführen ist. Der Prüfpunkt oder die Momentaufnahme, der bzw. die zu vorherbestimmten Zeitpunkten aufgenommen wird, listet sicher sämtliche Transaktionen auf, die zum Zeitpunkt der Aufnahme des Prüfpunktes im Gange waren. Daher kann das System, je nachdem, zu welchem Zeitpunkt ein Fehler aufgetreten ist, eine UNDO-Liste und eine REDO-Liste erstellen, indem es das Protokoll zunächst rückwärts durcharbeitet und dabei die Transaktionen in der UNDO-Liste rückgängig macht und anschließend das Protokoll wieder vorwärts durcharbeitet und die Transaktionen in der REDO-Liste wiederholt. Nur wenn sämtliche dieser Wiederherstellungsaktivitäten abgeschlossen sind, ist das System überhaupt in der Lage, neue Arbeit anzunehmen. Genaugenommen sind es der Prüfpunkt und die sich daran anschließende Protokollaktivität, die zur Bestätigung der UNDO- und REDO- Listen verarbeitet werden müssen.
Zum Stand der Technik liegen mehrere Quellen vor, in denen fehlertolerante, transaktionsorientierte Datenbanksysteme beschrieben werden. Hierzu zählen:
(1) Gawlick et al, US-Patentschrift 4.507.751, "Method and Apparatus for Logging Journal Data Using a Log Write Ahead Data Set", Patent erteilt am 26. März 1985.
(2) Baker et al, US-Patentschrift 4.498.145, "Method and Apparatus for Assuring Atomicity of Multirow Update Operations in a Database System", Patent erteilt am 5. Februar, 1985.
(3) Paradine et al, US-Patentschrift 4.159.517, "Journal Back-up Storage Control for a Data Processing System", Patent erteilt am 26. Juni 1979.
(4) Reinsch et al, "Method for Restarting a Long-running, Fault-tolerant Operation in a Transaction-oriented Data Base System Without Burdening the System Log", gleichzeitig anhängige Patentanmeldung US S/N 06/835.396, angemeldet am 3. März 1986.
Bei der gegenwärtige Protokollierungstechnik, die in den genannten Quellen dargestellt wird, werden sämtliche Registrierungsdaten, die von einem transaktionsorientierten System erzeugt werden, in einen einzigen Datenstrom geschrieben, der zu einem bestimmten Zeitpunkt physisch auf mehreren Direktzugriffsspeichergeräten oder Bandgeräten resident ist, wobei zu jedem Zeitpunkt immer nur auf eines dieser Geräte geschrieben wird. Die Patente von Gawlick, Baker und Paradine sowie die gleichzeitig anhängige Patentanmeldung von Reinsch beschreiben in dieser Reihenfolge (1) das Schreiben in ein Protokoll vor der Datensatzaktualisierung, (2) die Zwischenspeicherpufferung in ein Protokoll, (3) das gleichzeitige Schreiben in ein hartes und ein weiches Protokoll zur Gewährleistung einer ganzheitlichen Aktualisierung von mehreren Zeilen und (4) die Verwendung eines wiederanlauffähigen Ladedienstprogramms, in dem alle an der Datenbank vorgenommenen Änderungen zwecks Unterstützung einer Wiederherstellung im Falle einer Unterbrechung typischerweise in ein Protokoll geschrieben werden.
Beim Stand der Technik werden ferner die Arten von Informationen, die zur Wiederherstellung eines Systems beim Auftreten eines Fehlers benötigt werden von denjenigen unterschieden, die zur Wiederherstellung einer Ressource beim Auftreten eines Fehlers herangezogen werden. Eine Systemwiederherstellung bedeutet, daß die Systemressourcen wieder in einen früheren Zustand der Konsistenz überführt werden, wohingegen die Ressourcenwiederherstellung die Neuerstellung eines konsistenten Abbildes einer Ressource im Anschluß an deren Verstümmelung bedeutet.
Beim Stand der Technik werden bestimmte Bezeichnungen synonym verwendet. So kann beispielsweise der "Steuerstatus" und/oder der "Informationsstatus" einer Ressource oder eines Systems auch als "Abbild" derselben bzw. desselben bezeichnet werden. In der Transaktionsverarbeitung würde sich dies in den meisten Fällen auf die an Transaktionen erinnernden Datensätze beziehen.
Die vorliegende Erfindung ist in den beiliegenden Ansprüchen definiert.
Aufgabe dieser Erfindung ist es, ein Verfahren zur wirkungsvollen Bewerkstelligung einer protokollgestützten Datenwiederherstellung in transaktionsorientierten Systemen zu ersinnen. Hierzu gehört auch die Aufgabe, ein Verfahren zur Reduzierung der Anzahl der Registrierungsdaten zu ersinnen, auf die zur Bewerkstelligung der Datenwiederherstellung zugegriffen werden muß und die hierzu verarbeitet werden müssen.
Die zuvor erwähnten Aufgaben werden durch ein Verfahren zum Schreiben von gekennzeichneten (untergliederten und klassifizierten) Datensätzen aus einem ersten Protokolldatenstrom in mehrere Wiederherstellungsdatenströme und Löschen der gekennzeichneten Datensätze aus dem ersten Datenstrom beim Abschluß der Wiederherstellungseinheit, um die erneute Verwendung des ersten Protokolldatenstrom zu ermöglichen, gelöst, wie es in Anspruch 1 definiert ist.
Bei dem erfindungsgemäßen Verfahren wird die Wiederherstellung durch die Erzeugung zweier Datenstrukturen unterstützt. Dies sind die Datenströme TRS und RRS. Der Transaction Recovery Stream (Datenstrom zur Transaktionswiederherstellung, nachfolgend als TRS bezeichnet) wird zusammen mit dem Prüfpunkt und den Informationen zur Statusänderung dazu verwendet, die Umgebung zur Verwaltung von Transaktionen nach einer Störung wiederherzustellen. Der TRS enthält die Daten zur Bestimmung des Status der Wiederherstellungseinheit (unit of recovery, nachfolgend als UR bezeichnet), die Daten, die erforderlich sind, um ein ABORT (einen Abbruch) einer UR zu gewährleisten und die Daten, die erforderlich sind, um das COMMIT (die Festschreibung) einer UR sicherzustellen. Alle Daten, die für eine UR protokolliert wurden, werden in den TRS aufgenommen und Teil desselben.
Der Resource Recovery Stream (Datenstrom zur Ressourcenwiederherstellung, nachfolgend als RRS bezeichnet) wird zur Vorwärtswiederherstellung von Ressourcen verwendet. Damit ist die Neuerstellung eines gültigen Abbilds einer Ressource ausgehend von einer gültigen Kopie der Ressource gemeint, die zu einem vorherbestimmten Zeitpunkt stattfindet. Auf der Basis eines UR COMMIT oder UR ABORT werden die zur Vorwärtswiederherstellung von Ressourcen benötigten Datensätze aus dem TRS in einen oder mehrere vorherbestimmte(n) RRS(s) kopiert.
Der TRS stellt eine sehr dynamische Datenstruktur für Registrierungsdaten dar, die eine Behebung von Ressourcen-Inkonsistenzen erlaubt, die durch jene URs erzeugt wurden, die zum Zeitpunkt des Auftretens eines Fehlers aktiv waren. Der TRS ist das Repository (Depot) für protokollierte Daten, das aktiven URs zugeordnet wurde, wobei unter aktiven URs diejenigen Transaktionen zu verstehen sind, die zwischen den Begrenzungen BEGIN und END ausgeführt werden.
An dieser Stelle sei daran erinnert, daß jede Transaktion die Grundelemente BEGIN, COMMIT, ABORT (REDO, UNDO) und END zur Begrenzung der Transaktion verwendet. REDOs gewährleisten die Rückkehr der Transaktion zum am kürzesten zurückliegenden COMMIT-Punkt, wohingegen UNDOs die Rückkehr zum BEGIN-Punkt der Transaktion sicherstellen.
Wie zuvor bereits erwähnt, enthält der RRS Daten, die zur Vorwärtswiederherstellung ausgehend von einer Abbildkopie einer Ressource benötigt werden. Das erfindungsgemäße Verfahren erzeugt eine beliebige Anzahl von RRSs. Somit kann jede Anwendungssoftware, die auf das transaktionsorientierte Datenbanksystem zugreift, den Ressourcennamen festlegen. Daher kann auch jeder Schreibaufruf (WRITE) für das Protokoll die Ressource angeben, zu der ein bestimmter Datensatz gehören soll. Hierzu gehört auch die Auswahl der Semantik der Datensatzart, die die Bedingungen angibt, unter denen ein gegebener Datensatz aus einem TRS in einen RRS kopiert werden kann. Datensätze, die benötigt werden, um ein REDO einer Transaktion sicherzustellen, dürfen erst dann in den RRS kopiert werden, wenn die zugehörige UR den Status ENSURE-COMMIT (Festschreibung sicherstellen) annimmt. Datensätze, die benötigt werden, um ein UNDO einer Transaktion sicherzustellen, dürfen erst dann in den RRS kopiert werden, wenn die zugehörige UR in den Status ENSURE-ABORT (Abbruch sicherstellen) übergeht.
Aus dem oben Erwähnten geht hervor, daß durch die Verwendung des erfindungsgemäßen Verfahrens und die ausschließliche Verwaltung von konsistenten Abbildern der Daten im RRS eine Reduzierung der Speicheranforderung für RRS-Daten erreicht wird. Dies ist deshalb so, weil die Datensätze zum UR-Status und die nicht festgeschriebenen Datensätze nicht in die gespeicherten Daten aufgenommen werden müssen. Darüber hinaus reduziert sich durch die Beseitigung uninteressanter Datensätze die Zahl der Ein- Ausgabe-Operationen bei der Ressourcenwiederherstellung. Schließlich verringert sich der Verarbeitungsaufwand bei der Wiederherstellung, da der UR-Status erst dann festgelegt werden muß, wenn die Abbilder der Daten für die Kopie verwendet werden.
Die Erfindung wird nachstehend unter Bezugnahme auf die Figuren beschrieben, wobei
Fig. 1 das Auftreten von Grundelementen, die eine Transaktion begrenzen, hinsichtlich deren Abschluß bezüglich des Eintreten eines Prüfpunkts und eines Systemausfalls gemäß dem Stand der Technik zeigt,
die Fig. 2-3 eine Wiederherstellungseinheit (UR) und deren begrenzende Grundelemente zeigen, wobei die Wiederherstellung im einen Fall ein REDO und im anderen Fall ein UNDO von Transaktionen umfaßt,
Fig. 4 eine schematische Darstellung des Prozesses der Vorwärtswiederherstellung einer Ressource zeigt,
Fig. 5 eine höhere Steuerungsflußebene des Protokollierungsverfahrens gemäß der Erfindung aufzeigt,
Fig. 6 das Format der Protokollsätze innerhalb des Transaction Recovery Streams (TSR) gemäß der Erfindung veranschaulicht,
Fig. 7 eine Konkordanz zwischen Ressourcennamen und Resource Recovery Streams (RRSs) zeigt,
die Fig. 8-11 Pseudocode-Beschreibungen der UR-Steuerfunktionen (BEGIN, COMMIT, ABORT und END) darstellen,
Fig. 12 den höheren Pseudocode zeigt, der das Schreiben von Datensätzen zur Ressourcenwiederherstellung beschreibt und
die Fig. 13-24 die Strukturierung des TRS und der RRSs einschließlich der Antwort auf COMMIT-/ABORT-Befehle, bis hin zum Löschen der der Datensätze der betroffenen Wiederherstellungseinheit (UR) aus dem TRS gemäß dem erfindungsgemäßen Verfahren veranschaulichen.
In Fig. 1 sind die Beziehungen, die sich zwischen Transaktionsgrundelementen hinsichtlich des Zeitpunkts des Auftretens ergeben, in Bezug auf Prüfpunkte und Systemausfall dargestellt. Beim Eintreten einer Störung und damit eines Wiederanlaufs muß sich der Wiederherstellungs-Manager die Adresse des neuesten Prüfpunktsatzes aus einer Wiederanlaufdatei oder deren Äquivalent verschaffen, den Prüfpunktsatz im Systemprotokoll lokalisieren und damit fortfahren, das Protokoll von diesem Punkt an vorwärtsgerichtet bis zum Ende zu durchsuchen. Als Ergebnis dieses Vorgangs ist der Wiederherstellungs-Manager dann in der Lage, sowohl die Transaktionen zu bestimmen, die widerrufen werden müssen (UNDO), als auch die Transaktionen, die wiederholt werden müssen (REDO), um bei der Ressource wieder einen Zustand der Konsistenz herzustellen.
Jede Transaktion ist einer von fünf Kategorien zugeordnet. Demgemäß waren Transaktionen vom Typ T1 abgeschlossen, bevor der Prüfpunkt zum Zeitpunkt Tp erreicht war. Bei Transaktionen vom Typ T2 lag der Start vor dem Zeitpunkt Tp und der Abschluß nach dem Zeitpunkt Tp, aber noch vor dem Zeitpunkt Ta, bei dem der Systemausfall eintrat. Transaktionen vom Typ T3 begannen ebenfalls vor dem Zeitpunkt Tp, waren jedoch nicht vor dem Zeitpunkt Ta abgeschlossen. Transaktionen vom Typ T4 begannen nach dem Zeitpunkt Tp, wurden jedoch vor Erreichen des Zeitpunkts Ta abgeschlossen. Transaktionen vom Typ T5 schließlich starteten nach dem Zeitpunkt Tp, waren jedoch bis zum Zeitpunkt Ta nicht abgeschlossen. Aus diesem Grunde werden die Transaktionen T2 und T4 einem REDO unterworfen, wohingegen die Transaktionen T3 und T5 einem UNDO unterzogen werden.
Der Wiederherstellungs-Manager startet zwei Listen. Die UNDO- Liste enthält ursprünglich alle Transaktionen, die im Prüfpunktsatz aufgelistet sind, während die REDO-Liste zu Anfang keine Einträge enthält. Der Wiederherstellungs-Manager durchsucht das Protokoll vorwärts, beginnend beim Prüfpunktsatz. Wenn der Wiederherstellungs-Manager zu einer bestimmten Transaktion einen BEGIN-Transaktionssatz findet, fügt er diese Transaktion zur UNDO-Liste hinzu. Desgleichen verschiebt der Wiederherstellungs- Manager, wenn er einen COMMIT-Datensatz zu einer bestimmten Transaktion findet, diese Transaktion von der UNDO-Liste in die REDO-Liste.
Der Wiederherstellungs-Manager arbeitet das Protokoll nochmals rückwärts durch und macht die in der UNDO-Liste enthaltenen Transaktionen rückgängig. Schließlich arbeitet er wieder vorwärts und wiederholt die in der REDO-Liste enthaltenen Transaktionen.
Auf der Basis der obigen Beschreibung lassen sich ausgewählte Datensatzarten als REDOs oder UNDOs charakterisieren. Der Vollständigkeit halber sei auf die Fig. 2 und 3 eingegangen, die eine Wiederherstellungseinheit (UR) und deren begrenzende Grundelemente zeigen, wobei die Wiederherstellung im ersten Fall ein REDO und im zweiten Fall ein UNDO der Transaktionen bedeutet.
In der folgenden Erörterung beziehen sich die Fig. 5-12 auf den Grundgedanken des Verfahrens, während die Fig. 13-24 ein Ausführungsbeispiel der Erfindung veranschaulichen.
Es ist zu beachten, daß ein Protokoll beim Stand der Technik einen einzelnen Datenstrom darstellt, auf dem Daten, die für den Wiederanlauf des Systems benötigt werden, und Daten, die für die Wiederherstellung der Medien (Ressourcen) benötigt werden, aufgezeichnet sind. Bei dieser Erfindung wird anstelle der bloßen Verwendung einer serialisierten Aufzeichnung von Ereignissen der Datentyp eines wiederverwendbaren Transaction Recovery Streams (Datenstroms zur Transaktionswiederherstellung) und mehrerer Resource Recovery Streams (Datenströme zur Ressourcenwiederherstellung) herangezogen.
In Fig. 5 wird die Beziehung zwischen dem Transaction Recovery Stream (TRS) und den verschiedenen Resource Recovery Streams (RRSs) gezeigt, die durch die UR-Grundelemente (BEGIN, COMMIT/ABORT, END) ausgelöst werden. Sobald eine Transaktion einen elementaren Konsistenzpunkt erreicht und die Änderungen derselben in der Ressource, beispielsweise einer Datenbank, objektiviert wurden, steht der Speicherplatz, der im TRS von all den Datensätzen belegt war, die sich auf die Transaktion beziehen, zur erneuten Verwendung zur Verfügung. Der zugehörige Protokoll-Manager (als "Registriereinrichtung" bezeichnet) verfügt über eine Abbildung von RRS-Namen/Ressourcennamen (siehe Fig. 7). Der Ressourcenname wird in einem WRITE-Aufruf für das Protokoll angegeben. Die Datenmenge, die zur Ressourcenwiederherstellung benötigt wird, ist in der Regel sehr umfangreich.
Dies ist deshalb so, weil diese zur Wiederherstellung benötigten Daten ein Protokoll aller permanenten Änderungen darstellen, die an einer modifizierbaren Ressource vorgenommen wurden.
Zurückkommend auf Fig. 5 ist offensichtlich, daß die Verschiebung der Daten aus dem TRS in den entsprechenden RRS und die Rückforderung von Speicherplatz innerhalb des TRS durch Auslöser der UR-Steuerung bewirkt wird, die von der Registrierungseinrichtung vorgegeben werden. Diese Auslöser sind:
(1) BEGIN/END UR. Dieser gibt die Begrenzungen einer Wiederherstellungseinheit (UR) in Form einer Gruppe von atomischen Anwendungsprogramm-Aktualisierungen für eine Ressource an.
(2) COMMIT UR. Dies ist ein Entscheidungspunkt, der anzeigt, daß eine atomischer Übergangspunkt erreicht wurde. Änderungen an der Ressource werden über Fehler hinweg vorgenommen.
(3) ABORT UR. Dies ist ein Entscheidungspunkt, der anzeigt, daß Programmaktualisierungen widerrufen werden, für den Fall, daß die modifizierbare Ressource teilweise geändert wurde.
Günstigerweise wird beim erfindungsgemäßen Verfahren der Speicherplatz im Protokoll wiederverwendet und ein Lesen der Datensätze zur Medienwiederherstellung während des Systemwiederanlaufs vermieden.
In Fig. 6 ist das Format der Protokolldatensätze innerhalb des TRS dargestellt. Das UR ID-Feld definiert den Programmbereich, zu dem ein gegebener Protokolldatensatz gehört. Das Feld TYP kennzeichnet die Funktion der zugehörigen Daten während der Wiederherstellung. Die Typen können in zwei Kategorien unterteilt werden: UR-Steuerung und Ressourcenwiederherstellung. Der Status der UR-Steuersätze ändert sich in der UR. Die Statusänderungen werden dem Protokoll-Manager über Funktionsaufrufe mitgeteilt. Diese Funktionsaufrufe sind: BEGIN UR, COMMIT UR, ABORT UR und END UR. Jedes Ereignis erzeugt einen UR-Steuerprotokollsatz. Als UR-Steuersätze können folgenden Satzarten unterstützt werden: BEGIN, COMMIT, ABORT und END. Die Datensätze zur Ressourcenwiederherstellung zeichnen die Ressourcenänderungen auf. Als Datensätze zur Ressourcenwiederherstellung werden die Satzarten UNDO und REDO unterstützt. Die REDO-Sätze enthalten die Informationen, die zur Wiederholung der Ressourcenänderung benötigt werden.
Es ist zu beachten, daß das Feld mit dem Ressourcennamen ausschließlich auf die Datensätze zur Ressourcenwiederherstellung anwendbar ist. Dieses Feld bezeichnet die Ressource, die modifiziert wird. Der Ressourcenname erscheint ebenfalls in der in Fig. 7 gezeigten RRS-Abbildungstabelle. Das Feld DATEN schließlich stellt die ressourcenspezifischen oder steuerungsspezifischen Daten dar, die von der Anwendung weitergereicht werden. Der Protokoll-Manager ist nicht sensitiv für das Format oder den Inhalt dieser Daten.
Die nun folgende Fig. 7 zeigt die RRS-Abbildungstabelle. Die Wiederherstellungsdaten für eine Ressource werden in den in dieser Tabelle angegebenen Resource Recovery Stream (RRS) kopiert. Dabei ist zu beachten, daß ein RRS Daten für mehr als eine Ressource enthalten kann, daß heißt eine Eins-zu-n- Abbildung aufweist. Es sei hinzugesetzt, daß nicht wiederherstellbare Ressourcen durch die Bereitstellung einer Null- Ressourcen-RRS-Abbildung unterstützt werden. Somit ist die Ressource d dem Datenstrom RRS NULL zugeordnet. Datensätze für nicht wiederherstellbare Ressourcen stehen für die Transaktionswiederherstellung zur Verfügung, werden aber nicht in einen RRS übertragen.
Die Fig. 8-11 zeigen Pseudocode-Darstellungen der UR-Steuerfunktionen. Bezeichnenderweise weist der Pseudocode-Ausdruck eine Form auf, deren Gebrauch typisch für den Entwurf von Steuerungs- und Datenfluß ist. Veranschaulicht wird dieser Gebrauch von Linger et al in "Structured Programming: Theory and Practice", The System Programming Series, Addison-Wesley Publishing Co., Copyright 1979, ISBN 0-201-14461-1, in den Kapiteln 4-5.
In Fig. 8 ordnet der Pseudocode dem UR-Programmbereich eine ID zu und erstellt einen Protokollsatz im TRS. Zu irgendeinem Zeitpunkt innerhalb der Lebensdauer einer UR fällt die Entscheidung, diese durch ein COMMIT festzuschreiben oder durch ein ABORT abzubrechen. Erfolgt ein COMMIT, so wird die in Fig. 9 dargestellte COMMIT UR-Prozedur der Registriereinrichtung aufgerufen. Es sei daran erinnert, daß vor dem Erreichen des COMMIT- Punktes von verschiedenen Teilnehmern Datensätze in den Datenstrom TRS abgegeben wurden. Die Datensätze werden, sofern anwendbar, vom Transaktions-Manager oder Datenbank-Manager mit REDO/UNDO benannt, als Teil der Informationen, die an die Registriereinrichtung geliefert werden. Die Funktion der Grundelemente, wie sich diese im Steuersatz manifestieren und wie sie beantwortet werden, ist der nachstehend gezeigten Tabelle zu entnehmen: PROZEDUR UR-STEUERSATZ COPY (IM UNTERSCHIED ZU WRITE) BEGIN BEGIN TRS (Erstellen eines UR-Programmbereichs für Protokollsatz) COMMIT COMMIT/REDO TRS/RRS (REDO-Datensätze 1 : n abgebildet) ABORT ABORT/UNDO TRS/RRS (UNDO-Datensätze 1 : n in umgekehrter Abfolge abgebildet) END END TRS (Löschen aus TRS)
Zu beachten ist, daß die ABORT-Prozedur symmetrisch zur COMMIT- Prozedur ist. Die Tabelle deckt die in den Fig. 8-11 dargestellten Prozeduren ab. Erkannt werden muß jedoch, daß die in Fig. 12 gezeigte WRITE-Prozedur auch mehrmals in einen Transaktionsdatenstrom eingebettet werden kann, nach dem Schema BEGIN . . . WRITE,WRITE, . . . COMMIT/ABORT END. Die WRITE-Prozedur stellt einen Datensatz vom Typ UNDO/REDO in den TRS, wenn der Datensatz einen Ressourcennamen enthält, der in der RRS- Abbildungstabelle enthalten ist.
An diesem Punkt sind einige Bemerkungen angebracht. Erstens: der Ausdruck "1:n-Abbildung" bezieht sich auf einen UR-Programmbereich, der auf jeder der m Ressourcen definiert ist, die unter n RRSs aufgeteilt sind. Wenn m > n anwendbar ist, gibt es mindestens einen RRS, der die Datensätze/Wiederherstellungsdaten aus mindestens zwei Ressourcen enthält (siehe Fig. 4). Dies ist ein Beispiel für das "Pigeonhole"-Prinzip nach Dirichelet. Eine weitere Beobachtung ist hinsichtlich der Pseudocode-Prozeduren zu machen. Eine Reihe von Pseudocode-Prozeduren enthalten DO- Blöcke. Diese sind nicht mit DO-Schleifen gleichzusetzen.
DO-Blöcke werden jeweils nur einmal vollständig ausgeführt. Das Ziel in Fig. 5 besteht somit darin, eine Wiederherstellungseinheit (UR) aufzubauen. Der Aufruf der Prozedur wird zwar extern gesteuert, aber vom Protokoll-Manager beantwortet. Dadurch wird der Datensatz in den TRS gestellt.
In Fig. 13 sind zwei URs dargestellt: UR1 und UR2. Die URs werden im weiteren Verlauf die Ressourcen A, B, C und D verändern. In diesem Beispiel werden die zu UR1 gehörenden Daten durch ein COMMIT festgeschrieben, wohingegen bei UR2 ein Abbruch der Datenaktivität durch ein ABORT erfolgt. Bezeichnenderweise wird die Entscheidung, ob ein COMMIT oder ein ABORT erfolgt, außerhalb des Protokoll-Managers getroffen. Die an Beispielen veranschaulichten Aktivitäten umfassen: (1) die Übertragung von Daten aus dem TRS in die RRSs und (2) das anschließende Löschen der aus dem TRS übertragenen Daten als einer Funktion des END- Grundelements.
In Fig. 13 wurden UR1 und UR2 durch entsprechende Pendants der BEGIN-Befehle erstellt und im TRS installiert. Nachdrücklich sei hier darauf hingewiesen, daß die Festlegung eines REDO/UNDO für einen Datensatz durch den Transaktions- oder den Datenbank- Manager, nicht aber durch den Protokoll-Manager bzw. die Registriereinrichtung erfolgt. Die Datensätze in Fig. 13 sind entsprechend ihrer Abfolge auf der linken Seite durchnumeriert. So aktualisieren beispielsweise die Datensätze 1-10 den TRS für UR1 und UR2. Satz 11 beschreibt einen ABORT von UR2 und löst das Kopieren der UNDO-Datensätze 6, 8 und 10 zu UR2 aus dem TRS in den entsprechenden RRS aus. In diesem Zusammenhang wird Datensatz 6 (Ressource A) in den Datenstrom RRS1 gestellt, wohingegen die Datensätze 8 und 10 (Ressource C) in den Datenstrom RRS2 gestellt werden. Die Zuordnung, wie sie in Fig. 14 dargestellt ist, entspricht den Vorgaben der RRS-Abbildungstabelle in Fig. 7. Von Interesse ist dabei, daß die UNDO-Datensätze in umgekehrter Abfolge in den Datenstrom RRS2 gestellt werden. Dies gestattet eine exakte Vorwärtsverarbeitung bei der Ressourcenwiederherstellung. In diesem Zusammenhang sei daran erinnert, daß der ABORT (eine Form der Rückgängigmachung) auf die Rücksetzung abzielt. Der Vollständigkeit halber sei darauf hingewiesen, daß UNDO-Datensätze nur dann im RRS stehen müssen, wenn die Transaktionsverwaltung Kopiervorgänge für die Datenbank bei gleichzeitig vorliegender Transaktionsaktivität unterstützt.
Da die RRSs ausschließlich aus festgeschriebenen Abbildern bestehen, wird dann nur ein Teil der in der TRS-Satzfolge befindlichen Daten für die Ressourcenwiederherstellung benötigt. Im Falle eines ABORTs werden von insgesamt sieben UR2-Datensätzen im TRS nur drei UNDO UR2-Datensätze nach RRS 1 und 2 kopiert.
In den Fig. 15 und 16 ist die für das erfindungsgemäße Verfahren erforderliche Antwort auf einen im TRS als Datensatz 14 aufgezeichneten UR1 COMMIT-Befehl gezeigt. Der COMMIT löst das Kopieren der UR1 REDO-Datensätze 4, 12 und 13 nach RRS1, RRS2 und NULL in dieser Reihenfolge aus. Es ist zu beachten, daß lediglich die Hälfte der im TRS enthaltenen Datensätze in den RRS kopiert werden, da jede Transaktion zum Zeitpunkt der Entscheidung entweder durch einen COMMIT oder einen ABORT gesteuert wird. Bei Steuerung durch einen CONMIT werden nur Datensätze vom Typ REDO in die RRSs kopiert, während bei ABORT nur Datensätze vom Typ UNDO in die RRSs kopiert werden.
Wenn der Befehl END UR1 entgegengenommen wird, wie dies in Fig. 17 gezeigt ist, wird dadurch der Vorgang des Löschens von UR1-Datensätzen aus dem TRS ausgelöst. Wie in Fig. 18 gezeigt, sind die Inhalte der RRSs davon nicht betroffen. Bei der Ausführung des END-Befehls wird jede Spur von UR1 aus dem TRS gelöscht, wie in Fig. 19 zu sehen ist. Wie in Fig. 21 und 23 gezeigt bewirkt die Ausführung des END-Befehls für UR2 gleichfalls ein Löschen entsprechender Datensätze aus dem TRS. Die RRS-Datensatzabfolgen bleiben davon unberührt, wie die Fig. 20, 22 und 24 zeigen.

Claims

1. Ein Verfahren zur Reduzierung der Anzahl von Registrierungsdaten, auf die in einem transaktionsorientierten System zugegriffen wird und die in diesem verarbeitet werden, in dem gleichzeitig ablaufende, fehlerunabhängige Prozesse ein gemeinsames Protokoll benutzen und in dem ferner jede Transaktion die Grundelemente BEGIN, COMMIT, ABORT (REDO/UNDO) und END zur Begrenzung der Transaktion verwendet, REDOs die Rückkehr der Transaktion zum am kürzesten zurückliegenden COMMIT-Punkt sicherstellen, während UNDOs die Rückkehr zum BEGIN-Punkt der Transaktion sicherstellen, und das folgende Schritte umfaßt:

(a) das Einleiten der Aufzeichnung von Registrierungsdaten in einer untergliederten Weise mittels einer Wiederherstellungseinheit (UR) unter Verwendung eines BEGIN-Datensatzes in einem Transaction Recovery Stream (TRS);

(b) das Klassifizieren und anschließende Schreiben von Registrierungsdaten in den TRS in Abhängigkeit von deren Funktion bei der Wiederherstellung (COMMIT, ABORT, REDO, UNDO);

(c) die Durchführung einer Eins-zu-n-Abbildung aller REDO- Registrierungsdaten des UR-Programmbereichs aus dem TRS in zuvor festgelegte, zugehörige Ressource Recovery Streams (RRSs) als Reaktion auf die UR-Statusänderung COMMIT und die Durchführung einer Eins-zu-n-Abbildung von UNDO-Registrierungsdaten des UR- Programmbereichs aus dem TRS in zuvor festgelegte, zugehörige RRSs als Reaktion auf die UR-Statusänderung ABORT; und

(d) beim Abschluß (END) der UR-Statusänderungen unter Verwendung der RRSs, das Entfernen aller Registrierungsdaten, die im Zusammenhang mit dem gegebenen UR-Programmbereich stehen, aus dem TRS.

2. Ein Verfahren gemäß Anspruch 1, bei dem ein UR-Programmbereich, der auf jeder einzelnen von m Ressourcen definiert ist, unter n RRSs aufgeteilt wird, wobei m > n, so daß mindestens ein RRS die Registrierungsdaten aus zwei Ressourcen enthält.