DE3854667T2

DE3854667T2 - Datenbasissystem mit einer Baumstruktur.

Info

Publication number: DE3854667T2
Application number: DE3854667T
Authority: DE
Inventors: Frank Eliot Levine; Chandrasekaran Mohan
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1988-04-08
Filing date: 1988-08-03
Publication date: 1996-06-20
Anticipated expiration: 2008-08-04
Also published as: PH27313A; KR890016469A; DE3854667D1; KR930002331B1; ES2079355T3; EP0336035A3; BR8901659A; CN1037044A; JP2505040B2; EP0336035B1; HK71296A; JPH0212460A; CN1021713C; US5123104A; GB8818455D0; SG42824A1; EP0336035A2; MY107385A

Description

Die vorliegende Erfindung betrifft Datenverarbeitungsverfahren und -geräte und speziell ein Verfahren und ein Gerät zur Verwaltung von Datensätzen in einer Datenbank.
Datenbankverwaltungs- oder Transaktionsverarbeitungssysteme sind nach dem Stand der Technik bereits gut eingeführt. Solche Systeme werden gewöhnlich eingesetzt, um einen schnellen Zugriff auf Datenbanktabellen mit zahlreichen Datensätzen zu ermöglichen. Ein relationales Transaktionsverarbeitungssystem ermöglicht den Zugriff auf mehrere Datenbanktabellen, wobei Elemente einer Datenbanktabelle in der Regel mit Elementen einer anderen Datenbanktabelle verknüpft sind. In einer relationalen Datenbank kann der Benutzer die in mehreren Datenbanktabellen enthaltenen Daten anhand eines oder mehrerer spezieller Merkmale oder Felder suchen, abrufen oder ändern.
Ein wichtiger Aspekt aller solchen Datenbanksysteme ist die Fähigkeit des Systems, schnell und effizient Zugriff auf einzelne Datensätze jeder Datenbank zu ermöglichen. Vor kurzem wurden Datenbanksysteme entwickelt, die die gleichzeitige Benutzung der Datenbank durch mehrere Personen ermöglichen, wobei die Benutzer gleichzeitig auf die speziellen Daten zugreifen können.
Datenbankverwaltungssysteme arbeiten gewöhnlich mit einer Indexdatei, um schnell und effizient auf die Datensätze in den Tabellen zugreifen zu können. Diese Indexdateien sind in der Regel in einer B-Baum-Struktur konfiguriert. Der B-Baum ist unter anderem in "Efficient Locking For Concurrent Operation on B-Tree" von Lehman und Yao in ACM Transactions on Database Systems, Band 6, Nummer 4, Dezember 1981, Seite 650 bis 670, beschrieben. Zur Referenzliteratur über B-Baum-Strukturen zählen auch "The Ubiquitous B-Tree" von Comer, Computing Surveys, Band 11, Nummer 2, Juni 1979, Seite 121 bis 137 sowie "Concurrent Operation on B- Trees with Over Taking" von Sagiv, Proceedings ACM SIGACT-SIGMOD Symposium on Principles of Database Systems, März 1985, Seite 28 bis 37.
Die als B-Baumstruktur konfigurierte Indexdatei besteht aus einem Root-Knoten mit mehreren davon abzweigenden Knotenebenen. Zu den in diesen Knoten enthaltenen Informationen zählen Zeiger auf die Knoten der nächsten Ebene oder Zeiger auf Datensätze in der Datenbank. Diese Zeiger enthalten nähere Informationen, sogenannte Schlüsselsatzdaten, die auf die Sätze in den Datenbanken verweisen. Die Satzschlüssel sind über die Knoten hinweg geordnet. Angenommen, es gibt beispielsweise einen Indexbaum für eine alphabetische Namensliste der Mitarbeiter. Der Root-Knoten enthält Referenzschlüsseldaten, die sich auf Datensätze beziehen, auf welche in der nächsten Knotenebene indirekt oder direkt verwiesen wird. Die Referenzschlüssel enthalten Informationen über den verwendeten Index, in diesem Fall also über die Buchstabenfolge der Mitarbeiternamen. Die geordneten Schlüssel im Root- Knoten verweisen deshalb auf die nächste Knotenebene. Mit anderen Worten, der nächste Knoten kann indirekt oder direkt auf alle Mitarbeiternamen verweisen, die mit den Buchstaben A, B und C beginnen. Ein nächster Knoten auf der gleichen Ebene enthält vielleicht die Datensätze der Mitarbeiter, deren Namen mit den Buchstaben D bis M beginnen. Der letzte Knoten dieser Ebene verweist dann auf die Mitarbeiter, deren Namen mit N bis Z beginnen. Bei der Suche durch den Indexdateibaum wird schließlich ein End- oder Blattknoten erreicht. Dieser End- oder Blattknoten enthält Satzschlüssel, die auf die einzelnen Datensätze im Speicher verweisen.
Ein Problem bei gleichzeitigen Zugriffen auf Datenbanktabellen entsteht, wenn mehrere Transaktionen zur gleichen Zeit versuchen, auf denselben Datensatz zuzugreifen. Speziell wenn ein Benutzer einen Datensatz ändern will und ein anderer Benutzer auf eben diesen Datensatz zugreifen will, entsteht eine Konkurrenzsituation. Eine Lösung dieses Konkurrenzproblems besteht im ausschließlichen Zugriff (oder Sperren) der Datensätze oder der betreffenden Teile der B-Baum-Indizes, um sicherzustellen, daß der Indexknoten oder der Datensatz nicht geändert wird, währen ein anderer Benutzer versucht, darauf zuzugreifen. Das Sperren wird in "Index Locking and Splitting", IBM Technical Disclosure Bulletin, Band 25, Nummer 7B, Dezember 1982, Seite 3725 bis 3729, und in "Locking Protocols für Concurrent Operations on B- Trees", IBM Technical Disclosure Bulletin, Band 19, Nummer 10, März 1977, Seite 3887 bis 3889, beschrieben. Der Nachteil des Sperrens besteht darin, daß nur einer der beiden konkurrierenden Benutzer eine Zugriffsmöglichkeit hat. Durch eine möglichst geringe Anzahl von Sperren wäre es möglich, die gleichzeitige Systembenutzung durch mehrere Personen effizienter zu gestalten.
Ein anderer wichtiger Aspekt von Datenbanksystemen ist die Fähigkeit eines solchen Systems, Änderungen der in der Datenbank enthaltenen Daten so vorzunehmen, daß sie wieder rückgängig gemacht werden können. Dies bedeutet, daß diese Systeme sicherstellen, daß bei einer Systemunterbrechung durch Fehler in einer oder mehreren Komponenten entweder alle von einem bestimmten Benutzer eingegebenen Änderungen erhalten bleiben, oder daß keine dieser Änderungen übernommen wird. Entsprechend bekommt auch der Benutzer die Möglichkeit, bis zu einem bestimmten Zeitpunkt anzufordern, daß die von ihm vorgenommenen Änderungen in der Datenbank wieder rückgängig gemacht werden sollen. Die durch den Benutzer vorgenommenen Änderungen der Datenbank werden deshalb als "aufhebbar" bezeichnet. Dieses Konzept ist Bestandteil von Datenbanksystemen, die auf der Basis der Transaktionsverarbeitung arbeiten. Eine Transaktion ist eine logische Arbeitseinheit, die aus einer Folge von Operationen besteht, welche einen ersten konsistenten Zustand einer wiederherstellbaren Datenbankressource in einen anderen konsistenten Zustand umwandelt, ohne daß notwendigerweise in allen Zwischenschritten Konsistenz bewahrt wird. Die Verwendung eines Transaktionsverarbeitungssystems muß gewährleisten, daß wenn eine Transaktion bestimmte Änderungen an einer wiederherstellbaren Datenbankressource vornimmt und ein Fehler auftritt, bevor die Transaktion ordnungsgemäß abgeschlossen oder ein konsistentes Zwischenstadium erreicht ist, die vorgenommenen Änderungen rückgängig gemacht werden.
Da eine Transaktion die Ausführung einer durch die Anwendung vorgegebenen Operationsfolge beinhaltet, wird ihre Existenz im System gewöhnlich mit einer speziellen "ARBEITSBEGINN"-Operation eingeleitet und entweder mit "FESTSCHREIBEN" oder mit "ABBRUCH" beendet. Die Operationen FESTSCHREIBEN und ABBRUCH liefern "atomare" Einheiten, da die Operation FESTSCHREIBEN bedeutet, daß ein neuer Konsistenzpunkt erreicht ist und alle bis dahin von der betreffenden Transaktion vorgenommenen Änderungen permanent festgeschrieben werden müssen. Die Operation ABBRUCH bedeutet, daß ein Fehler aufgetreten ist und alle von der betreffenden Transaktion vorgenommenen Änderungen rückgängig gemacht und die wiederherstellbaren Datenbankressourcen auf den letzten konsistenten Stand gebracht werden müssen.
Um diese Wiederherstellungsgarantie zu ermöglichen, muß das Datenbanksystem in der Lage sein, über Systemausfälle hinweg die noch nicht abgeschlossenen Transaktionen und das Stadium ihrer Änderungsaktionen zu speichern, so daß die Auswirkungen dieser Aktionen auf die wiederherstellbaren Daten bei einem erneuten Systemstart angemessen wiedergegeben werden. Dies wird erreicht, indem der Fortgang jeder Transaktion vom Anfang bis zum Ende sowie die Aktionen, welche Änderungen an wiederherstellbaren Datenbankressourcen bewirken, in einem stabilen Speicher protokolliert werden. Mit Hilfe dieses Protokolls wird gewährleistet, daß die festgeschriebenen Aktionen der Transaktion berücksichtigt werden bzw. die nicht festgeschriebenen Aktionen rückgängig gemacht werden, um sicherzustellen, daß die Datenbank konsistent bleibt. Wenn das Protokoll der Transaktionsoperationen widersprüchliche Datenobjekte widerspiegelt, werden die Protokollsätze auch als Quelle zur Rekonstruktion der fehlerhaften oder verlorengegangenen Daten benutzt. In diesen Systemen wird in der Regel jedem Protokollsatz eine eindeutige Protokollnummer (LSN) zugeordnet, sobald der Satz in das Protokoll geschrieben wird. Die Protokollnummern werden meist in aufsteigender numerischer Reihenfolge zugeordnet. Nach Abschluß der Aufzeichnung einer Änderung einer Speicherseite der Datenbank wird die Protokollnummer des Protokollsatzes für diese Änderung typischerweise ebenfalls auf der betreffenden Seite gespeichert.
Der oben beschriebene Systemtyp wird als System mit Protokollvorausschreibung bezeichnet. In einem System mit Protokollvorausschreibung muß ein Protokolleintrag zu einer bestimmten Operation physisch in einen stabilen Speicher geschrieben werden, bevor neue Versionen der geänderten Daten die vorausgehenden Versionen der Daten im nichtflüchtigen Speicher ersetzen. Unter einem stabilen Speicher ist hier ein nichtflüchtiger Speicher zu verstehen, der auch bei einem Systemausfall intakt und verfügbar bleibt. Ein Beispiel hierfür ist die Verwendung einer magnetischen Festplatte. Zusätzlich wird in solchen Systemen der Transaktionsstatus im Protokoll gespeichert, und keine Transaktion kann als abgeschlossen betrachtet werden, solange sie nicht festgeschrieben ist und alle zugehörigen Protokolldaten sicher im stabilen Speicher aufgezeichnet sind. Beim erneuten Systemstart nach einem Ausfall werden Operationen der Transaktion, die zwar erfolgreich abgeschlossen wurden, denen es vor dem Systemausfall aber nicht mehr gelang, ihre geänderten Ressourcen physisch in den stabilen nichtflüchtigen Speicher zu schreiben, nicht berücksichtigt. Außerdem erlauben solche Systeme nicht, daß eine Transaktion die Fortschreibungsverarbeitung beendet, bevor alle Teile aller Protokollsätze für die betreffende Transaktion physisch protokolliert sind.
In "Data Base Management for HP Precision Architecture Computers" von Brown et al., Hewlett Packard Journal, Band 37, Nummer 12, Dezember 1986, wird ein Datenverarbeitungssystem beschrieben, das ein Datenbanksystem enthält, in welchem mehrere Benutzer mittels einer Baumstruktur gleichzeitig auf Daten in der Datenbank zugreifen können. Der Zugriff umfaßt erste Operationen, in denen die Baumstruktur unverändert bleibt, und zweite Operationen, in denen die Baumstruktur verändert wird. Das Datenverarbeitungssystem enthält Mittel zur Durchführung einer aus einer Folge von Operationen bestehenden Transaktion sowie Wiederherstellungsmittel zur Speicherung der sequentiellen Positionen von Operationen, anhand derer eine Transaktion sozusagen zurückgespult werden kann, damit die Operationen im Fall eines Systemausfalls rückgängig gemacht werden können.
Gemäß Anspruch 1 der vorliegenden Erfindung gibt es jetzt ein Datenverarbeitungssystem mit einem Datenbanksystem, in dem mehrere Benutzer über eine Baumstruktur gleichzeitig auf die Daten in der Datenbank zugreifen können, wobei der Zugriff erste Operationen enthält, in denen die Baumstruktur unverändert bleibt, und zweite Operationen, in denen die Baumstruktur verändert wird, wobei das Datenverarbeitungssystem Mittel zur Durchführung einer aus mehreren Operationen bestehenden Transaktion sowie Wiederherstellungsmittel enthält, mittels derer die sequentiellen Positionen von Operationen gespeichert werden, anhand derer eine Transaktion zurückgespult werden kann, damit die Operationen im Fall eines Systemausfalls rückgangig gemacht werden können. Das System ist dadurch gekennzeichnet, daß das Wiederherstellungmittel Mittel zur Speicherung einer Angabe der sequentiellen Position einer zweiten Operation aus einer Folge von Operationen, welche die Baumstruktur unmittelbar vor Beginn der Sequenz verändert, enthält, ferner Mittel zur Speicherung eines Kompensationsprotokollsatzes, der bei Beendigung der Operationsfolge auf diese Angabe verweist, und Mittel zum Zurückspulen all dieser Operationen der Transaktion anhand der gespeicherten Angabe für den Fall, daß das System ausfällt, bevor die Folge abgeschlossen ist, sowie zum Zurückspulen nur der nicht in der Folge enthaltenen Operationen, wenn die Folge zum Zeitpunkt eines Systemausfalls abgeschlossen ist, anhand des Kompensationsprotokollsatzes.
Unter einem anderen Gesichtspunkt betrachtet liefert die Erfindung ein Verfahren zum Betrieb eines Datenverarbeitungssystem mit einem Datenbanksystem, in dem mehrere Benutzer gleichzeitig über eine Baumstruktur auf die Daten in der Datenbank zugreifen können, wobei der Zugriff erste Operationen enthält, in denen die Baumstruktur unverändert bleibt, und zweite Operationen, in denen die Baumstruktur verändert wird, und wobei das Verfahren aus folgenden Schritten besteht: Durchführung einer aus mehreren Operationen bestehenden Transaktion; Speicherung einer Angabe der sequentiellen Position einer zweiten Operation in einer Folge von Operationen, welche die Baumstruktur verändert, unmittelbar vor Beginn der Folge; Speicherung eines Kompensationsprotokollsatzes, der bei Beendigung der Folge auf diese Angabe verweist; Zurückspulen jeder Operation der Transaktion durch Verweis auf die gespeicherte Angabe für den Fall, daß das System ausfällt, bevor die Folge abgeschlossen ist, sowie im Fall eines Systemausfalls Zurückspulen nur der nicht in der Folge enthaltenen Operationen, wenn die Folge abgeschlossen ist, durch Verweis auf den Kompensationsprotokollsatz.
Ein Ausführungsbeispiel der Erfindung, das im folgenden ausführlicher beschrieben wird, ermöglicht gleichzeitige Änderungen eines Indexbaums in einem Transaktionsverarbeitungssystem. Der Indexbaum enthält mindestens einen Root-Knoten mit einem Schlüsselsatzverweis auf einen oder mehrere Knoten der nächstniedrigeren Ebene und mindestens einen Endknoten, der den Zugriff auf Schlüsselsätze ermöglicht. Transaktionen einschließlich einer Strukturänderungsoperation werden durchgeführt, indem der Indexbaum bis zu dem ausgewählten Knoten durchlaufen und dann ein Hinweis auf die Anhängigkeit einer Strukturänderungsoperation erzeugt wird. Gleichzeitiges Löschen oder Einfügen von Schlüsselsätzen ist im Indexbaum erlaubt, wo kein Hinweis auf eine anhangige Strukturänderungsoperation vorliegt, und wird verzögert, wo ein solcher Hinweis auf eine anhängige Strukturänderungsoperation vorhanden ist. Entsprechend können Transaktionen, bei denen ein Schlüsselsatz gelöscht werden muß, eine Strukturänderungsoperation erfordern, falls die Transaktion keinen neuen Konsistenzpunkt erreicht und rückgängig gemacht werden muß. Aus diesem Grund wird ein Hinweis auf jede Löschung eines Schlüsselsatzes, die noch keinen neuen Konsistenzpunkt erreicht hat, erzeugt, und gleichzeitige Einfügungen von Schlüsselsätzen werden ebenfalls verzögert, bis die Möglichkeit einer Strukturänderungsoperation endet. Nach Abschluß einer Strukturänderungsoperation wird ein Protokollsatz geschrieben, der das Rückgängigmachen der Strukturänderungsoperation im Fall eines Systemausfalls verhindert, unabhängig davon, ob die Transaktion, welche die Strukturänderungsoperation enthält, einen neuen Konsistenzpunkt erreicht hat. In einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung wird nach einer Verzögerung der lokale Knoten daraufhin geprüft, ob ein Schlüsselsatz eingefügt oder gelöscht werden kann, ohne daß der Baum ein zweites Mal durchlaufen werden muß.
Im folgenden wird das bevorzugte Ausführungsbeispiel der Erfindung anhand der beigefügten Zeichnungen exemplarisch beschrieben.
FIGUR 1 ist ein Blockdiagramm eines Datenbanksystems für gemeinsamen Zugriff gemäß der vorliegenden Erfindung.
FIGUR 2 ist ein Flußdiagramm, das eine erste Suchoperation in einer Datenbank illustriert.
FIGUR 3 ist ein Flußdiagramm, das eine Abfrageoperation in einer Datenbank illustriert.
FIGUR 4 ist ein Flußdiagramm, das eine Einfügungsoperation in einer Datenbank illlustriert.
FIGUR 5 ist ein Flußdiagramm, das eine Löschoperation in einer Datenbank illustriert.
FIGUR 6 ist ein Flußdiagramm, das eine Aufhebungsoperation einer Schlüsselsatzeinfügung in einer Datenbank illustriert.
FIGUR 7 ist ein Flußdiagramm, das eine Aufhebungsoperation einer Schlüsselsatzlöschung in einer Datenbank illustriert.
FIGUR 8 ist ein Flußdiagramm, das einen Knotenaufspaltungsalgorithmus illustriert.
FIGUR 9 ist ein Flußdiagramm, das einen Knotenauflösungsalgorithmus illustriert.
Figur 1 ist ein Blockdiagramm eines Datenbanksystems für gemeinsamen Zugriff gemäß der vorliegenden Erfindung. Wie aus dem Diagramm ersichtlich ist, enthält das Datenbanksystem für gemeinsamen Zugriff mehrere interaktive Datenstationen (IWS) 10, die alle mit einem Host 12 verbunden sind. Der Host 12 ist wiederum mit der Datenbank 14 verbunden. Für den Fachmann ist klar, daß außer der abgebildeten Konfiguration auch ein ähnliches System verwendet werden kann, bei dem einzelne Rechner über ein lokales Netzwerk verbunden sind. Jeder Bediener einer interaktiven Datenstation 10 kann mit Hilfe eines Datenbankverwaltungssystems im Host 12 Sätze der Datenbank 14 suchen, abfragen oder ändern. Der Fachmann weiß, daß die Datenbank 14 typischerweise durch Verwendung von Indexdateien zugänglich gemacht wird, welche in der Regel in einer oben beschriebenen B-Baum-Struktur konfiguriert sind. Eine typische B-Baum-Struktur besteht aus mindestens einem Root-Knoten und mehreren davon abzweigenden Knotenebenen. Zu den in den einzelnen Knoten enthaltenen Informationen zählen Zeiger auf Knoten der nächstniedrigeren Ebene oder Zeiger auf Datensätze, die in den auch als Blattknoten bezeichneten Knoten der untersten Ebene in der Datenbank stehen.
Fig. 2 zeigt ein Flußdiagramm einer ersten Suchoperation in einer Datenbank. Die Logik beginnt bei Schritt 100 und geht dann weiter bei Schritt 102, dem Verhängen einer S-Sperre und dem Zugriff auf den Index-Root-Knoten. Eine S-Sperre gewährt anderen konkurrierenden Benutzern beschränkten Zugriff. Dieser beschränkte Zugriff gibt anderen Benutzern die Möglichkeit, die im Knoten gespeicherten Daten abzurufen und zu lesen. Andere Zugriffe wie Löschen oder Ändern der Daten im Knoten sind nicht möglich. Der Index-Root-Knoten gibt die Indexart an und liefert die Anfangsrichtung für den Zugriff auf einen Datensatz in diesem Beispiel. Der Index-Root-Knoten kann beispielsweise den Index als alphabetischen Index in aufsteigender Reihenfolge für mehrere Namen ausweisen. In Schritt 103 wird der Kindknoten, auf den zugegriffen werden soll, nach den Informationen des Elternknotens identifiziert. In Schritt 104 wird danach festgestellt, ob es sich bei der auszuführenden Operation um eine Abrufoperation handelt. Ist die Operation keine Abrufoperation, sondern eine Satzeinfügungsoperation (oder eine Schlüsselsatzeinfügung) oder eine Satzlöschoperation (oder eine Schlüsselsatzlöschoperation), fährt die Zugriffslogik mit Schritt 106 fort, wo festgestellt wird, ob der nächste Knoten unterhalb des Elternknotens ein End- oder Blattknoten ist. Handelt es sich um einen Blattknoten, wird mit Schritt 110 fortgefahren und eine X-Sperre am Kindknoten gesetzt. Die X-Sperre ist eine exklusive Sperre, die alle anderen Zugriffe auf diesen speziellen Knoten ausschließt. Durch Verhängen einer X-Sperre für den betreffenden Knoten hindert das Programm alle anderen Transaktionen am Zugriff auf diesen Knoten.
Wird in Schritt 104 festgestellt, daß es sich um eine Abrufoperation handelt, oder ist in Schritt 106 der Kindknoten kein Blattknoten, fährt das Zugriffsprogramm mit Schritt 108 fort, um den Kindknoten mit einer S-Sperre zu versehen. Die Zugriffslogik fährt dann mit Schritt 112 fort; in diesem Schritt wird festgestellt, ob der Schlüssel des gesuchten Datensatzes größer ist als der höchste Schlüssel im Kindknoten. Dem Fachmann ist selbstverständlich bekannt, daß, falls bei der Suche ein leerer Knoten geprüft wird, automatisch bestimmt wird, daß der gesuchte Schlüssel größer ist als der höchste Schlüssel im Kindknoten. Ist der gesuchte Schlüsselsatz größer als der höchste Schlüssel im Kindknoten, fährt das Programm mit Schritt 114 fort und prüft, ob die Baumindexstruktur gesperrt ist. Ist der Baum nicht gesperrt, geht es weiter mit Schritt 118, wo die Sperren an Eltern- und Kindknoten aufgehoben werden und der Baum gesperrt wird. Die Zugriffslogik springt dann von Schritt 118 zurück zu Schritt 102 und leitet nach der Sperrung des Baums die Operation erneut ein. Der Fachmann weiß, daß Optimierungen möglich sind, um die Anzahl der Knoten zu verringern, auf die zugegriffen werden muß, wenn erneut versucht wird, die Operation auszuführen.
In diesem Beispiel wird der Baum mit einer X-Sperre versehen, wodurch allen anderen Zugriffen mitgeteilt wird, daß gerade eine Änderung der Baumstruktur erfolgt. Läuft gerade ein Zugriff mit X-Sperre ab, wenn der Baum mit einer Sperre versehen werden soll, so muß dieser zweite Zugriff warten, bis der erste beendet ist. Eine S-Sperre des Baums signalisiert allen anderen Zugriffen, daß keine Strukturänderung vorgenommen wird, daß aber eventuell gleichzeitig andere Zugriffe auf den Baum erfolgen. Weitere Änderungen sind erst nach Aufhebung der S-Sperre möglich. Die Baumstruktur kann unabhängig von eventuellen S- oder X-Sperren durchlaufen werden, auch zum Löschen oder Einfügen von Schlüsselsätzen.
War in Schritt 114 der Baum gesperrt oder ist in Schritt 112 der Schlüssel nicht größer als der höchste Schlüssel im Kindknoten, fährt die Logik mit Schritt 116 fort, um festzustellen, ob der Kindknoten ein Blattknoten ist. Ist dies nicht der Fall, fährt das Programm mit Schritt 115 fort, um die Sperre des Elternknotens aufzuheben, und springt dann zu Schritt 103 zurück. Ist der Kindknoten hingegen ein Blattknoten, fährt das Programm mit Schritt 120 fort, um den Elternknoten freizugeben, und springt dann zu den Schritten 122, 124 und 126, um festzustellen, ob es sich um eine Abrufoperation, eine Einfügungsoperation oder eine Löschoperation handelt. In dem abgebildeten Beispiel kehrt das Programm in Schritt 130 wieder zum Benutzer zurück, wenn keine dieser Operationen versucht wurde. In der Praxis würde dabei eine Fehlermeldung ausgegeben, die besagt, daß die auszuführende Operation von diesem Programm nicht identifiziert werden kann.
Ist die auszuführende Operation eine Abrufoperation, fährt die Zugriffslogik mit Schritt 200 in Figur 3 fort. Figur 3 ist ein Flußdiagramm einer Abrufoperation aus einer Datenbank gemäß der vorliegenden Erfindung. In Schritt 200 findet die Logik den angeforderten Schlüssel, der gesucht wird, oder den nächsthöheren Schlüssel in der Datenbank. In Schritt 202 fordert die Logik dann eine bedingte Satzsperre des gefundenen Schlüsselsatzes an. In dem abgebildeten Beispiel wird von einem Datenbankverwaltungssystem, das die Satzschlüsselsperren verwaltet, eine bedingte Satzsperre angefordert. "Bedingt" bedeutet, daß wenn die Sperre nicht sofort gewährt wird, der Zugreifende, der die Sperre angefordert hat, eine Antwort erhält, die besagt, daß die Sperre im Moment nicht gewährt wird. Anhand dieser Antwort wird die Entscheidung in Schritt 204 getroffen. Wurde die Sperre nicht gewährt, fährt die Logik mit Schritt 206, wo die Sperre am Kindknoten aufgehoben wird, und anschließend mit Schritt 208, der Anforderung einer unbedingten Sperre des Schlüsselsatzes, fort. Die Anforderung einer unbedingten Satzsperre wie in Schritt 208 macht es erforderlich, daß der Zugreifende mit der Fortsetzung seiner Operation warten muß, bis eine solche Satzsperre gewährt wird. Nach Gewährung der Satzsperre sperrt die Logik in Schritt 214 den Kindknoten wieder und prüft in Schritt 216, ob sich der Knoten geändert hat. Die Prüfung des Knotens in Schritt 216 wird hier als "lokale Prüfung" bezeichnet und dient zur Steigerung der Effizienz des dargestellten Systems, indem sie es der Logik ermöglicht, wieder vom lokalen Knoten auszugehen, wenn der Knoten nicht wesentlich geändert wurde, anstatt den ganzen Baum ein zweites Mal zu durchlaufen. Ob sich der Knoten geändert hat kann zum Beispiel durch einen Vergleich der im Knoten gespeicherten Protokollnummer mit der vor der Warteperiode aufgezeichneten Protokollnummer festgestellt werden. Wurde der Knoten nicht verändert, wird in Schritt 218 geprüft, ob der Schlüssel der erste im lokalen Knoten ist. Ist dies nicht der Fall, wird der gefundene Schlüsselsatz in Schritt 209 zurückgegeben. Anschließend wird in Schritt 210 die Sperre des Kindknotens aufgehoben. Dem Fachmann ist klar, daß Schritt 211 ausgeführt wird, wenn die Transaktion abgeschlossen ist, oder zu einem früheren Zeitpunkt.
Wird in Schritt 218 hingegen festgestellt, daß der gefundene Schlüssel der erste Schlüssel im Knoten ist, so kehrt die Logik an den Anfang des in Figur 2 dargestellten Prozesses zurück und durchläuft den Baum erneut. Dies ist erforderlich, weil die Möglichkeit besteht, daß der angeforderte Schlüssel nicht gefunden wurde und der gefundene nächsthöhere Schlüsselsatz der erste im lokalen Knoten war. Die Verzögerung durch das Warten auf eine unbedingte Sperre des gefundenen Schlüsselsatzes könnte bedeuten, daß im nächstniedrigeren Knoten ein Schlüsselsatz eingefügt wurde und der angeforderte Schlüssel deshalb möglicherweise vorhanden ist. In diesem Fall muß der Baum erneut durchlaufen werden, um festzustellen, ob der angeforderte Schlüssel vorhanden ist oder nicht.
Wurde in Schritt 216 festgestellt, daß der Knoten geändert wurde, so wird in Schritt 220 geprüft, ob der Knoten noch im gleichen Baum und auf der gleichen Ebene wie der vorherige Kindknoten vorhanden ist. Ist dies nicht der Fall, muß der Baum erneut durchlaufen werden, um den richtigen Kindknoten für den angeforderten Schlüsselsatz zu finden. Sind der Baum und die Ebene des lokalen Knotens trotz der Änderung des Knotens unverändert, wird in Schritt 222 der angeforderte Schlüssel oder der nächsthöhere Schlüssel gesucht. Anschließend wird in Schritt 224 geprüft, ob die Logik wieder denselben Schlüssel gefunden hat wie zuvor. Wenn dies der Fall ist, wurde der richtige Schlüsselsatz gefunden, und der Schlüsselsatz wird durch Schritt 209 wie oben beschrieben zurückgegeben. Wurde nicht der gleiche Schlüssel gefunden wie zuvor, muß der Baum erneut durchlaufen werden, um den richtigen Kindknoten zu finden. Ist im Kindknoten tatsächlich ein Schlüssel vorhanden, der kleiner als der angeforderte ist, wird in Schritt 226 die Sperre des zuvor gefundenen Schlüsselsatzes aufgehoben, und es erfolgt ein Rücksprung zu Schritt 200 zum erneuten Suchen des angeforderten Schlüssels oder des nächsthöheren Schlüssels.
Figur 4 zeigt ein Flußdiagramm einer Einfügungsoperation in eine Datenbank gemäß der vorliegenden Erfindung. Dem Fachmann ist klar, daß vor Beginn der Einfügungsoperation der einzufügende Schlüsselsatz bei Bedarf mit einer X-Sperre versehen wird. Diese Operation würde verwendet, um einen Datensatz in den Speicher des Rechners einzufügen und den Index um einen eingefügten Schlüsselsatz zu erweitern, der den bzw. die betreffenden Knoten des Index aktualisiert, so daß andere Transaktionen auf den neu eingefügten Datensatz zugreifen können.
In Schritt 300 wird zuerst geprüft, ob der einzufügende Schlüsselsatz in den End- oder Blattknoten paßt. Ist dies der Fall, fährt die Logik mit Schritt 304 fort und sucht den nächsten Schlüssel, der größer ist als der einzufügende Schlüssel. Befindet sich der nächste Schlüssel nicht in diesem Knoten, wird auf den darauffolgenden Knoten verwiesen. Gibt es keinen darauffolgenden Knoten, so findet die Zugriffslogik den Nullanzeiger. Anschließend fordert die Zugriffslogik in Schritt 308 eine bedingte X-Sperre des nächsten Schlüsselsatzes an. In Schritt 312 wird festgestellt, ob diese bedingte X-Sperre gewährt wurde. Wurde sie gewährt, fährt die Logik mit Schritt 330 fort und stellt fest, ob das SMO-Bit den Wert Null hat.
Das SMO-Bit ist ein in einem Blattknoten vorhandenes Kennzeichen, das gesetzt wird, wenn eine Transaktion anhängig ist, welche eine Strukturänderungsoperation beinhaltet. Dieses Kennzeichen dient zur Verzögerung der Operation eines Benutzers, während eine Strukturänderungsoperation eines anderen Benutzers noch nicht abgeschlossen ist. Ist die Strukturänderungsoperation dieses Benutzers abgeschlossen, so wird diese bei einem Systemausfall nicht rückgängig gemacht, und das SMO-Bit wird auf Null gesetzt.
Dann wird in Schritt 332 ermittelt, ob das Löschbit den Wert Null hat. Jeder Blattknoten enthält ein Löschbit, das angibt, ob der betreffende Knoten von einer Löschoperation betroffen ist oder war, die noch keinen neuen Konsistenzzustand erreicht hat. Dies ist wichtig angesichts der Tatsache, daß wenn vor Erreichen eines Konsistenz zustandes eine Löschoperation rückgängig gemacht werden muß, die nachfolgende Einfügung des zuvor gelöschten Datensatzes die Aufspaltung eines Knotens erforderlich machen kann, falls im Knoten nicht mehr genügend Platz ist, um das zuvor gelöschte Bit wieder einzufügen. Diese Änderung in der Struktur des Indexbaums kann sich nachteilig auf eine gleichzeitig ablaufende Operation auswirken.
Hat das Löschbit den Wert eins, muß deshalb die versuchte Schlüsselsatzoperation verzögert werden, bis ein neuer Konsistenzpunkt erreicht ist. Sind die beiden genannten Bedingungen erfüllt, zeigt Schritt 334 die Protokollierung der Einfügungsoperation, die in allen Systemen mit Protokollvorausschreibung erforderlich ist. Anschließend fügt Schritt 318 den Schlüssel in den entsprechenden Kindknoten ein. In Schritt 324 wird die Sperre des nächsten Datensatzes und des zugehörigen Schlüsselsatzes wieder aufgehoben. In Schritt 329 werden auch eventuelle Sperren des Knotens aufgehoben, und in Schritt 325 kehrt das Programm zum Benutzer zurück.
Hat in Schritt 330 und 332 entweder das SMO-Bit oder das Löschbit den Wert eins, was bedeutet, daß entweder eine Strukturänderungsoperation anhängig ist oder daß die Möglichkeit besteht, daß durch Rückgängigmachen einer Löschoperation eine Strukturänderungsoperation erforderlich wird, muß die Zugriffslogik eine bedingte S-Sperre des Indexbaums anfordern wie in Schritt 336 dargestellt. In Schritt 338 wird dann geprüft, ob die Sperre gewährt wurde. Wurde sie gewährt, werden in Schritt 340 das SMO- Bit und das Löschbit auf Null gesetzt, bevor in den Schritten 334 und 318 die Einfügung wie oben beschrieben protokolliert und durchgeführt wird.
Wurde in Schritt 336 die bedingte S-Sperre des Baums nicht gewährt, wird in Schritt 342 die Sperre des Knotens aufgehoben, und in Schritt 334 wird eine unbedingte S-Sperre des Baums angefordert. Nach Ablauf einer gewissen Zeit und nach Gewährung der unbedingten S-Sperre wird in Schritt 346 der betreffende Knoten wieder mit einer Sperre versehen. Anschließend wird in Schritt 348 lokal geprüft, ob der Knoten wesentlich geändert wurde. Wurde der Knoten nicht geändert, wird der einzufügende Schlüsselsatz in Schritt 334 und 318 protokolliert und eingefügt.
Wurde der zuvor gefundene Knoten wesentlich geändert, wird in Schritt 350 geprüft, ob der gefundene Knoten sich im gleichen Indexbaum und auf der gleichen Ebene befindet. Ist dies nicht der Fall, kehrt die Logik zu der in Figur 2 dargestellten Abrufoperation zurück, und der Baum wird erneut durchlaufen, um den richtigen Knoten zu ermitteln.
Falls der gefundene Knoten geändert wurde, Baum und Ebene jedoch identisch sind, wird in Schritt 352 geprüft, ob der einzufügende Schlüssel auf den lokalen Knoten begrenzt ist. Ist dies der Fall, muß der Baum nicht erneut durchlaufen werden, und die Einfügung wird gemäß Schritt 334 und 318 protokolliert und durchgeführt. Ist der Schlüssel nicht auf den Knoten begrenzt, beginnt wie oben die in Figur 2 dargestellte Prozedur zum Suchen und Identifizieren des richtigen Knotens für die Schlüsseleinfügung.
Wurde in Schritt 312 die bedingte X-Satzsperre des nächsten Schlüsselsatzes nicht gewährt, fährt die Logik mit Schritt 316 fort und hebt die Sperre am Kindknoten auf. Dann wird in Schritt 322 eine unbedingte X-Sperre für den nächsten Schlüsselsatz angefordert. Nach Gewährung der unbedingten X-Sperre zeigt Schritt 354 das erneute Sperren des Knotens, und in Schritt 356 wird geprüft, ob der Knoten während der Warteperiode wesentlich geändert wurde. Wurde er nicht geändert, wird in Schritt 360 festgestellt, ob der einzufügende Schlüssel auf den Knoten begrenzt ist, und wenn dies der Fall ist, wird die Einfügung gemäß Schritt 334 und 318 protokolliert und durchgeführt.
Wurde der Knoten geändert, wird in Schritt 358 geprüft, ob Baum und Ebene des Knotens gleich geblieben sind. Wurden sie geändert, so wird wieder die in Figur 2 dargestellte Prozedur zum Suchen des richtigen Knotens eingeleitet. Sind sie gleich geblieben, wird in Schritt 360 festgestellt, ob der einzufügende Schlüsselsatz auf den lokalen Knoten begrenzt ist. Ist dies nicht der Fall, beginnt die Suchprozedur aus Figur 2 von neuem wie oben beschrieben. Ist der einzufügende Schlüsselsatz auf den lokalen Knoten begrenzt, kehrt das Programm zu Schritt 300 zurück und folgt der oben beschriebenen Prozedur.
Paßt in Schritt 300 der einzufügende Schlüsselsatz nicht in den Blattknoten, fährt das Programm mit Schritt 302 fort und fordert eine bedingte X-Sperre des Indexbaums an. In Schritt 306 wird dann geprüft, ob die bedingte Sperre gewährt wurde. Wurde sie nicht gewährt, fährt die Logik mit Schritt 310 fort und hebt die Sperre am Kindknoten auf. Anschließend wird in Schritt 314 eine unbedingte X-Sperre des Indexbaums angefordert. Nach Gewährung der unbedingten X-Sperre für den Indexbaum wird in Schritt 362 der Knoten wieder gesperrt, und in Schritt 364 wird geprüft, ob der lokale Knoten während der Warteperiode geändert wurde.
Wurde der Knoten geändert, wird der in Schritt 320 genannte Knotenaufspaltungsalgorithmus, der weiter unten ausführlicher beschrieben wird, aufgerufen. Anschließend wird der Baum freigegeben, und der Einfügungsprozeß kehrt zu Schritt 300 zurück, um den Schlüsselsatz je nach Schlüsselwert entweder in den neu eingerichteten Knoten oder in den ursprünglich gefundenen Knoten einzufügen. Wurde der gefundene Knoten geändert, wird in Schritt 366 geprüft, ob Baum und Ebene des lokalen Knotens gleich geblieben sind. Ist dies nicht der Fall, kehrt die Logik wie oben beschrieben zu dem in Figur 2 dargestellten Suchprozeß zurück, um den richtigen Blattknoten zu suchen. Sind Baum und Ebene des lokalen Knotens gleich geblieben, wird in Schritt 368 festgestellt, ob der einzufügende Schlüsselsatz auf den lokalen Knoten begrenzt ist. Ist dies nicht der Fall, wird die in Figur 2 beschriebenene Suchprozedur erneut ausgeführt. Ist der einzufügende Schlüsselsatz hingegen auf den Knoten begrenzt, so kehrt die Logik zu Schritt 300 zurück und vollzieht die zum Einfügen des Schlüsselsatzes erforderlichen Schritte.
Figur 5 zeigt ein Flußdiagramm einer Löschoperation in einer Datenbank gemäß der vorliegenden Erfindung. Dem Fachmann ist klar, daß vor Beginn der Löschoperation der zu löschende Schlüsselsatz bei Bedarf mit einer X-Sperre versehen wird. In Schritt 400 sucht die Logik den nächsthöheren Schlüssel bezüglich des zu löschenden Schlüssels. In Schritt 402 wird eine bedingte X-Satzsperre dieses nächsthöheren Datensatzes angefordert. Dann wird in Schritt 404 geprüft, ob die bedingte X-Satzperre gewährt wurde. Wurde sie nicht gewährt, wird in Schritt 406 die Sperre des Kindknotens aufgehoben und dann in Schritt 410 eine unbedingte Satzsperre für den nächsten Schlüsselsatz angefordert.
Nach dem Warten auf die Gewährung der unbedingten Satzsperre wird in Schritt 456 der Kindknoten wieder mit einer Sperre belegt. Anschließend wird in Schritt 458 geprüft, ob der lokale Knoten während der Warteperiode wesentlich geändert wurde. Wurde er nicht geändert, wird in Schritt 462 festgestellt, ob der zu löschende Schlüssel noch vorhanden ist. Ist er noch vorhanden, kehrt die Logik zu Schritt 400 zurück und beginnt den Löschprozeß. Ist er nicht mehr vorhanden, wird der Suchprozeß aus Figur 2 erneut ausgeführt.
Wurde der lokale Knoten wesentlich geändert, wird in Schritt 460 geprüft, ob Baum und Ebene des Knotens gleich geblieben sind. Ist dies nicht der Fall, kehrt die Logik zu dem in Figur 2 dargestellten Suchprozeß zurück. Sind Baum und Ebene des lokalen Knotens gleich geblieben, wird in Schritt 462 geprüft, ob der zu löschende Schlüssel noch im lokalen Knoten vorhanden ist. Ist er nicht mehr vorhanden, kehrt die Logik wieder zu der in Figur 2 dargestellten Suchprozedur zurück, um den richtigen Blattknoten zu suchen. Ist der zu löschende Schlüssel hingegen noch im lokalen Knoten vorhanden, kehrt die Logik zu Schritt 400 zurück und beginnt den Löschprozeß.
Wurde in Schritt 404 die bedingte X-Satzsperre des nächsten Schlüsselsatzes gewährt, wird in Schritt 432 festgestellt, ob der zu löschende Schlüssel auf den lokalen Knoten begrenzt ist. Ist dies der Fall, wird in Schritt 434 geprüft, ob das SMO-Bit den Wert Null hat, was bedeutet, daß der betreffende Blattknoten nicht von einer noch nicht abgeschlossenen Strukturänderungsoperation betroffen ist. Wenn das SMO-Bit den Wert Null hat, wird in Schritt 436 das Löschbit auf Eins gesetzt, was bedeutet, daß in dem betreffenden Knoten ein Schlüsselsatz in einer Transaktion gelöscht wurde&sub1; die noch keinen neuen Konsistenzpunkt erreicht hat. Anschließend wird der zu löschende Satz in Schritt 437 protokolliert und in Schritt 408 gelöscht.
Ist der zu löschende Schlüsselsatz nicht auf den Blattknoten begrenzt oder hat das SMO-Bit nicht den Wert Null, wird in Schritt 438 eine bedingte S-Sperre des Indexbaums angefordert. Wurde die S-Sperre gewährt und dies in Schritt 440 festgestellt, werden nun in Schritt 442 das SMO-Bit und das Löschbit auf Null gesetzt, und die Löschung wird in den Schritten 437 bzw. 408 protokolliert und durchgeführt. Wurde die angeforderte bedingte Sperre des Knotens aufgehoben, und in Schritt 446 wird eine unbedingte S-Sperre des Indexbaums angefordert.
Nach dem Warten auf die Gewährung der unbedingten S-Sperre wird in Schritt 448 der Kindknoten wieder mit einer Sperre versehen, und in Schritt 450 wird lokal geprüft, ob der Knoten während der Warteperiode wesentlich geändert wurde. Wurde er nicht geändert, kehrt die Logik zu Schritt 442 zurück, wo das SMO-Bit und das Löschbit auf Null gesetzt werden, und die Löschung wird dann in Schritt 437 und 408 protokolliert und ausgeführt. Wurde der Knoten wesentlich geändert, wird in Schritt 452 geprüft, ob der Knoten sich noch im gleichen Baum und auf der gleichen Ebene befindet. Befindet sich der Knoten noch im gleichen Baum und auf der gleichen Ebene, wird in Schritt 454 festgestellt, ob der zu löschende Schlüsselsatz noch im Knoten vorhanden ist. Ist dies der Fall, kehrt das Programm zu Schritt 400 zurück und beginnt den Löschprozeß. Befindet sich der lokale Knoten nicht mehr im gleichen Baum oder auf der gleichen Ebene, kehrt die Logik zu der in Figur 2 dargestellten Suchprozedur zurück, um den richtigen Blattknoten für diese Operation zu ermitteln.
Nachdem der Schlüsselsatz in Schritt 408 gelöscht wurde, fährt die Logik mit Schritt 412 fort und prüft, ob der Knoten, der den gelöschten Schlüsselsatz zuvor enthalten hatte, jetzt leer ist. Ist er nicht leer, hebt die Logik in Schritt 421 die Sperre des Knotens auf und kehrt in Schritt 414 zum Bediener zurück. Ist der Knoten hingegen leer, wird in Schritt 416 eine bedingte X- Sperre des Indexbaums angefordert. Anschließend wird in Schritt 418 geprüft, ob die bedingte Sperre gewährt wurde. Ist dies der Fall, fährt die Logik mit Schritt 424 fort und führt den später näher beschriebenen Knotenauflösungsalgorithmus aus. Der Knotenauflösungsalgorithmus entfernt den leeren Knoten und die Verweise auf den leeren Knoten aus den Knoten, die dem leeren Knoten im Indexbaum vorausgehen. Anschließend wird in Schritt 426 die Sperre des Baums aufgehoben, und in Schritt 430 kehrt die Logik zum Bediener zurück.
Wurde in Schritt 418 festgestellt, daß die angeforderte X-Sperre des Indexbaums nicht gewährt wurde, so wird in Schritt 420 die Sperre des Kindknotens aufgehoben und in Schritt 422 eine unbedingte X-Sperre des Baums angefordert. Nach dem Warten auf die Gewährung der unbedingten X-Sperre des Indexbaums wird in Schritt 423 geprüft, ob der betreffende Knoten während dieser Wartezeit geändert wurde. Wurde er geändert, erfolgt in Schritt 425 eine Rückkehr zum Bediener. Wurde der Knoten nicht geändert, werden der Knotenauflösungsalgorithmus und die oben beschriebenen nachfolgenden Schritte ausgeführt.
Figur 6 zeigt ein Flußdiagramm einer Operation zum Rückgängigmachen einer Schlüsselsatzeinfügung in einer Datenbank gemäß der vorliegenden Erfindung. Für den Fachmann ist klar, daß wenn beim Einfügen eines Schlüsselsatzes in einer Transaktion das System ausfällt, bevor ein neuer Konsistenzpunkt erreicht ist, die Einfügung rückgängig gemacht werden muß. Dies entspricht dem Löschen eines Schlüsselsatzes. Wie in Figur 6 zu sehen ist, besteht der erste Schritt beim Rückgängigmachen einer Schlüsselsatzeinfügung darin, anhand des Protokollsatzes den richtigen Knoten zu ermitteln wie in Schritt 500 angegeben. Anschließend wird der betreffende Knoten in Schritt 502 mit einer X-Sperre versehen, und in Schritt 504 werden das SMO-Bit und das Löschbit auf Null gesetzt, wenn die Einfügungsoperation aufgrund eines Neustarts des Systems rückgängig gemacht werden muß. Anschließend wird in Schritt 506 geprüft, ob der betreffende Knoten sich im gleichen Baum und auf der gleichen Ebene befindet wie vor dem Systemausfall, aufgrund dessen die Einfügung rückgangig gemacht werden muß. Entsprechend wird in Schritt 508 festgestellt, ob der zu löschende Schlüssel im Knoten vorhanden ist. Sind Baum und Ebene nicht gleich geblieben oder ist der Schlüssel nicht vorhanden, muß die Logik zu der in Figur 2 dargestellten Suchprozedur zurückkehren. Anschließend wird in Schritt 510 geprüft, ob das SMO-Bit den Wert eins hat, was bedeutet, daß der Knoten von einer noch nicht abgeschlossenen Strukturänderungsoperation betroffen ist. Hat das SMO-Bit nicht den Wert eins, wird in Schritt 512 geprüft, ob der zu löschende Schlüssel der erste oder der letzte Schlüssel im Knoten ist. Hat das SMO-Bit den Wert eins oder ist der zu löschende Schlüssel der erste im Knoten, wird in Schritt 514 eine bedingte S-Sperre des Baums angefordert. Dann wird in Schritt 516 festgestellt, ob die Sperre gewährt wurde. Ist dies der Fall, so werden in Schritt 518 das SMO-Bit und das Löschbit auf Null gesetzt.
Hat das SMO-Bit nicht den Wert eins und ist der zu löschende Schlüssel nicht der erste im betreffenden Knoten, wird in Schritt 520 ein Protokollsatz geschrieben, bevor der Schlüsselsatz gelöscht wird. Danach wird der Schlüsselsatz in Schritt 522 gelöscht, und in Schritt 528 wird geprüft, ob der Knoten jetzt leer ist. Ist dies nicht der Fall, erfolgt in Schritt 530 eine Rückkehr zum Bediener. Ist der Knoten nach dem Löschen des Schlüsselsatzes leer, führt die Logik in Schritt 532 den Knotenauflösungsalgorithmus aus. Anschließend wird in Schritt 534 die Sperre des Baums aufgehoben, und in Schritt 536 kehrt die Logik zum Bediener zurück.
Wurde in Schritt 516 festgestellt, daß die angeforderte bedingte S-Sperre des Baums nicht gewährt wurde, wird in Schritt 524 die Sperre des Knotens aufgehoben, und in Schritt 526 wird eine unbedingte S-Sperre des Baums angefordert. Danach kehrt die Logik zu Schritt 502 zurück und beginnt nach Gewährung der unbedingten S-Sperre, die Schlüsselsatzeinfügung rückgängig zu machen.
Figur 7 zeigt ein Flußdiagramm, in dem die Löschung eines Schlüsselsatzes in einer Datenbank gemäß der vorliegenden Erfindung rückgängig gemacht wird. Dem Fachmann ist klar, daß es zur Erhaltung der Konsistenz eines Indexbaums von Zeit zu Zeit erforderlich ist, eine Operation, die noch keinen neuen Konsistenzpunkt erreicht hat, rückgängig zu machen, wenn vor Beendigung der Operation das System ausgefallen ist oder ein anderer Fehler aufgetreten ist. Zum Rückgängigmachen einer Schlüsselsatzlöschung wird ähnlich vorgegangen wie zum Rückgangigmachen einer Schlüsselsatzeinfügung. Zuerst wird in Schritt 600 anhand des Protokollsatzes, der nach dem Protokollvorausschreibungsverfahren angelegt und verwaltet wurde, der richtige Knoten ermittelt. Dann wird der Knoten in Schritt 602 mit einer X-Sperre versehen, und in Schritt 604 werden das SMO-Bit und das Löschbit auf Null gesetzt, falls die Operation aufgrund eines Neustarts nach einem Systemausfall rückgängig gemacht werden muß.
In Schritt 606 wird festgestellt, ob der Knoten sich im gleichen Baum und auf der gleichen Ebene befindet wie vor der Situation, die das Rückgängigmachen erforderlich machte. Ist dies nicht der Fall, wird die in Figur 2 dargestellte Suchprozedur wiederholt. In Schritt 608 wird dann geprüft, ob der zu löschende Schlüssel auf den Knoten begrenzt ist. Ist dies nicht der Fall, wird wieder die in Figur 2 dargestellte Suchprozedur ausgeführt.
Ist der zu löschende Schlüssel auf den lokalen Knoten begrenzt, so wird in Schritt 610 geprüft, ob das SMO-Bit den Wert eins hat, was wie oben beschrieben bedeutet, daß der betreffende Knoten von einer anhängigen Strukturänderungsoperation betroffen ist. Hat das SMO-Bit nicht den Wert eins, so wird in Schritt 612 festgestellt, ob das Löschbit den Wert eins hat, was bedeutet, daß in dem betreffenden Knoten ein Datensatz in einer Transaktion gelöscht wurde, die noch keinen neuen Konsistenzpunkt erreicht hat.
Hat weder das SMO-Bit noch das Löschbit den Wert eins, fährt die Logik mit Schritt 624 fort und prüft, ob der einzufügende Schlüsselsatz in den betreffenden Knoten paßt. Wurde in den Schritten 610 und 612 festgestellt, daß entweder das SMO-Bit oder das Löschbit den Wert eins hat, wird in Schritt 614 eine bedingte S-Sperre des Baums angefordert. In Schritt 616 wird dann festgestellt, ob die S-Sperre gewährt wurde. Ist dies der Fall, werden in Schritt 622 das SMO-Bit und das Löschbit auf Null gesetzt, bevor in Schritt 624 festgestellt wird, ob der einzufügende Schlüssel im Knoten Platz findet.
Wurde die in Schritt 614 angeforderte S-Sperre des Baums nicht gewährt, wird in Schritt 618 die Sperre des Knotens aufgehoben, und in Schritt 620 wird eine unbedingte S-Sperre des Baums angefordert. Nach Gewährung einer unbedingten S-Sperre kehrt die Logik zu Schritt 602 zurück, wo eine X-Sperre über den Knoten verhängt wird und der Prozeß von vorne beginnt.
Wurde in Schritt 624 festgestellt, daß der einzufügende Schlüsselsatz nicht in den Knoten paßt, wird in Schritt 626 der Knotenaufspaltungsalgorithmus aufgerufen. Anschließend wird in Schritt 628 die Sperre des Baums aufgehoben, und das Programm kehrt wieder zu Schritt 602 zurück, um die Prozedur von vorne zu beginnen. Paßt der einzufügende Satz hingegen in den betreffenden Knoten, wird in Schritt 630 ein Protokollsatz geschrieben, bevor dann in Schritt 632 die Einfügung vorgenommen wird. Danach erfolgt in Schritt 634 eine Rückkehr zum Benutzer.
Figur 8 zeigt ein Flußdiagramm eines Knotenaufspaltungsalgorithmus. Wie aus der Zeichnung ersichtlich ist, beginnt der Knotenaufspaltungsalgorithmus mit der Speicherung einer Protokollnummer, die der Operation zugeordnet ist, welche unmittelbar vor der Knotenaufspaltungsoperation ausgeführt wurde. Dem Fachmann ist klar, daß dies bei einer vorwärtsgerichteten Transaktion die Protokollnummer unmittelbar vor dem Knotenaufspaltungsalgorithmus ist; wenn jedoch beim Rückgangigmachen einer Operation eine Knotenaufspaltungsoperation notwendig wird, ist die Protokollnummer diejenige der Operation, die unmittelbar nach der fraglichen Operation stattgefunden hat.
Dann wird in Schritt 702 eine X-Sperre über den Baum verhängt, und in Schritt 704 wird die Notwendigkeit eines neuen Knotens nach dem Protokollvorausschreibungsverfahren protokolliert. Nun wird in Schritt 706 der neue Knoten erstellt, und in Schritt 708 werden bei Bedarf der neue und der alte Knoten mit einer X-Sperre belegt. In Schritt 710 werden die Änderungen der Schlüsselpositionen nach dem Protokollvorausschreibungsverfahren in ein Protokoll geschrieben, bevor dann in Schritt 712 ein Teil der Schlüssel aus dem alten Knoten in den neuen verschoben wird. Außerdem wird in Schritt 712 das SMO-Bit im betroffenen Blattknoten auf eins gesetzt, so daß gleichzeitig auf die Datenbank zugreifende Benutzer feststellen können, daß dieser Knoten von einer noch nicht abgeschlossenen Strukturänderungsoperation betroffen ist.
Dann werden in Schritt 714 der alte und der neue Knoten freigegeben, und in Schritt 716 wird der Elternknoten mit einer X- Sperre versehen. Eventuell erforderliche Änderungen im Elternknoten werden dann in Schritt 718 protokolliert, und in Schritt 720 wird der Elternknoten aktualisiert. Anschließend wird in Schritt 722 die Sperre des Elternknotens aufgehoben, und in Schritt 724 wird ein Dummy-Kompensationsprotokollsatz (CLR) in den Protokollspeicher geschrieben, der auf die gespeicherte Protokollnummer (LSN) verweist. Wie der Fachmann weiß, ist ein Dummy-Kompensationsprotokollsatz ein Protokoll, das den Ort oder Zeitpunkt angibt, an dem eine Operation rückgängig gemacht wird, so daß diesem Satz zu entnehmen ist, wieviel und was zu diesem Zeitpunkt rückgängig gemacht wurde. Auf diese Weise wird eine eben beendete Strukturänderungsoperation nicht rückgängig gemacht, auch wenn das System ausfällt, bevor die beteiligte Transaktion einen neuen Konsistenzpunkt erreicht hat. Bei einem solchen Systemausfall bewirkt der Dummy-CLR-Satz, daß der Algorithmus zum Rückgängigmachen auf die Operation springt, die unmittelbar vor Beginn der Durchführung der Strukturänderungsoperation stattgefunden hat. Eine Transaktion, bei der eine Strukturänderungsoperation erfolgte, wird so im Ganzen rückgängig gemacht, wenn die Strukturänderungsoperation noch nicht abgeschlossen ist; war die Strukturänderungsoperation jedoch vor dem Systemausfall oder einem Abbruch während der normalen Verarbeitung abgeschlossen, so werden nur die Operationen der Transaktion rückgängig gemacht, die die Struktur nicht verändert haben. Es ist anzumerken, daß dies effektiv verhindert, daß eine bereits abgeschlossene Strukturänderungsoperation rückgängig gemacht wird, auch wenn die Transaktion, in deren Verlauf die Strukturänderungsoperation ausgeführt wurde, keinen Festschreibungsstatus erreicht hat. Auf diese Weise ist ein höherer Grad gemeinsamer Nutzung möglich, da das System eine Strukturänderung festschreiben kann, ohne daß die Transaktion einen Festschreibungsstatus erreicht haben muß.
Figur 9 schließlich zeigt ein Flußdiagramm eines Knotenauflösungsalgorithmus gemäß der vorliegenden Erfindung. Wie der Zeichnung zu entnehmen ist, beginnt der Prozeß ähnlich wie bei dem beschriebenen Knotenaufspaltungsalgorithmus mit der Speicherung einer Protokollnummer (LSN) in Schritt 800. Anschließend wird der Baum in Schritt 802 mit einer X-Sperre belegt, und der benachbarte Knoten und der alte Knoten werden bei Bedarf mit einer X-Sperre versehen.
Die Schlüsselverschiebung beim Auflösen des Knotens wird in Schritt 806 nach dem oben beschriebenen Protokollvorausschreibungsverfahren protokolliert, und in Schritt 808 werden die Schlüssel vom benachbarten Knoten in den leeren Knoten verschoben. Außerdem wird in Schritt 808 das SMO-Bit auf eins gesetzt, so daß gleichzeitig zugreifende Benutzer wissen, daß eine Strukturänderungsoperation bezüglich dieses Knotens im Gange ist. Anschließend wird in Schritt 810 der Vorwärtsknotenzeiger aktualisiert, und in Schritt 812 wird der benachbarte Knoten aufgelöst.
Die Sperren des Kindknotens und des benachbarten Knotens werden dann in Schritt 814 aufgehoben, und in Schritt 816 wird der Elternknoten mit einer X-Sperre versehen, bevor er geändert wird. In Schritt 818 werden die Änderungen am Elternknoten protokolliert, bevor die Änderungen in Schritt 820 tatsächlich vorgenommen werden. Anschließend wird in Schritt 822 die Sperre des Elternknotens aufgehoben, und es wird ein Dummy-Kompensationsprotokollsatz (CLR) geschrieben, der auf die betreffende gespeicherte Protokollnummer verweist.
Sowohl beim Knotenaufspaltungsalgorithmus als auch beim oben beschriebenen Knotenauflösungsalgorithmus ist dem Fachmann klar, daß das SMO-Bit nach Abschluß der Strukturänderungsoperation jederzeit auf geeignete Weise auf Null zurückgesetzt werden kann. Aus den vorigen Ausführungen wird deutlich, daß die Erfindung ein System für gleichzeitige Änderungen eines Indexbaums in einem Transaktionsverarbeitungssystem liefert, das einen hohen Grad gemeinsamer Nutzung ermöglicht, indem es das Einfügen und Löschen von Schlüsselsätzen im gesamten Baum mit Ausnahme der Bereiche, in denen eine Strukturänderungsoperation anhängig ist, erlaubt.
Außerdem wird nach Beendigung der Strukturänderungsoperation ein Dummy-Kompensationsprotokollsatz verwendet, um zu gewährleisten, daß die Strukturänderungsoperation auch dann nicht rückgängig gemacht wird, wenn das System ausfällt, bevor die fragliche Transaktion einen neuen Konsistenzpunkt erreicht hat. Auf diese Weise wird die physische Konsistenz des Indexbaums bewahrt, und der dadurch ermöglichte hohe Grad gemeinsamer Nutzung ermöglicht eine bessere Verwendung des Indexbaums durch mehrere gleichzeitig arbeitende Benutzer.
Entsprechend verzögert die Verwendung eines Kennzeichenbits innerhalb der Knoten, das besagt, daß vor kurzem eine Löschoperation ausgeführt wurde, eine Schlüsselsatzeinfügung, die andernfalls von einer Strukturänderungsoperation während des Rückgängigmachens einer Einfügungs- oder Löschoperation betroffen wäre. Sobald die Transaktion, in deren Verlauf der Satz gelöscht wurde, einen Konsistenzpunkt erreicht hat, wird das Löschbit wieder auf Null gesetzt, und verzögerte Schlüsselsatzeinfügungen können ablaufen.
Der Fachmann weiß, daß die hier beschriebenen Operationen allgemein als in einem Blattknoten ablaufend betrachtet werden, die Knotenaufspaltungs- und Knotenauflösungsoperationen jedoch häufig bewirken, daß sich entsprechende Operationen im Baum bis zum Root-Knoten fortpflanzen. Die hier beschriebenen Verfahren gelten selbstverständlich auch für solche Operationen auf höheren Ebenen.

