DE69330433T2

DE69330433T2 - Verfahren zur relationsherstellung einer datenbank bei fehlern

Info

Publication number: DE69330433T2
Application number: DE69330433T
Authority: DE
Inventors: Erik Larsson; Maria Sanchez Ivan; Hed Sintorn
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1992-12-08
Filing date: 1993-12-03
Publication date: 2002-05-16
Anticipated expiration: 2013-12-04
Also published as: FI952792A; AU674193B2; WO1994014126A1; DE69330433D1; CN1091846A; FI952792A0; CA2151255A1; KR100266978B1; NO952247D0; EP0673529A1; US5530800A; EP0673529B1; CA2151255C; KR950704752A; JPH08504530A; AU5663394A; SE9203690D0; SE9203690L; SE508828C2; NO952247L

Description

Technisches Gebiet

Die vorliegende Erfindung betrifft ein Verfahren zur Relationsherstellung im Fall von Fehlern.
In einem Datenbanksystem gibt es viele Maßnahmen, die gegen einen Informationsverlust vorgenommen werden können. Normalerweise werden Sicherungskopien und Log(Protokoll)- Listen zum Sichern verwendet, so dass eine Extrakopie der Datenbank vorliegt. Diese werden dann für ein Restaurieren der Datenbank im Falle eines Systemausfalls oder Hardwarefehlern verwendet.
Eine Datenbank weist normalerweise eine Wiederherstellungsfunktion auf, die auf eine Konsistenz von in der Datenbank gespeicherte Daten reagiert, d. h. die den erwarteten Zustand mit Bezug auf unterschiedliche Aktualisierungen und ihre Gruppierung aufweisen.
Um ein Wiederherstellen von Schreibfehlern der Datenbank aufgrund eines Ausfalls zu ermöglichen, muss eine Sicherungs(Backup)version sicher gespeichert werden. Eine Sicherung enthält alle notwendige Information, um die Datenbank wieder in den gleichen konsistenten Zustand zu bringen, der zu dem Zeitpunkt vorlag, als die Sicherung erzeugt wurde.
Eine typische Strategie zum Wiedergewinnen einer Datenbank kann wie folgt zusammengefasst werden:
Falls die Datenbank aufgrund eines aufgetretenen katastrophalen Fehlers inkonsistent wurde, ordnet die Wiederherstellfunktion einen Neustart mit einem Neuladen der Datenbank zur letzten Sicherungsversion an. Um eine Rückkehr in einen aktuelleren Zustand zu erlauben, wird die Datenbank dann mit Information aktualisiert, die in einem Log gespeichert ist, d. h. einer Historie früherer Betriebsvorgänge, gespeichert in einem Speicher, der durch die Wiederherstellfunktion zum Wiederherstellen der letzten erlaubten Transaktionen verwendet wird, d. h. Betriebsvorgängen bezüglich Objekten oder Datensätzen (records) in der Datenbank. Das Konzept eines Objekts umfasst hier die bekannte Bedeutung innerhalb des Standes der Technik der Datenverarbeitung. Kurzgesagt ist ein Objekt ein Informationspaket mit einer zugeordneten Beschreibung, wie die Information zu handhaben ist. Die Objekte sind, wie es auch die Datensätze sind, unterteilt in Klassen gemäss ihrem Anwendungsgebiet, und sind mittels Zeichen identifiziert. Eine detaillierte Beschreibung des Konzepts von Objekten kann beispielsweise gefunden werden in "Object-Oriented Analysis" von Peter Coad und Edward Yourdon, Yourdon Press Computing Series.
Die Informationen und Mechanismen, die für ein Wiederherstellen der Datenbank erforderlich sind, werden durch das für ein Aktualisieren der Datenbank gewählte Verfahren bestimmt. Im Falle eines Aktualisierens eines Objektes wird eine Kopie des ursprünglichen Objektes erzeugt, eine Sperrung wird angefügt, um zu verhindern, dass andere Benutzer die Datenbank aktualisieren, und bei einer Bestätigung, d. h. bei einer Beendigung einer Transaktionsverarbeitung, verwendet durch ein Programm oder einen Bediener, die angibt, dass eine momentane Transaktion beendet ist, und dass ihre Effekte verbleiben sollen, wird die aktualisierte Kopie eingefügt und angefügte Sperren werden freigegeben.
Im Falle, dass ein Fehler in der Datenbank nicht sofort erfasst werden kann, ist eine Datenbankkopie nicht ausreichend. In einem Bankregister kann ein Bediener zum Beispiel aus Versehen einen Kundendatensatz entfernen, trotz der Tatsache, dass immer noch zugeordnete Kontoeinträge vorhanden sind, oder er kann aus Versehen alle Zahlungsbeschwerden entfernen.
Im ersten Fall gibt es gut bekannte Verfahren zum Sicherstellen einer Datenintegrität. Diese werden Integritätsbedingungen genannt. Solch eine Bedingung könnte es beispielsweise sein, dass Kontoeinträge einem Kundenregister zugeordnet sein müssen. Es könnte auch ein etablierter Wiederherstellungsmechanismus vorhanden sein, der vorschreibt, was passieren soll, falls eine Integritätsbedingung verletzt wird. In dem obigen Beispiel könnten einem definitiven Entfernen des Kundendatensatzes gezwungenermaßen aufeinanderfolgende Liquidierungsschritte vorangehen, die zu der Entfernung auch von Kontoeinträgen zusammen mit dem Kundendatensatz führen.
In dem zweiten Fall, bei dem alle Zahlungsbeschwerden entfernt wurden, ist es notwendig, entfernte Datensätze aus einer Sicherungskopie wiederherstellen zu können. Auf der anderen Seite ist es notwendig, dass nicht alle Daten in der Datenbank wiederhergestellt werden, zum Beispiel zwölf Stunden alte Einträge bezüglich Banktransaktionen. Sogar wenn es möglich wäre, nur solche Datensätze aus der Sicherung zu finden und wiederherzustellen, die Zahlungsbeschwerden betreffen, während der Rest der Datenbank aktualisiert verbleibt, müssen auch alle Verletzungen von Integritätsbedingungen gefunden werden können, und entsprechende Wiederherstellungsmaßnahmen müssten genommen werden können, die erforderlich sind für ein Wiedererstellen der Integrität der Datenbank. Es kann dann jedoch schwierig sein, sicherzustellen, dass nicht noch wichtigere Daten durch diese Maßnahmen zerstört werden, zum Beispiel Banktransaktionen.