Claims

1. Ein Datenverarbeitungssystem bestehend aus einem Datenbanksystem für gemeinsamen Zugriff 12, 14, in dem mehrere Benutzer 10 mittels einer Baumstruktur gleichzeitig auf die Datenbank zugreifen können, wobei der Zugriff erste Operationen umfaßt, bei denen die Baumstruktur unverändert bleibt, sowie zweite Operationen, bei denen die Baumstruktur geändert wird, und wobei das Datenverarbeitungssystem über Mittel zur Ausführung einer aus mehreren Operationen bestehenden Transaktion sowie Mittel zur Speicherung der sequentiellen Positionen von Operationen, anhand derer eine Transaktion im Fall eines Systemausfalls rückgangig gemacht werden kann, verfügt,

wobei das System dadurch gekennzeichnet ist, daß das Mittel zur Wiederherstellung über Mittel zur Speicherung einer Angabe der sequentiellen Position einer zweiten Operation aus einer Folge von Operationen, welche die Baumstruktur unmittelbar vor Beginn der Operation verändert haben, verfügt, ferner über Mittel zur Speicherung eines Kompensationsprotokollsatzes, der nach Beendigung der Operationsfolge auf diese Angabe verweist, sowie Mittel zum Rückgängigmachen der Operationen in der Transaktion durch einen Verweis auf die gespeicherte Angabe, falls das System vor Beendigung der Operationsfolge ausfällt, und zum Rückgängigmachen nur der nicht in der Folge enthaltenen Operationen bei einem Systemausfall, sofern die Folge durch einen Verweis auf den Protokollkompensationssatz abgeschlossen wurde.