Stand der Technik

In einem bekannten Datenbankmanagementsystem ist die Funktion implementiert, um Teilsysteme unter Verwendung von vollständig unterschiedlichen Datenbanken wiederherzustellen. Dieses umfasst, dass keine Garantien für eine Konsistenz zwischen den unterschiedlichen Wiederherstellungsteilsystem vorhanden sind, und dass keine Integritätsbedingungen (wie beispielsweise die Existenz einer Abhängigkeit) zwischen Objekten in unterschiedlichen Datenbanken und Teilsystemen erfüllt sind.
Aus der US 4,933,848 ist ein Datenbankmanagementsystem bekannt, in dem Anforderungen an Daten angelegt werden, dass sie Referenzbedingungen aufweisen. Die Datenbank ist eine Relationsdatenbank, in der Daten in Tabellen mit Zeilen und Spalten gespeichert sind. Neue Zeilen werden gespeichert und Information bezüglich diesen und ihrer Beschränkungen werden extrahiert und sortiert. Die neuen Zeilen werden hinsichtlich Beschränkungsverletzungen überprüft, und die Verletzungen werden richtiggestellt, um die Referenzintegrität wieder zu erstellen.
Die GB 2,252,853 bezieht sich allgemein auf ein Speichern und Wiedergewinnen von Daten in einer Relationsdatenbank.

Offenbarung der Erfindung

Es ist eine Aufgabe der Erfindung, ein Verfahren für Relationsherstellung in der Datenbank bereitzustellen, während gleichzeitig ein durchgehender Zugriff auf die Datenbank erlaubt wird, das sicherstellt, dass Daten immer in einem konsistenten Zustand sind und die Konsequenzen eines Datenausfalls im größtmöglichen Ausmaß beschränkt sind.
Die vorliegende Erfindung ist in den beigefügten Ansprüchen definiert.

Beschreibung der Zeichnungen

Ausführungsbeispiele der Erfindung werden nunmehr mit engerem Bezug auf die beigefügten Zeichnungen beschrieben:
Fig. 1 veranschaulicht schematisch eines der Probleme, die zu der vorliegenden Erfindung geführt haben,
Fig. 2 zeigt ein Fig. 1 ähnliches Diagramm, das Ereignisabläufe in Verbindung mit einem ersten Beispiel für eine Wiederherstellung veranschaulicht,
Fig. 3 zeigt ein Fig. 2 zugeordnetes Flussdiagramm,
Fig. 4 zeigt ein Fig. 2 ähnliches Diagramm, das Ereignisabläufe in Verbindung mit einem zweiten Wiederherstellungsbeispiel veranschaulicht, und
Fig. 5 zeigt ein Fig. 4 zugeordnetes Flussdiagramm.

Beschreibung von Ausführungsbeispielen

In der Beschreibung unterhalb wird eine Anzahl von unterschiedlichen Aktoren, Funktionen und Aktionen beschrieben. In diesem Zusammenhang ist darauf hinzuweisen, dass, falls nicht anders bemerkt, dies eine Frage einer Softwarefunktionalität ist, die durch einen Computer, nicht gezeigt, durchgeführt wird. Solche Computer und ihre Funktionsweisen können dergestalt sein, wie es dem Fachmann offensichtlich wird, beim Lesen der unterhalb aufgeführten Beschreibung, und müssen daher nicht weiter erläutert werden. Der in der Beschreibung verwendete Code ist ein Pseudocode für C++ und sollte dem Fachmann auch gut bekannt sein.
In Übereinstimmung mit den kennzeichnenden Merkmalen der Erfindung ist die Erfindung auf der Verwendung von Wiederherstellungs-Untersystemen gegründet, zwischen denen gewisse Abhängigkeitsbezüge existieren können, die unterhalb genauer beschrieben werden. Diese Wiederherstellungs- Untersysteme werden verwendet zur Beschränkung eines Problems auf die Anwendung, die es bewirkt hat. In einer Datenbank umfasst dieses, dass Funktionen vorhanden sind, die ein Rückabwickeln (Rückspulen) von Teilen der Datenbank erlauben, ohne das Log neu zu laden, ohne die gesamte Datenbank rückabzuwickeln. Die Beispiele unterhalb basieren auf der Annahme, dass es mehrere Hierarchieebenen von Wiederherstellungs-Untersystemen gibt.
In dem Diagramm in Fig. 1 ist die horizontale Achse eine Zeitachse. Die schneidende vertikale Achse bezeichnet den Zeitpunkt der letzten Sicherung. Die oberen und unteren Bereiche 2 bzw. 4 veranschaulichen Ereignisabfolgen in einem "oberen" und einem "unteren" Wiederherstellungs-Untersystem. Die kleinen runden nicht schraffierten Bereiche 6 und 8 in den jeweiligen "Ereignisabläufen" bezeichnen Objekte, zwischen denen eine Abhängigkeitsbeziehung existiert. Am Ende des Ereignisablaufs 2 in dem oberen Wiederherstellungs- Untersystem tritt eine Fehlersituation auf, die ein Rückabwickeln dieses Wiederherstellungsteilsystems erforderlich macht, durch einen Pfeil 10 angezeigt.
Die Frage, angezeigt durch einen Pfeil 12, ist nun was mit der Relation zwischen dem Objekt 8 und dem Objekt 6, das nach der Rückabwicklung nicht existiert, passiert.
Das Obige, veranschaulicht mit Bezug auf Fig. 1, ist dazu vorgesehen, eins der Probleme zu veranschaulichen, die durch die vorliegende Erfindung gelöst werden. Insbesondere ist es das Problem, sicherzustellen, dass Integritätsbedingungen, die sich über mehr als einen Datenbankdatensatz erstrecken, und mehr als über ein Wiederherstellungs-Untersystem, nach einem Rückführen eines der Untersysteme gültig sind.
Ein Teil dieser Lösung ist es, eine Anzahl von den Objekten zugeordneten Attributen zu bestimmen, wie auch Relationsherstellungsverfahren für unterschiedliche Situationen.
Unterhalb sind Beispiele für eine Anzahl von Attributen gegeben. Die Abkürzung DOL, unterhalb in dem Namen der Attribute verwendet, kommt von Data Object Logic (Datenobjektlogik), dessen Bedeutung offensichtlich ist.

Attribute

- DOL.Foreign_Dependency (Fremdabhängigkeit)

Dies ist ein Einbitflag, das in einem Transaktionsprotokoll enthalten ist, Transaktionslog und Backup (Sicherung). Falls gesetzt, bedeutet das Flag, dass das Objekt eine direkte Abhängigkeitsrelation zu Objekten in einem weiteren, unteren Wiederherstellungsteilsystem aufweist. Es wird gesetzt durch die Relationslogik, wenn die erste direkte Abhängigkeit eingerichtet wurde, und wird entfernt, wenn die letzte direkte Abhängigkeit entfernt wurde. Nur direkte Abhängigkeiten sind relevant, und somit keine indirekten.
Das Flag wird verwendet durch einen Relationsgewinnungsagenten, um Objekte zu finden, die "roots" (Wurzeln) von Problemhierarchien sein können. Es kann daher geeigneterweise als ein Bit in einem Katalog von Objekten enthalten sein.

- DOL.Not_OK (Nicht-ok)

Dieses ist ein Einbitflag, das nicht in dem Transaktionslog enthalten sein muss, und nicht rückabgewickelt werden muss.
Jedoch muss ein Nullsetzen in dem Transaktionsprotokoll enthalten sein. Falls gesetzt bedeutet das Flag, dass das Objekt in einem Wiederherstellungs-Untersystem enthalten ist, das rückabgewickelt wurde, und die Relationen davon nicht vollständig wiederhergestellt wurden, und dass das Objekt seit einem Rückabwickeln nicht überprüft wurde.
Das Flag ist für alle Objekte gesetzt im Falle eines Rückabwickelns und wird freigegeben für jedes Objekt, wenn es überprüft ist. Wenn der Relationswiederherstellungsagent alle Objekte mit dem gesetzten ForeignDependency Flag überprüft hat, können alle Not OK Flags gelöscht werden. Weiter wird dieses Flag geeigneterweise als ein Bit in den Objektkatalog eingefügt.

- DOL.Depend_on_me

Dieses ist eine Liste von in dem Transaktionsprotokoll, dem Transaktionslog und Backup enthaltenen Referenzen. Die Liste umfasst Referenzen zu allen Objekten mit einer direkten Abhängigkeit vom Selbst-Objekt, und werden durch die Relationslogik von DOL gehalten.
Es wird verwendet für ein Alarmieren von abhängigen Objekten, falls das Selbst-Objekt zerstört wurde und durch die Relationswiederherstellungsfunktion wiedergewonnen wurde.

- DOL.Depending_on

Dieses ist eine Liste von Referenzen, die in dem Transaktionsprotokoll, dem Transaktionslog und Backup enthalten ist. Die Liste umfasst Referenzen zu Objekten, zu denen das Selbst-Objekt direkte Abhängigkeiten aufweist, und wird durch die Relationslogik von DOL gehalten.
Es wird verwendet zum Erzeugen eines Wissensstandes bezüglich solcher Objekte, die überprüft werden müssen, bevor garantiert werden kann, dass das Selbst-Objekt korrekt ist (durch das Verfahren Verify, unterhalb beschrieben). Geeigneterweise wird das Flag mit einer solchen Aufzählung von den Referenzen des Objektes implementiert, dass solche referenztragenden Abhängigkeiten bekannt sind.