2. Ein Datenverarbeitungssystem gemäß Anspruch 1, bei dem die Baumstruktur eine Indexbaumstruktur ist mit einem Root-Knoten und Schlüsselsatzverweisen auf Knoten einer nächstniedrigeren Ebene, der wiederum eine nächstniedrigere Knotenebene folgt, auf deren Knoten durch Schlüssel im nächsthöheren Knoten verwiesen wird, bis hin zu Endknoten mit Schlüsseln, die auf die Daten in der Datenbank verweisen, wobei in jeder Operation die Knoten mittels der Schlüsselsatzverweise auf einen vorhandenen Endknoten durchlaufen werden, und das Mittel zur Anforderung bedingter Zugriffsbeschränkungen bei Erreichen eines Schlüsselsatzes im Endknoten, Mittel zum Zugriff auf die im Verweis bezeichneten Daten in der Datenbank nach Gewährung der Zugriffsbeschränkung, Mittel zur Anforderung unbedingter Zugriffsbeschränkungen bei Nichtgewährung der bedingten Zugriffsbeschränkung sowie Mittel zum Durchlaufen der Knoten vom Root-Knoten zu einem neuen Endknoten im Fall einer wesentlichen Änderung des vorhandenen Endknotens enthält.

3. Ein Datenverarbeitungssystem gemäß Anspruch 2, das Mittel enthält, um den Endknoten nach Gewährung der unbedingten Zugriffsbeschränkung daraufhin zu prüfen, ob ein im Endknoten bezeichneter Schlüsselsatz der erste Schlüsselsatz in dem Knoten ist.

4. Ein Datenverarbeitungssystem gemäß Anspruch 3, das Mittel enthält, um den Endknoten daraufhin zu prüfen, ob ein darin enthaltener Schlüsselsatz kleiner ist als ein angeforderter Schlüssel satz.

5. Ein Verfahren zum Betrieb eines Datenverarbeitungssystems bestehend aus einem Datenbanksystem, das mittels einer Baumstruktur den gleichzeitigen Zugriff mehrerer Benutzer auf Daten in der Datenbank ermöglicht, wobei der Zugriff erste Operationen enthält, bei denen die Baumstruktur unverändert bleibt, sowie zweite Operationen, bei denen die Baumstruktur verändert wird, wobei das Verfahren folgende Schritte umfaßt:

Ausführen einer Transaktion bestehend aus mehreren solchen Operationen;

Speichern einer Angabe der sequentiellen Position einer zweiten Operation aus einer Folge von Operationen, welche die Baumstruktur verändern, unmittelbar vor Beginn der Operationsfolge;

Speichern eines Kompensationsprotokollsatzes, der nach Abschluß der Folge auf diese Angabe verweist;

Rückgängigmachen der Operationen einer Transaktion durch Verweis auf die gespeicherte Angabe, falls das System vor Beendigung der Folge ausfällt; sowie