- DOL.Rec_Status

Nur in geöffneten Objekten während der Relationswiederherstellung verwendet, muss nicht gespeichert werden, und bedeutet, ob das Selbst-Objekt
in einem Abhängigkeitsbaum enthalten ist, der verifiziert wird (Verifying_Self) zum Vermeiden von Schleifen,
überprüft werden muss, wenn die Verifikation vorgenommen wird (Must_Check),
bereits rückgesetzt wurde (Reset) und somit nicht nochmals rückgesetzt werden soll;
oder falls nichts besonderes anwendbar ist (Normal)
Der DOL.Rec_Status wird gehalten und durch die Relationswiederherstellungsfunktionalität verwendet.
Die obigen in Klammern aufgeführten Bezeichnungen werden unterhalb in Verbindung mit einer Beschreibung von Wiederherstellungsverfahren verwendet.

- RecDB.Rewind_Timestamp (Rückabwicklungszeitmarke)

RecDB (Recovery Data Base), enthalten in dem Namen, bedeutet Wiederherstellungsdatenbank. Es ist die Frage einer Zeitmarkierung, die anzeigt, wann das Wiederherstellungs- Untersystem und somit die Wiederherstellungsdatenbank zuletzt rückabgewickelt wurde.
Es wird verwendet durch die Wiederherstellungsfunktionalität zum Erzeugen eines Wissenstandes von Objekten, die nicht rückabgewickelt wurden, und die daher inkompatible Daten aufweisen können. Es wird gesetzt durch einen Wiederherstellungsmanager in Verbindung mit dem Rückabwickeln.

Relationswiederherstellungsverfahren

Zur Vereinfachung der Beschreibung wird etwas ungenau angenommen, dass Objekte sich selbst öffnen können und dass sie antworten können, dass sie nicht existieren oder dass jemand anderes sie gesperrt hat. Man vergleiche auch die Ausführungsbeispiele, die unterhalb detaillierter beschrieben werden.
In der folgenden Beschreibung sind die Definitionen der Verfahren als Typ-des-Objekts.Name-des-Verfahrens(Typ-des- Arguments formaler_Name) dargestellt. Dies soll so verstanden werden, dass für Objekte des Typs Typ-von-Objekt, das Verfahren Name-von-Verfahren definiert ist, das ein Argument des Typs Typ-von-Argument annimmt. In den Definitionen ist das Argument mit der Bezeichnung formaler_Name bezeichnet.
Ein Aufrufen eines Verfahrens in Übereinstimmung mit Name- von-Verfahren(Argument) soll interpretiert werden als ein Aufrufen des Verfahrens mit dem Namen Name-von-Verfahren mit dem Wert des innerhalb der Klammern bezeichneten Arguments.
Eine Antwort von einem Verfahrensaufruf wird entweder als Antwortcode oder Antwortcode(Definition) bezeichnet, wobei der Antwortcode die Antwort mit einer Definition, falls vorhanden, innerhalb der Klammern bezeichnet.