Rückgängigmachen nur der nicht in der Folge enthaltenen Operationen bei einem Systemausfall, sofern die Folge abgeschlossen ist, anhand des Kompensationsprotokollsatzes.

6. Ein Verfahren gemäß Anspruch 5, bei dem die Baumstruktur eine Indexbaumstruktur ist mit einem Root-Knoten und Schlüsselsatzverweisen auf Knoten einer nächstniedrigeren Ebene, der wiederum eine nächstniedrigere Knotenebene folgt, auf deren Knoten jeweils durch Schlüssel im nächsthöheren Knoten verwiesen wird, bis hin zu Endknoten mit Schlüsseln, die auf die Daten in der Datenbank verweisen, wobei in jeder Operation die Knoten mittels der Schlüsselsatzverweise bis zu einem vorhandenen Endknoten durchlaufen werden, und das außerdem folgende Schritte enthält:

Anforderung bedingter Zugriffsbeschränkungen bei Erreichen eines Schlüsselsatzes im Endknoten;

Zugriff auf die im Verweis bezeichneten Daten in der Datenbank nach Gewährung der Zugriffsbeschränkung;

Anforderung einer unbedingten Zugriffsbeschränkung, falls die bedingte Zugriffsbeschränkung nicht gewährt wird;

Durchlaufen der Knoten vom Root-Knoten bis zu einem neuen Endknoten, wenn der bestehende Endknoten wesentlich verändert wurde.

7. Ein Verfahren gemäß Anspruch 6, bei dem der Endknoten nach Gewährung der unbedingten Zugriffsbeschränkung daraufhin geprüft wird, ob ein im Endknoten bezeichneter Schlüsselsatz der erste Schlüsselsatz des Knotens ist.

8. Ein Verfahren gemäß Anspruch 7, bei dem ferner geprüft wird, ob ein Schlüsselsatz im Endknoten kleiner ist als der angeforderte Schlüsselsatz.