- DOL.Verify(Transaction TR

Falls das Objekt durch eine andere Transaktion gesperrt ist, sollte die Antwort LOCKED verwendet werden.
Falls das Objekt ein NOT_OK (Nicht_OK) Flag aufweist, das nicht gesetzt ist, oder falls es bereits in der Transaktion TR geöffnet ist, sollte die Antwort V_Ready mit der letzten Rückabwicklungszeit des Teilsystems als ein Argument verwendet werden.
Falls das Objekt nicht geöffnet ist und das NOT_OK Flag gesetzt ist, wird es mit einem Schreiben einer Sperre in TR geöffnet.
Das Attribut Rec_Status ist auf Verifying_Self (Selbstverifizierung) eingestellt. Verify(TR) wird weiter (rekursiv) zu den Objekten gesendet, von denen das Selbst- Objekt abhängt. Falls eins der Objekte gesperrt ist, wird der Versuch abgebrochen und die Antwort V_locked sollte verwendet werden. Falls alle Objekte mit einer richtigen Rückabwicklungszeit antworten, und falls das Alertverfahren (Alarmverfahren) des Selbst-Objektes nicht aufgerufen wurde (d. h. Rec.Status wurde nicht auf Must_Check (Überprüfungszwang) gesetzt, vgl. unterhalb), sollte die Antwort V_ready (Rückabwicklungszeit) verwendet werden und Rec.Status soll auf Normal eingestellt werden. Andernfalls wird das Verfahren Check(TR) des Selbst-Objekts aufgerufen. Falls es erfüllt wird, ist die Antwort V_Ready (Rückabwicklungszeit).

DOL.Check (Transaktion TR)

Die Relationsüberprüfungen des Objekts werden gestartet. Falls sie erfüllt werden, wird das Attribut Rec_Status auf Normal gesetzt.
Falls etwas nicht in Ordnung ist, wird Reset(TR) ausgeführt und Alert (TR) (siehe unterhalb) wird für alle Objekte aufgerufen, die von dem Selbst-Objekt abhängen.

- DOL.Reset (Transaktion TR)

Die Attribute des Objekts erhalten ihre Nulleinstellungswerte, oder andernfalls wird das Objekt entfernt, in Abhängigkeit dessen, was als Relationsherstellungsaktion bestimmt ist.
Das Attribut Rec.Status ist auf Reset eingestellt.
Es gibt vier Arten von Aktionen, die solch ein Wiederherstellungsverfahren kombinieren kann.
- Einstellen eines Attributs. Relativ einfach wird der Status des Objekts rückgesetzt auf etwas was mit der Umgebung kompatibel ist. Die Attributeinstellung muss eine einfache Zuweisung sein, da auf der anderen Seite es nicht von anderen Objekten abhängen darf - diese sind die, die die Probleme hervorrufen - und, auf der anderen Seite, darf es nicht fehlschlagen, da es keinen "alten Wert" gibt, zu dem zurückgekehrt werden könnte.
- Entfernen einer Referenz. Dieses ist die normale Weise, mit Referenzen zu Objekten umzugehen, die nicht existieren. Dieses ist geeignet in einem Fall, in dem optionale Referenzen verschwunden sind, kann jedoch auch in einem Fall mit Kardinalfehlern oder sogar Zustandsfehlern verwendet werden.
- Entfernung des Objekts. Dieses kann geeignet sein im Falle einer Existenzabhängigkeit, oder möglicherweise im Falle einer Kardinalabhängigkeit. Falls das Objekt entfernt wird, gibt es keinen Grund, eine der zwei obenerwähnten Aktionen zu verwenden.
- Sende eine Benachrichtigung zu einem Agenten. Diese Aktion kann verwendet werden, wenn es beispielsweise erwünscht ist, Betreiber oder ähnliches zu informieren.

- DOL.Alert (Transaktion TR)

Falls das Objekt durch eine andere Transaktion gesperrt ist, wird LOCKED zurückgeliefert.
Falls das Objekt nicht offen ist, wird es mit dem Schreibschutz in TR geöffnet, und falls das NOT_OK Flag gesetzt ist, bewirkt es Verify(TR) bezüglich sich selbst. Möglicherweise existierende Fehlercodes werden zurückgeliefert, andernfalls wird Check(TR) des Selbst- Objekts aufgerufen und Fehlercodes oder A_Ready werden zurückgeliefert.
Falls das Objekt offen ist, und damit beschäftigt ist, sich selbst zu verifizieren, d. h. Rec_Status ist Verifying_Self oder Must_Check, wird Rec-Status auf Must_Check eingestellt. A_Ready wird zurückgeliefert.
Falls das Objekt ein Rücksetzen bereits durchgeführt hat, d. h. Rec_Status ist rückgesetzt, wird A_Ready zurückgeliefert, da es nicht weiter möglich ist, das Objekt auf Null zu setzen.
In den verbleibenden Fällen wird Check(TR) aufgerufen und die Fehlercodes oder A_Ready werden zurückgeliefert.

- Zusatz zum Öffnen von Datenbankobjekten

Dies ist ein Zusatz zum normalen Verfahren beim Öffnen eines Objekts, das auf normale Weise vorgenommen wird, falls das Not_OK Flag gesetzt ist. In solch einem Fall wird eine neue Transaktion gestartet und Verify des Selbst-Objekts wird aufgerufen.
Falls LOCKED (oder ein anderer Fehlercode) erhalten wird, wird in Antwort darauf die Transaktion TR unterbrochen und die Antwort wird sein "Relationen nicht voll wiederhergestellt". Das Öffnen hat fehlgeschlagen.
Falls V_Ready(TR) als Antwort erhalten wird, wird die Transaktion ausgeführt, und das Öffnen wird wie gewöhnlich durchgeführt.

Zusätzlich zum Ausführprotokoll

Jedes Mal, wenn ein Objekt als ein Teil einer Transaktion geschrieben wird, wird das Not_OK Flag gelöscht, falls es gesetzt war, da die Relationslogik erfüllt ist.

- Zusatz zu der Relationslogik

Sobald eine Abhängigkeitsrelation für ein Objekt in einer weiteren Relationsherstellungsdatenbank gesetzt ist, wird das Foreign_Dependency Flag gesetzt.
Falls die letzte Abhängigkeit zu einem Objekt in einer anderen Relationsherstellungsdatenbank entfernt wird, wird das Foreign_Dependency Flag gelöscht.
Das Foreign_Dependency Flag ist im Transaktionsprotokoll enthalten.
Unterhalb wird der im Fall einer Relationsherstellung verwendete Algorithmus kurz beschrieben.

Algorithmus im Falle einer Wiederherstellung

- Relationswiederherstellung

- Der Wiederherstellungsmanager der Datenbank initiiert eine Relationsherstellung durch:
- Not_OK (nicht ok) Markieren aller Objekte. Am geeignetsten wird dies durchgeführt, wenn der Objektkatalog sowieso wiedererstellt wird.
- Der Relationsherstellungsmanager (vgl. unterhalb) wird gestartet. Daraufhin kann der Verkehr angeschaltet werden. Dies wird in allen Fällen benötigt, in denen nicht das gesamte Transaktionslog für die Herstellungsdatenbank gelesen wurde.

- Relationsherstellungsmanager

Dieser Agent geht durch ein rückabgewickeltes Wiederherstellungs-Untersystem im Hintergrund. Es ist für die Konsistenz der Datenbank nicht notwendig, aber entfernt existierende Relationsprobleme, um so die meisten davon entfernt zu haben, bevor Objekte durch eine Anwendung geöffnet werden.
Der Algorithmus basiert auf einem Auflösen der Problemketten "von unten". Dies wird durchgeführt, indem durch den Objektkatalog durchgegangen wird, und nach Objekten gesucht wird, bei denen sowohl das Not_OK Flag als auch das Foreign_Dependency Flag gesetzt ist. Wenn solch ein Objekt gefunden wird, wird eine Transaktion TR gestartet und Verify(TR) wird an das Objekt gesendet. Falls die Transaktion gut ausgeht, wird sie festgelegt; falls ein Sperren auftritt wird ein Abbruch durchgeführt und die Suche wird weiter fortgeführt.
Wenn keine Objekte mit sowohl dem Not_OK Flag und dem Foreign_Dependency Flag übrig sind, wurden alle Objekte mit einer direkten Abhängigkeit zu einem anderen Untersystem rückgesetzt, und demgemäss weiter alle Objekte mit einer indirekten Abhängigkeit. Somit können nun alle Not_OK Flags gelöscht sein.
In der obenbeschriebenen Implementierung gibt es nur ein Herstellungsverfahren für jeden Typ von Objekten - d. h. nicht einen für jede Validitätsbedingung. Der Grund dafür sind Leistungsanforderungen, im Grunde wären es jedoch sehr komplexe Abhängigkeiten zwischen unterschiedlichen Validitätsverletzungen und ihren Wiederherstellungen. Beispielsweise könnte eine Verletzung eine Wiederherstellung bedingen, die eine neue Verletzung erzeugt, die eine neue Wiederherstellung erzeugt, die wieder die erste Verletzung erzeugt. Es ist jedoch denkbar, dass eine Implementierung mehr Wiederherstellungsverfahren für jeden Typ von Objekt haben kann.
In Fig. 2 ist eine Situation veranschaulicht, in der ein Ablauf von Ereignissen 20 aufgrund eines Fehlers unterbrochen wurde, zum Zeitpunkt BD2 in einer "oberen" Wiederherstellungsdatenbank, und die letztere wurde rückabgewickelt in Übereinstimmung mit dem Pfeil 22 zum letzten Sicherungsdatum BD1. Die Datenbank enthält die Objekte B1 und B2, die eine wechselseitige Abhängigkeit aufweisen, B1 hat jedoch auch eine Abhängigkeit von einem Objekt A1, das in einem Ereignisablauf 24 in einer "unteren" Herstellungsdatenbank enthalten ist. Nichts wurde geändert, jedoch wurden die Objekte bisher nicht überprüft.
Falls jemand B2 öffnet, Transaktion TR1, passiert das folgende mit Bezug auf Fig. 3:
- Beim Öffnungsaufruf entdeckt die Logik von B2, dass bei B2 das Not_OK Flag gesetzt ist. Daher wird eine neue Transaktion TR2 gestartet, die einen Verify-Aufruf an B2 durchführt.
- Aufgrund dieses Aufrufs wird B2 geöffnet mit einem Schreibschutz und Abhängigkeiten werden untersucht. Die Abhängigkeit zu B1 wird entdeckt, und ein Verify-Aufruf wird bezüglich B1 durchgeführt.
- Aufgrund der Tatsache, dass auch B1 Not_OK ist, wird es geöffnet mit einem Schreibschutz in TR2 und die Abhängigkeitsliste wird überprüft. Die Abhängigkeit zu A1 wird entdeckt, und ein Verify-Aufruf wird bezüglich A1 durchgeführt.
- A1 ist OK und antwortet mit seinem letzten Rückabwicklungsdatum (BD1). Da dieses Datum nicht das gleiche ist wie von B1, ist es möglich, dass A1 mit B2 inkompatible Daten enthält.
- B1 fährt fort mit seiner Liste von Abhängigkeiten und entdeckt die Abhängigkeit bezüglich B2 und sendet einen Verify-Aufruf.
- B2 antwortet direkt mit seinem Datum (BD"), da es bereits offen ist, und somit bereits verifiziert hat.
- Aufgrund der Tatsache, dass B1 die Zeitmarkierung BD1 von A1 empfangen hat, kann A1 inkompatibel sein. Daher muss sich B1 selbst überprüfen, indem es seine Relationslogik (Check) durchführt.
- Dieses findet, dass alles in Ordnung ist; und B1 antwortet V_Ready (BD2) an B2.
- B2 hat keinen Grund seine Auffassung zu ändern, oder sogar die Relationslogik laufen zu lassen, bedingt jedoch die Transaktion TR2.
- Aus diesem Grund werden die Not_OK Flags von B2 und B1 (und A1, von dem bereits herausgefunden wurde, dass es OK ist) gelöscht.
- B2 kann nun wie gewöhnlich für die Transaktion TR1 geöffnet werden.
Im zweiten Ausführungsbeispiel, gezeigt in Fig. 4, wurde ein Ereignisablauf 30 unterbrochen zu einem Zeitpunkt BD2 in einer "oberen" Wiederherstellungsdatenbank, und die letztere wurde rückabgewickelt in Übereinstimmung mit Pfeil 32 zum letzten Sicherungsdatum BD1. Sie umfasst Objekte B1 und B2, die eine wechselseitige Abhängigkeit aufweisen, wobei B1 weiter eine Abhängigkeit von einem Objekt A1 aufweist, enthalten in einem Ereignisablauf 34 in einer "unteren" Herstellungsdatenbank. Seit der Sicherung wurden alle drei Objekte entfernt und A1 existiert immer noch nicht.
Falls jemand B2 öffnet, Transaktion TR1, tritt das folgende mit Bezug auf Fig. 5 auf:
- Zum Öffnungsaufruf entdeckt die Logik von B2, dass das Nicht_OK Flag von B2 gesetzt ist. Daher wird eine neue Transaktion TR2 gestartet, die einen Verify-Aufruf bezüglich B2 durchführt.
- Aufgrund dieses Aufrufs wird B2 mit Schreibschutz geöffnet und Abhängigkeiten werden untersucht. Die Abhängigkeit von B1 wird entdeckt, und ein Verify-Aufruf wird bezüglich B1 durchgeführt.
Aufgrund der Tatsache, dass ebenso B1 Not_OK ist, wird es mit Schreibschutz in TR2 geöffnet, und untersucht seine Abhängigkeitsliste. Die Abhängigkeit von A1 wird entdeckt, und der Verify-Aufruf liefert Not_Found (nicht gefunden) zurück.
- B1 setzt seine Referenz bezüglich A1 auf Null und fährt fort mit seiner Abhängigkeitsliste und entdeckt die Abhängigkeit bezüglich B2 und sendet einen Verify-Aufruf:
- B2 antwortet Verify_Ready, da es bereits Verify durchführt.
- Aufgrund der Tatsache, dass B1 die Antwort Not_Found empfangen hat, muss es sich selbst durch Ablaufen lassen der Relationslogik (Check) überprüfen.
- Dieses deckt auf, dass B1 "auf Null gesetzt" werden muss (Reset) aufgrund von einer Inkonsistenz. Wenn dies durchgeführt ist, müssen alle, die von B1 abhängen, informiert werden, und ein Alert-Aufruf muss bezüglich B2 durchgeführt werden.
- Wenn B2 den Alert-Aufruf empfängt, weiß es, dass es die Relationslogik laufen lassen muss, dies wird jedoch nicht sofort durchgeführt, da nicht alle der Verify-Liste untersucht wurden. Es liefert Alert Ready zurück.
- B1 ist nun fertig und liefert V_Ready (BD2) zurück.
- B2 hat keine weiteren Objekte zu verifizieren, lässt jedoch die Relationslogik (Check) ablaufen.
- Dieses stößt auf Probleme aufgrund der Tatsache, dass B1 geändert wurde, und muss rückgesetzt werden (Reset). Danach müssen alle abhängigen Objekte informiert werden, und ein Alert(Alarm)-Aufruf an B1 gesendet werden.
- B1 weiß, dass es bereits auf Null gesetzt ist, und antwortet daher sofort mit Alert_Ready.
- Die Transaktion TR2 wird begonnen (commited).
- Aufgrund dessen werden die NOT_OK Flags von B2 und B1 auf Null gesetzt.
- B2 kann nun wie gewöhnlich für die Transaktion TR1 geöffnet werden - ist jedoch auf Null gesetzt.

Claims

1. Ein Verfahren zum Wiederherstellen von Relationen in einer Datenbank im Falle von Fehlern, durchgeführt durch einen Computer, wobei

Daten in der Datenbank strukturiert werden als Einheiten von Daten in einer Vielzahl von Herstellungsuntersystemen, wobei jede Einheit von Daten nur einem Untersystem angehört,

umfassend die Schritte:

falls ein Untersystem mindestens eine Dateneinheit enthält, die von einer anderen Dateneinheit in einem anderen Untersystem abhängt, Markieren des Untersystems als von dem anderen Untersystem abhängig,

falls ein erstes Untersystem als von einem zweiten Untersystem als abhängend bezeichnet ist, wobei dieses als von einem dritten Untersystem abhängig markiert ist, rekursives Markieren des ersten Untersystems als von dem dritten Untersystem abhängig,

wobei keine zwei Untersysteme als voneinander abhängig markiert werden und

Integritätseinschränkungen zwischen einer Dateneinheit in einem Untersystem und einer Dateneinheit in einem anderen Untersystem zugelassen werden, vorausgesetzt, dass eines der Untersysteme als von dem anderen abhängig markiert ist, und

Wiederherstellen eines Untersystems, wobei nur Dateneinheiten des Untersystems und von als von diesem abhängig markierten Untersystemen geändert werden.

2. Ein Verfahren nach Anspruch 1, weiter den Schritt umfassend:

Erstellen, gleichzeitig mit einem Durchführen einer Sicherung eines Untersystems, konsistenter Kopien von allen als von dem Untersystem abhängig markierten Untersystemen.

3. Ein Verfahren nach Anspruch 2, weiter den Schritt umfassend:

Wiederherstellen, im Falle einer Wiederherstellung eines Untersystems von einer Sicherungskopie, von Untersystemen, die als von dem von der Sicherungskopie wiederhergestellten System abhängig markiert sind.

4. Ein Verfahren nach einem der vorhergehenden Ansprüche, wobei der Wiederherstellungsschritt nur Aktionen umfasst, die zur Folge haben, dass das Untersystem erneut einen konsistenten Zustand erreicht.

5. Ein Verfahren nach einem der vorhergehenden Ansprüche, wobei der Wiederherstellungsschritt nur solche Untersysteme beeinflusst, die als von dem wiederhergestellten Untersystem abhängig markiert sind.

6. Ein Verfahren nach einem der vorhergehenden Ansprüche, wobei Daten beschrieben und angeordnet sind in Übereinstimmung mit einer objektorientierten Sprache, wobei jedes Objekt ein Informationspaket mit einer zugeordneten Beschreibung umfasst, wie seine Information zu handhaben ist,

und der Wiederherstellungsschritt, wenn widersprechende Werte zwischen Objekten in zwei unterschiedlichen wiederherzustellenden Untersystemen auftreten, ein Ersetzen der widersprechenden Werte mit einem Wert umfasst, der ein vorgegebene Validitätseinschränkungen erfüllt.

7. Ein Verfahren nach Anspruch 6, wobei Attribute der Objekte auf einen vorgegebenen Wert rückgesetzt werden, mittels einer einfachen Zuordnung, um nicht eine Abhängigkeit von anderen Objekten zu erzeugen, und um nicht fehlzuschlagen.

8. Ein Verfahren nach einem der Ansprüche 1 bis 5, wobei Daten beschrieben und angeordnet sind in Übereinstimmung mit einer objektorientierten Sprache und wobei jedes Objekt ein Informationspaket mit einer zugeordneten Beschreibung umfasst, wie seine Information zu handhaben ist, und der Wiederherstellungsschritt, wenn widersprechende Werte zwischen Objekten in zwei unterschiedlichen Untersystem, die wiederhergestellt werden, auftreten, ein Ändern des Zustands der Objekte umfasst.

9. Ein Verfahren nach Anspruch 8, wobei der Wiederherstellungsschritt ein Entfernen eines Bezuges umfasst.

10. Ein Verfahren nach Anspruch 8, wobei der Wiederherstellungsschritt ein Entfernen mindestens eines der Objekte umfasst.

11. Ein Verfahren nach einem der vorhergehenden Ansprüche, bei dem Daten beschrieben und angeordnet sind in Übereinstimmung mit einer objektorientierten Sprache, wobei jedes Objekt ein Informationspaket mit einer zugeordneten Beschreibung umfasst, wie dessen Information zu handhaben ist, und der Wiederherstellungsschritt ein Überprüfen von Relationen umfasst, von denen das Objekt abhängt, durch Anfordern einer Verifikation von allen Objekten, die am anderen Ende der Relationen angeordnet sind, und ein Durchführen von Relationssteuerungen, wenn die Gefahr eines Auftretens von Fehlern besteht.

12. Ein Verfahren nach einem der vorhergehenden Ansprüche, wobei Daten beschrieben und angeordnet sind in Übereinstimmung mit einer objektorientierten Sprache, und wobei jedes Objekt ein Informationspaket umfasst, mit einer zugeordneten Beschreibung, wie dessen Information zu handhaben ist, und der Wiederherstellungsschritt ein Durchführen von Relationsüberprüfungen an einem Objekt umfasst, um so ein Rücksetzen des Objekts im Falle von Fehlern zu umfassen, und ein Informieren von Objekten mit Abhängigkeitsrelationen zum überprüften Objekt, dass diese Relationen von einem Objekt abhängen, das geändert wurde.

13. Ein Verfahren nach einem der vorhergehenden Ansprüche, wobei Daten beschrieben und angeordnet sind in Übereinstimmung mit einer objektorientierten Sprache, wobei jedes Objekt ein Informationspaket umfasst, mit einer zugeordneten Beschreibung, wie dessen Information zu handhaben ist, und der Wiederherstellungsschritt umfasst, im Falle einer Wiederherstellungsverarbeitung, die ein Objekt enthält, ein Durchführen eines von Rücksetzattributen des Objekts, Entfernen von Relationen von dem Objekt, und Entfernen des Objekts, gemäss einer Bestimmung durch die Objektrelationen.

14. Ein Verfahren nach einem der vorhergehenden Ansprüche, wobei Daten beschrieben und angeordnet sind in Übereinstimmung mit einer objektorientierten Sprache, wobei jedes Objekt ein Informationspaket umfasst, mit einer zugeordneten Beschreibung, wie dessen Information zu handhaben ist, und der Wiederherstellungsschritt umfasst, Datenbankoperationen bezüglich überprüften Objekten zu erlauben, bevor alle anderen Objekte überprüft wurden.

15. Ein Verfahren nach einem der vorhergehenden Ansprüche, wobei Daten beschrieben und angeordnet sind in Übereinstimmung mit einer objektorientierten Sprache, wobei jedes Objekt ein Informationspaket umfasst, mit einer zugeordneten Beschreibung, wie dessen Information zu handhaben ist, wobei der Computer einen Wiederherstellungsmanager umfasst, zum Initiieren einer Wiederherstellung von Relationen durch Markieren eines betroffenen Objekts mit einem Flag, das anzeigt, dass das Objekt in einem Relationsherstellungssystem angeordnet ist, dass es rückabgewickelt wurde, und dessen Relationen nicht vollständig wiedergewonnen wurden, und dass das Objekt seit einem Rückabwickeln nicht überprüft wurde, und wobei der Wiederherstellungsschritt ein Starten des Relationsherstellungsmanagers umfasst, und, ein Erlauben von Datenbankbetriebsvorgängen.

16. Ein Verfahren nach Anspruch 15, wobei der Relationsherstellungsmanager die meisten Relationsprobleme entfernt, bevor Objekte geöffnet werden.