DE60220676T2

DE60220676T2 - Konsistente lesevorgänge in einer verteilten datenbankumgebung

Info

Publication number: DE60220676T2
Application number: DE60220676T
Authority: DE
Inventors: Amit San Jose GANESH; Roger Woodside BAMFORD
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2001-06-01
Filing date: 2002-05-29
Publication date: 2008-03-06
Anticipated expiration: 2022-05-30
Also published as: HK1059491A1; JP4301937B2; AU2002303900B2; US20020194206A1; DE60220676D1; CN1524239A; WO2002099701A2; CA2447692A1; JP2005503606A; ATE364872T1; CN1270261C; US7334004B2; EP1402414B1; CA2447692C; EP1402414A2; WO2002099701A3

Description

GEBIET DER ERFINDUNG
Die Erfindung betrifft ein Zugreifen auf gespeicherte Daten in einer verteilten Datenbankumgebung, und insbesondere ein Verfahren und eine Vorrichtung zum Bestimmen, welche Version eines Datenelementes an eine Transaktion, die das Datenelement anfordert, zu liefern ist.
HINTERGRUND DER ERFINDUNG
Bei typischen Datenbanksystemen führen Benutzer ein Speichern, Aktualisieren, Abrufen und Auswählen von Information durch Absenden von Befehlen oder Anweisungen an eine Datenbankanwendung durch. Für eine korrekte Verarbeitung müssen die Anweisungen die Datenbanksprache, die durch die Datenbankanwendung unterstützt wird, einhalten (diese befolgen). Eine weit verbreitete Datenbanksprache ist als 'Strukturierte Abfragesprache' (Structured Query Language – SQL) bekannt.
Eine logische Arbeitseinheit, die aus einer oder mehreren Anweisungen einer Datenbanksprache besteht, wird als Transaktion bezeichnet. Beispiele für Anweisungen einer Datenbanksprache sind etwa "Einfügen", für ein Einfügen von Daten in eine Datenbank, und "Abfrage", für ein Auswählen von Daten in einer Datenbank.
Wenn mehrere Benutzer ein Datenbanksystem gemeinsam nutzen, ist es unpraktisch, lediglich ein gleichzeitiges Ausführen einer einzigen Transaktion zu gestatten. Wenn jedoch ein gleichzeitiges Ausführen vieler Transaktionen gestattet ist, tritt ein Konsistenzproblem auf. In transaktionsbasierten Datenbankverwaltungssysteme steht eine spezielle Anweisung zur Verfügung-"Festschreibung" (Commit), die ein Benutzer oder Programm sendet, um eine Abgrenzung von Anweisungen, aus denen eine Transaktion besteht, vorzunehmen. Bevor das "Festschreiben" einer Transaktion erfolgt, werden alle durch die Transaktion vorgenommenen Änderungen als vorübergehend betrachtet, und diese werden entfernt, wenn ein "Festschreiben" der Transaktion nicht ausgeführt wird. Zum Zeitpunkt, bei dem ein Festschreiben der Transaktion erfolgt, werden alle durch die Transaktion vorgenommenen Änderungen bleibend (permanent) gemacht, und können danach von anderen Transaktionen 'gesehen' werden.
Um voraussagbare und reproduzierbare Ergebnisse zu gewährleisten, wurden Verfahren entwickelt, die gleichzeitig ablaufende Transaktionen vor einer unkontrolliert erfolgenden wechselseitigen Beeinflussung schützen. Transaktionen werden so gestaltet, dass Änderungen in der Datenbank derart erfolgen, dass sich die Datenbank, in ihrer Gesamtheit, von einem konsistenten Zustand zu einem anderen konsistenten Zustand 'bewegt'.
Es ist nicht nur erforderlich, dass die Transaktionen die Datenbank bei Abschluss in einem konsistenten Zustand zurücklassen, sondern es ist auch erforderlich, dass Transaktionen die Datenbank in einem konsistenten Zustand 'sehen'. Diese Bedingung ist schwierig zu erfüllen, da viele gleichzeitig ablaufende Transaktionen vorhanden sein können, von denen jede eine temporäre Inkonsistenz verursachen kann, die lediglich innerhalb dieser einzelnen Transaktion sichtbar ist. Demzufolge dürfen Transaktionen nicht fähig sein, die von gleichzeitigen ablaufenden Transaktionen vorgenommenen Änderungen zu sehen, bis diese Transaktionen "festgeschrieben" werden.
Ein Lösungsansatz, um zu gewährleisten, dass eine Transaktion, zu der eine Abfrage gehört, Änderungen nicht sieht, die durch gleichzeitig ablaufende Transaktionen vorgenommen werden, besteht darin, zu verhindern, dass Transaktionen eine Datenelementversion, die aktualisiert wurde, lesen, bevor bei der Transaktion, die das Aktualisieren der Datenelementversion durchgeführt hat, ein "Festschreiben" erfolgt. Jedoch vermindert dieser Lösungsansatz die "Concurrency" (gleichzeitige Zugriffe) des Systems, da bewirkt wird, dass Transaktionen, die Datenelementversionen lesen möchten ('Leser') warten müssen, bis bei Transaktionen, die in Datenelementversionen geschrieben haben ('Schreiber'), ein Festschreiben erfolgt ist.
Ein weiterer Weg, um zu verhindern, dass ein Abfragevorgang die von gleichzeitig ablaufenden Transaktionen vorgenommenen Änderungen 'sieht', besteht darin, der Abfrage eine "Speicherauszugszeit" ("Snapshot-Time") zuzuweisen, und dann (1) zu veranlassen, dass die Abfrage alle Änderungen sehen kann, die von Transaktionen vorgenommen wurden, deren Festschreiben vor der Speicherauszugszeit erfolgt ist, und (2) zu verhindern, dass die Abfrage Änderungen sieht, die von jeglichen Transaktionen vorgenommen wurden, deren Festschreiben nach der Speicherauszugszeit erfolgt. Insbesondere ist es, wenn eine Abfrage Teil einer Transaktion ist, erforderlich, dass die Abfrage 'sieht': (1) alle Änderungen, deren Festschreiben in der Datenbank zu oder vor dem Speicherauszugszeitpunkt der Abfrage erfolgt ist, und (2) alle Änderungen, die von der Transaktion, zu der die Abfrage gehört, vorgenommen wurden (sogar wenn das Festschreiben der Transaktion noch nicht erfolgt ist).
Es ist möglich, dass sich in einem Datenbanksystem mehrere Versionen desselben Datenelementes im Cache-Speicher befinden. Diese Versionen beinhalten (1) die aktuelle Version des Datenelementes (nachfolgend als aktuelle Version bezeichnet), die alle Änderungen beinhaltet, welche an diesem Datenelement bis zum aktuellen Zeitpunkt vorgenommen wurden, und (2) Klone der aktuellen Version, bei denen es sich entweder um Kopien der aktuellen Version oder Kopien von anderen Klonen handelt, die zu verschiedenen Zeitpunkten erstellt wurden (nachfolgend als Klone bezeichnet). Der Satz, bestehend aus der aktuellen Version und den Klonen der aktuellen Version, wird nachfolgend als die "Datenelementversionen" des Datenelementes bezeichnet.
Wenn in einer Abfrage ein Abrufen eines Datenelementes bezeichnet ist, muss das Datenbanksystem bestimmen, welche der verschiedenen Versionen des Datenelementes der Abfrage geliefert werden können. Bezüglich einer gegebenen Abfrage fällt jede Version eines Datenelementes unter eine von zwei Kategorien: (1) Versionen, die alles enthalten, was von der Abfrage gesehen werden muss (und die Änderungen aufweisen, welche in der Zukunft von dem liegen (zeitlich danach), was die Abfrage benötigt. Diese 'zukünftigen' Änderungen können mittels "Rollback" rückgängig gemacht werden, jedoch ist es schwierig, ältere Versionen von Datenelementen zeitlich vorwärts zu 'bewegen'), und (2) Versionen, in denen Änderungen fehlen, welche die Abfrage 'sehen' muss.
Im Allgemeinen können Versionen von Datenelementen, die bezüglich einer speziellen Abfrage unter die erste Kategorie fallen, verwendet werden, um diese spezielle Abfrage zu beantworten, nachdem jegliche Änderungen, welche die Abfrage nicht sehen kann aus der Version der Datenelemente entfernt wurde. Der Prozess der Entfernung von Änderungen aus einer Version eines Datenelementes wird als "Rollback" bezeichnet. Versionen von Datenelementen, die bezüglich einer speziellen Abfrage in die zweite Kategorie fallen, können nicht verwendet werden, um die spezielle Abfrage zu beantworten.
Ein Lösungsansatz, um an eine Abfrage Daten zu liefern, könnte darin bestehen, immer mit der aktuellen Version eines Datenelementes zu beginnen. Per Definition verfügt die aktuelle Version des Datenelementes über alle Änderungen, die jemals am Datenelement vorgenommen wurden. Daher gehört es für alle Abfragen immer zu Kategorie 1. Eine Verwendung der aktuellen Version des Datenelementes erfordert häufig (1) einen Klon herzustellen, und (2) aus dem Klon mittels "Rollback" alle Änderungen rückgängig zu machen, die die Abfrage nicht sehen soll. Jedoch können, wenn der Speicherauszugszeitpunkt der Abfrage alt ist, dann zahlreiche Änderungen vorliegen, die aus dem Klon entfernt werden müssen, was zu einer Rollback-Operation führt, die große Mengen an Zeit und Ressourcen verbraucht. Außerdem funktioniert, wenn man stets ein Rollback der Änderungen ausgehend von der aktuellen Version durchführt, dies nur bei einem Einzelknotensystem gut, da bei einem Mehrknotensystem eine Abfrage eines Datenelementes in einer Situation 'hängenbleiben' könnte, bei dem der aktuellen Version des Datenelementes 'nachgejagt' wird, während die aktuelle Version in einem Cluster von Knoten zu Knoten bewegt wird.
Falls bei einem System Rollback-Operationen nicht immer unter Verwendung der aktuellen Version begonnen werden, dann muss das System in der Lage sein, zu bestimmen, unter welche Kategorie die Klone bezüglich der Abfragen fallen, die das System verarbeitet. Falls sie bezüglich einer gegebenen Abfrage in Kategorie Eins fallen, dann können sie verwendet werden, um der Abfrage Daten zu liefern. Um die Einteilung der Klone in Kategorien zu erleichtern, können "Informationen über entfernte Daten" mit jeder Datenelementversion gespeichert werden. Die Information betreffend entfernte Daten bezeichnet im Allgemeinen, welche der an einer Datenelementversion vorgenommenen Änderungen anschließend von dieser Version des Datenelementes entfernt wurden.
Beispielsweise sei angenommen, dass die aktuelle Version eines Datenelementes geklont wird, um Klon X zu erzeugen. Zu Anfang bezeichnet die Information betreffend entfernte Daten von Klon X, dass keine Daten entfernt wurden. Falls beim Klon X eine Rollback-Operation durchgeführt wurde, um die durch die Transaktion T1 vorgenommenen Änderungen zu entfernen, dann wird die Information betreffend entfernte Daten von Klon X überarbeitet, um anzugeben, dass die von T1 vorgenommenen Änderungen aus Klon X entfernt wurden. Wenn eine Abfrage die von T1 vorgenommenen Änderungen nicht sehen braucht, dann kann Klon X verwendet werden, um der Abfrage Daten zu liefern (zusätzliche Rollback-Vorgänge können erforderlich sein). Falls die Abfrage die von T1 vorgenommenen Änderungen sehen muss, dann kann Klon X nicht verwendet werden, um der Abfrage Daten zu liefern.
Leider liefert die Information betreffend entfernte Daten nicht immer eine genau Angabe aller Änderungen, die (1) am Datenelement vorgenommen wurden, und die (2) nicht im Klon vorhanden sind. Insbesondere gibt es, sogar wenn die Information betreffend entfernte Daten angibt, dass keine Daten aus einem Klon entfernt wurden, weiterhin die Möglichkeit, dass Änderungen, die die Abfrage sehen muss, im Klon fehlen. Insbesondere kann es erforderlich sein, dass eine Abfrage Änderungen sehen muss, die an der aktuellen Version nach der Erzeugung des Klons vorgenommen wurden. Daher reicht diese Information betreffend entfernte Daten nicht aus, um alle Daten zu bestimmen, die bei einer Datenelementversion fehlen können. Mit anderen Worten können bei einem Klon Änderungen fehlen, bei denen keine Entfernung aus dem Klon durchgeführt wurde.
Das Folgende ist ein Beispiel dafür, wie es passieren kann, dass bei einem Klon letztendlich Daten fehlen, die nicht von der Information betreffend entfernte Daten des Klons widergespiegelt werden. Eine Transaktion TXB nimmt Aktualisierungen an einer aktuellen Version vor. Die aktuelle Version wird geklont, was in einem Klon Y resultiert. TXB fährt damit fort, Aktualisierungen an der aktuellen Version vorzunehmen. In diesem Fall fehlen beim Klon nun die Aktualisierungen, die an der aktuellen Version nach deren Klonen vorgenommen wurden, jedoch ist in der Information betreffend entfernte Daten für Klon Y nicht angegeben, dass irgendwelche Änderungen fehlen.
Ein Lösungsansatz, um anzugeben, ob Änderungen, die nicht in der Information betreffend entfernte Daten widergespiegelt werden, bei einem Klon fehlen, besteht darin, alle bestehenden Klone als "alt" zu markieren, wenn die aktuelle Version des Datenelementes aktualisiert wird. Die Operation, Klone als "alt" zu markieren, wird nachfolgend als 'Ungültigmachen' bezeichnet. Jedoch ist es bei einem Mehrknotensystem (nachfolgend als Cluster bezeichnet), bei dem die Klone über viele Knoten verteilt sein können, unpraktisch, da dies für jede Aktualisierung eines jeden Datenelementes ein Rundsenden einer Ungültigkeits-Nachricht an alle diejenigen Knoten des Clusters zur Folge hätte, welche möglicherweise Klone des Datenelementes enthalten.
Basierend auf dem zuvor Erwähnten besteht ein Bedarf nach einem Mechanismus, um zu bestimmen, welche Datenelementversionen an eine Abfrage geliefert werden können, wobei sich Klone dabei des Datenelementes in mehreren Knoten eines Clusters befinden können.
US 6,192,377 B1 offenbart ein Verfahren und eine Vorrichtung zum Bestimmen, ob eine Transaktion eine Version eines Datenelementes verwendet kann. Übersichtsdaten zur Transaktion werden erzeugt, die sowohl eine Auffrischzeit des Datenpuffers als auch eine Festschreibungszeit des Datenpuffer angeben. Basierend auf den Übersichtsdaten zur Transaktion und einer von der Transaktion verwendeten Speicherauszugszeit wird bestimmt, ob diese Version des Datenelementes an die Transaktion geliefert werden soll.
INHALT DER ERFINDUNG
Die Erfindung ist durch die unabhängigen Ansprüche definiert. Die abhängigen Ansprüche definieren optionale Merkmale einiger Ausführungsformen der Erfindung.
Gemäß einem Aspekt der Erfindung werden Verfahren bereitgestellt, um zu bestimmen, welche Datenelementversionen verwendet werden können, um einer Abfrage zu genügen. Die hier beschriebenen Verfahren können in einer Cluster-Umgebung, ohne die beträchtlichen Leistungsnachteile alternativer Verfahren verwendet werden. Außerdem werden Verfahren bereitgestellt, um zu bestimmen, welche Versionen den geringsten Arbeitsaufwand erfordern, um den Erfordernissen einer Abfrage zu genügen.
Gemäß einer Ausführungsform beinhaltet das Verfahren:

1) Zuordnen eines ersten neuen Feldes zu jedem Klon, wobei das erste neue Feld den Zeitpunkt angibt, zu dem eine Datenelementversion aktuell war,
2) Zuordnen eines zweiten neuen Feldes zu jeder Abfrage, wobei das zweite neue Feld die letzte Änderung angibt, die von einer Transaktion vorgenommen wurde, die die Abfrage sehen muss, und
3) Verwenden des Wertes des ersten neuen Feldes eines Klons, und des Wertes des zweiten neuen Feldes der Abfrage, um zu bestimmen, ob der Klon der Abfrage geliefert werden kann.

KURZE BESCHREIBUNG DER ZEICHNUNGEN
Ausführungsformen der Erfindung sind beispielhaft und nicht einschränkend in den Figuren der anliegenden Zeichnungen dargestellt, in denen gleiche Bezugszeichen ähnliche Elemente bezeichnen; in diesen sind:
1 ein Blockdiagramm von einer Datenelementversion und Transaktionen, mittels denen diese aktualisiert wurde;
2 ein Blockdiagramm eines Klon-Zweigs;
3 ein Blockdiagramm eines Vektors;
4 ein Blockdiagramm eines Datenbanksystems gemäß einer Ausführungsform der Erfindung; und
5 ein Blockdiagramm eines Computersystems, das zur Implementierung einer Ausführungsform der Erfindung verwendet werden kann.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
Es werden ein Verfahren und ein System beschrieben, um Datenelementversionen von einer Datenbank zum Beantworten einer Abfrage zu liefern. In der folgenden Beschreibung sind zu Erläuterungszwecken zahlreiche spezielle Details dargelegt, um für ein grundlegendes Verständnis der Erfindung zu sorgen. Für einen Fachmann ist es jedoch offensichtlich, dass die Erfindung ohne diese speziellen Details ausgeführt sein kann. In anderen Fällen sind allgemein bekannte Strukturen und Vorrichtungen in Blockdiagrammform dargestellt, um zu vermeiden, dass die Erfindung unnötig kompliziert dargestellt wird.
FUNKTIONSÜBERBLICK
Es werden Verfahren bereitgestellt, um eine Version eines Datenelementes zu aufzufinden, das sich in einem von einer Vielzahl von Knoten eines Clusters befindet, und zwar für eine Abfrage, die einen konsistenten Speicherauszug (Snapshot) der Datenbank sehen muss. Wie zuvor erwähnt, dürfen derartige Abfragen lediglich (1) Änderungen sehen, bei denen ein Festschreiben in der Datenbank durch einen speziellen Satz von festgeschriebenen (= vollständig abgeschlossenen) Transaktionen erfolgt ist, und (2) Änderungen sehen, die durch vorhergehende Anweisungen der Transaktion, zu der die Abfrage gehört, erfolgt sind.
Gemäß einer Ausführungsform beinhalten diese Verfahren das Speichern einer KLON-ZEIT bei jedem Klon, und eines LETZTE-SICHT-ZEITSTEMPELs bei jeder Abfrage. Die folgenden Absätze beschreiben, wie diese zusätzlichen Informationselemente ermittelt, unterhalten und verwendet werden, um zu bestimmen, ob einer speziellen Abfrage ein spezieller Klon geliefert werden kann.
GLOBALE SYSTEMZEIT
Die globale Systemzeit ist eine Zähleinrichtung, die durch das Datenbanksystem unterhalten wird. Typischerweise wird diese Zähleinrichtung mit dem Fortschreiten der Zeit hochgezählt. Um die Abfolge von Datenbankereignisse zu verfolgen, erfolgt ein Markieren der Ereignisse, dass sie im Datenbanksystem zu dem durch die globale Systemzeit angegebenen Zeitpunkt erfolgt sind. Beispielsweise wird angenommen, dass ein Ereignis, das bei einer globalen Systemzeit von 10 stattgefunden hat, vor irgendetwas anderem stattgefunden hat, das bei einer globalen Systemzeit von 11 stattgefunden hat. Wie später noch detaillierter beschrieben wird, wird die globale Systemzeit verwendet, um Zeitstempel zu erzeugen, die sowohl für die KLON-ZEIT von Klonen als auch LETZE-SICHT-ZEITSTEMPEL von Abfragen verwendet werden.
KLON-ZEIT
Wie zuvor erwähnt, wird Information betreffend entfernte Daten bei jedem Klon gespeichert, um anzugeben, ob irgendwelche Änderungen, sofern vorhanden, vom Klon entfernt wurden. Jedoch gibt die Information betreffend entfernte Daten nicht an, ob bei einem Klon Änderungen fehlen, die an der aktuellen Version vorgenommen wurden, nachdem der Klon erzeugt wurde. Um ein Verfolgen dieser letzteren Art von fehlenden Änderungen zu erleichtern, wird eine "KLON-ZEIT" bei jedem Klon gespeichert.
Im Allgemeinen ist die KLON-ZEIT eines Klons ein Wert, welcher den Zeitpunkt angibt, zu dem das Klonen des "Klon-Zweigs", zu dem der Klon gehört, ausgehend von der aktuellen Version des Datenelementes erfolgt ist. Der Klon-Zweig, zu dem ein spezieller Klon gehört, beinhaltet (1) alle Klone, die bei den Klonoperationen beteiligt waren, die diesen speziellen Klon hervorgebracht haben, und (2) alle Klone, für deren Herstellung dieser spezielle Klon verwendet wird.
Im folgenden Szenario werden Klone, Klon-Zweige und KLON-ZEITEN detaillierter erläutert. Jede nicht-aktuelle Version eines Datenelementes wurde entweder ausgehend von einer aktuellen Version oder ausgehend von einer anderen nicht-aktuellen Version des Datenelementes geklont. Somit ist jede nicht-aktuelle Version eines Datenelementes das Produkt einer Abfolge von einer oder mehreren Klonoperationen. Beispielsweise ist in 2 eine aktuelle Version 200 dargestellt. Zum Zeitpunkt T = 10 wird ein erster Klon 201 der aktuellen Version 200 aus der aktuellen Version erzeugt. Dem Zeitpunkt, bei dem das Klonen von Klons 201 ausgehend von der aktuellen Version 200 erfolgt, wird von der globalen Systemzeit eine KLON-ZEIT zugewiesen.
Der Klon 202 ist ein Klon von Klon 201. Der Klon 202 wird aus Klon 201 bei T = 12 geklont. Obschon Klon 201 bei T = 12 erzeugt wird, gehört er zu einem Klon-Zweig, der ausgehend von der aktuellen Version 200 bei T = 10 geklont wurde. Demzufolge wird dem Klon 202 die KLON-ZEIT von T = 10 zugewiesen.
Dem Klon 203, der ein Klon von Klon 202 ist, der bei T = 15 erzeugt wurde, wird ebenfalls die KLON-ZEIT von T = 10 zugewiesen. Klon 204, der ein Klon von Klon 203 ist, der bei T = 17 erzeugt wurde, wird ebenfalls die KLON-ZEIT von T = 10 zugewiesen. Somit gehören alle Klone (201, 202, 203 und 204) zum gleichen Klon-Zweig und weisen alle die gleiche KLON-ZEIT T = 10 auf, die anfänglich dem Klon 201 zugewiesen wurde.
Somit ist die KLON-ZEIT, die einem Klon zugewiesen wird, der direkt aus der aktuellen Version erzeugt wird, die globale Systemzeit, zu der der Klon erzeugt wird. Die KLON-ZEIT, die einem Klon zugewiesen wird, der aus einem anderen Klon erzeugt wird, ist die KLON-ZEIT des anderen Klons, aus dem dieser erzeugt wurde.
Unter Verwendung der Information betreffend entfernte Daten in Verbindung mit der KLON-ZEIT ist es möglich, zu 'wissen', dass alle Änderungen, die an einem Datenelement vor der KLON-ZEIT vorgenommen wurden, entweder (1) in der Datenelementversion widergespiegelt werden, oder (2) durch die Information betreffend entfernte Daten als entfernt identifiziert sind.
LETZTE-SICHT-ZEITSTEMPEL
Gemäß einer Ausführungsform wird, zusätzlich dazu, dass jedem Klon eine Klonzeit zugewiesen wird, ein LETZTE-SICHT-ZEITSTEMPEL jeder Abfrage zugewiesen, die eine konsistente Ansicht der Datenbank sehen muss. Gemäß einer Ausführungsform ist der LETZTE-SICHT-ZEITSTEMPEL, der einer Abfrage, die Teil einer Transaktion ist, zugewiesen wird, der Wert der globalen Systemzeit, bei der Transaktion die am kürzesten zurückliegende Änderung, die die Abfrage sehen muss, vorgenommen hat.
Beispielsweise sei angenommen, dass eine Abfrage Q1 ein Teil einer Transaktion TX1 ist, die fünf Änderungen an der Datenbank vorgenommen hat, und zwar zu Zeiten T = 1, T = 2, T = 3, T = 4 bzw. T = 5. Es sei angenommen, dass Q1 die ersten drei Änderungen von TX1 sehen muss. Unter diesen Umständen ist der LETZTE-SICHT-ZEITSTEMPEL, der Q1 zugewiesen wird, T = 3, welches die globale Systemzeit ist, bei der TX1 ihre dritte Änderung vorgenommen hat.
VERGLEICH VON KLON-ZEIT UND LETZTE-SICHT-ZEITSTEMPEL
Typischerweise bezeichnet eine Information betreffend entfernte Daten eines Klons die "Festschreibungs"-Zeit der zeitlich am kürzesten zurückliegenden Transaktion, deren Änderungen im Klon widergespiegelt werden. Zu Erläuterungszwecken wird dieser Wert hier als JÜNGSTE-AUFNAHMEZEIT bezeichnet.
Somit gibt, wenn ein Klon Daten von Transaktionen beinhaltet, die zu Zeitpunkten 10, 12 und 15 "festgeschrieben" wurden, dann die JÜNGSTE-AUFNAHMEZEIT des Klons einen Festschreib-Zeitpunkt von 14, welches die Festschreib-Zeit der Transaktion (z. B. 15) minus Eins ist. Falls die von der Transaktion vorgenommenen Änderungen, die zum Zeitpunkt 15 festgeschrieben wurden, aus dem Klon entfernt werden, dann wird die JÜNGSTE-AUFNAHMEZEIT auf 12 verändert.
In der Vergangenheit konnte ein Klon nicht verwendet werden, um einer Abfrage zu genügen, wenn die JÜNGSTE-AUFNAHMEZEIT des Klons zeitlich vor der Speicherauszugszeit einer Abfrage lag, sogar wenn die Information betreffend entfernte Daten des Klons angab, dass keine Änderungen aus dem Klon entfernt wurden. Beispielsweise konnte einer Abfrage mit einer Speicherauszugszeit von 20 nicht unter Verwendung eines Klons genügt werden, dessen JÜNGSTE-AUFNAHMEZEIT 14 betrugt, sogar wenn die Information betreffend entfernte Daten des Klons angab, dass keine Änderungen aus dem Klon entfernt wurden. Der Klon konnte nicht verwendet werden, da es möglich war, dass Änderungen an der aktuellen Version (1) nach der Erzeugung des Klons und (2) vor der Speicherauszugszeit der Abfrage vorgenommen wurden. Außerdem erfolgte in der Vergangenheit ein Ungültigmachen von Datenelementversionen lokal, und entfernt liegende Datenelementversionen konnten nicht verwendet werden, da ein globales Ungültigmachen teuer ist.
Dadurch, dass bei der Abfrage ein LETZTE-SICHT-ZEITSTEMPEL und bei einem Klon eine KLON-ZEIT unterhalten wird, ist es möglich, Datenelementversionen clusterübergreifend zu verwenden, ohne ein Ungültigmachen durchzuführen. Insbesondere kann, wenn die KLON-ZEIT eines Klons größer oder gleich groß wie der LETZTE-SICHT-ZEITSTEMPEL einer Abfrage ist und die Speicherauszugszeit kleiner als die JÜNGSTE-AUFNAHMEZEIT ist, die Datenelementversion verwendet werden.
Gemäß einer Ausführungsform ist der LETZTE-SICHT-ZEITSTEMPEL auf den Wert der globalen Systemzeit eingestellt, um den Zeitpunkt anzugeben, zu dem die Transaktion die Änderung vorgenommen hat, der ein "LAUFNUMMER-VON-LETZTER-ÄNDERUNG"-Wert zugeordnet ist. Der LAUFNUMMER-VON-LETZTER-ÄNDERUNG-Wert ist die Laufnummer der höchsten Änderung, die die Abfrage sehen muss und die von der Transaktion, zu der die Abfrage gehört, vorgenommen wurde.
FÜR EINE DATENELEMENTVERSION UNTERHALTENE DATEN
Wie zuvor angegeben, gibt es zwei mögliche Ursachen dafür, dass in einer Datenelementversion Änderungen fehlen, die eine Abfrage sehen muss: 1) Änderungen, die mittels Roll back aus der Datenelementversion entfernt wurden, und 2) Änderungen, die an der aktuellen Version des Datenelementes vorgenommen wurden, nachdem die Datenelementversion aus der aktuellen Version des Datenelementes geklont wurde. Die Änderungen, die mittels Rollback aus einer Datenelementversion entfernt wurden, werden als "entfernte Daten" bezeichnet, und die Information, die benötigt wird, um diese Daten zu verfolgen, wird als "Information betreffend entfernte Daten" bezeichnet.
Information betreffend entfernte Daten ist jeder Datenelementversion zugeordnet. Diese Information betreffend entfernte Daten beinhaltet Folgendes:

1) JÜNGSTE-AUFNAHMEZEIT: die Festschreib-Zeit der zeitlich am kürzesten zurückliegenden Transaktion, deren Änderungen nicht aus der Datenelementversion entfernt wurden. Für die aktuelle Version eines Datenelementes ist die JÜNGSTE-AUFNAHMEZEIT immer unendlich klein. Wenn Änderungen aus einer Datenelementversion mittels Rollback entfernt werden, wird die JÜNGSTE-AUFNAHMEZEIT einer Datenelementversion aktualisiert, so dass sie die Festschreib-Zeit der am kürzesten zurückliegenden Transaktion widerspiegelt, um die Datenelementversion zu modifizieren, deren Änderungen nicht durch Rollback aus der Datenelementversion entfernt wurden. Falls beispielsweise durch Transaktionen TXA, TXB und TXC ein Festschreiben von Änderungen an einer speziellen Datenelementversion zu Zeitpunkten 5, 10 bzw. 15 erfolgt ist, dann werden von TXC vorgenommene Änderungen mittels Rollback entfernt, und die JÜNGSTE-AUFNAHMEZEIT wird auf 10 gesetzt. Wenn die Änderungen von TXB durch Rollback entfernt wurden, dann wird die JÜNGSTE-AUFNAHMEZEIT auf 5 gesetzt.
2) LETZTE-FEHLENDE-TRANSAKTION: die Kennung der letzten Transaktion, deren Änderung(en) in der Datenelementversion fehlt/fehlen. Mit anderen Worten ist die LETZTE-FEHLENDE-TRANSAKTION die Transaktionskennung der Transaktion, bei der als letzte durch Rollback Änderungen aus der Datenelementversion entfernt wurden.
3) LAUFNUMMER-VON-JÜNGSTER-FEHLENDER-ÄNDERUNG: die Laufnummer der jüngsten fehlenden Änderung, die durch die LETZTE-FEHLENDE-TRANSAKTION vorgenommen wurde. Beispielsweise sei angenommen, dass durch die LETZTE-FEHLENDE-TRANSAKTION vier Änderungen an einem speziellen Datenelement vorgenommen wurden, wobei den vier Änderungen die Laufnummern 11, 25, 32 und 50 zugeordnet wurden. Falls keine der Änderungen durch Rollback aus der Datenelementversion entfernt wurde, dann wird die LAUFNUMMER-VON-JÜNGSTER-FEHLENDER-ÄNDERUNG eliminiert. Falls alle Änderungen entfernt wurden, dann wird die LAUFNUMMER-VON-JÜNGSTER-FEHLENDER-ÄNDERUNG auf 11 gesetzt.
4) ROLLBACK-INDIKATOR-WEITERER-TRANSAKTIONEN: ein Bit, das gesetzt wird, falls Änderungen, die durch Transaktionen außer der LETZTE-FEHLENDE-TRANSAKTION vorgenommen wurden, aus dieser Datenelementversion durch Rollback entfernt wurden.

1 ist ein Blockdiagramm, das eine Datenelementversion 100, Transaktionen, welche die Datenelementversion 100 aktualisiert haben, und Information betreffend entfernte Daten darstellt, die für die Datenelementversion 100 unterhalten werden, gemäß einer Ausführungsform der Erfindung. Die Datenelementversion 100 enthält Daten 106 und weist zu dieser gehörige Information betreffend entfernte Daten auf. Die Information betreffend entfernte Daten besteht aus: JÜNGSTE-AUFNAHMEZEIT 102, LETZTE-FEHLENDE-TRANSAKTION 103, LAUFNUMMER-VON-JÜNGSTER-FEHLENDER-ÄNDERUNG 104 und ROLLBACK-INDIKATOR-WEITERER-TRANSAKTIONEN 105.
Um zu verdeutlichen, wie die verschiedenen Änderungen der Information betreffend entfernte Daten unterhalten werden, sei angenommen, dass drei Transaktionen Aktualisierungen an der Datenelementversion 100 vorgenommen haben. Diese Transaktionen sind TXA 110, TXB 111 und TXC 112. Bei TXA 110 erfolgte das Festschreiben bei einer globalen Systemzeit von 10. Bei TXB 111 erfolgte das Festschreiben bei einer globalen Systemzeit von 12. Bei TXC 112 erfolgte das Festschreiben bei einer globalen Systemzeit von 14.
Es sei angenommen, dass die Datenelementversion 100 die aktuelle Datenversion ist, in welchem Fall die JÜNGSTE-AUFNAHMEZEIT unendlich ist, die LETZTE-FEHLENDE-TRANSAKTION eliminiert wird und der ROLLBACK-INDIKATOR-WEITERER-TRANSAKTIONEN nicht gesetzt wird. Die LAUFNUMMER-VON-JÜNGSTER-FEHLENDER-ÄNDERUNG wird eliminiert.
Es sei angenommen, dass Rollback-Vorgänge bei der Datenelementversion 100 vorgenommen werden, um alle durch TXC vorgenommenen Änderungen durch Rollback zu entfernen. Ebenso sei angenommen, dass TXC Änderungen mit den Laufnummern 11, 25, 32 und 50 vorgenommen hat. Jetzt weist die Datenelementversion 100 eine JÜNGSTE-AUFNAHMEZEIT von 13 auf, die Festschreib-Zeit von TXC minus Eins, eine LETZTE-FEHLENDE-TRANSAKTION von TXB, und eine LAUFNUMMER-VON-JÜNGSTER-FEHLENDER-ÄNDERUNG von 11 auf, und der ROLLBACK-INDIKATOR-WEITERER-TRANSAKTIONEN ist gesetzt, da von TXC vorgenommene Änderungen durch Rollback aus der Datenelementversion entfernt wurden.
Falls einige, jedoch nicht alle von TXB 111 vorgenommenen Änderungen dann durch Rollback aus der Datenelementversion entfernt werden, würde ein Verfahren darin bestehen, die LETZTE-FEHLENDE-TRANSAKTION auf die Transaktion zu setzen, die aktuell gerade die Datenversion 100 liest und den ROLLBACK-INDIKATOR-WEITERER-TRANSAKTIONEN auf JA zu setzen. Die LAUFNUMMER-VON-JÜNGSTER-FEHLENDER-ÄNDERUNG würde auf die LAUFNUMMER-VON-LETZTER-ÄNDERUNG des 'Lesers' plus Eins gesetzt. Falls beim Abfragekontext des 'Lesers' die Transaktions-ID nicht aktiv war (d. h. zum Zeitpunkt des Speicherauszugs von der Transaktion keine Änderungen erfolgt waren), dann würde die LAUFNUMMER-VON-JÜNGSTER-FEHLENDER-ÄNDERUNG nicht auf die LAUFNUMMER-VON-LETZTER-ÄNDERUNG des 'Lesers' plus Eins gesetzt, da es nicht erforderlich wäre, dies vorzunehmen.
Wie zuvor dargelegt, werden die oben beschriebenen Felder verwendet, um Information für die entfernten Daten zu unterhalten, und somit werden diese kollektiv als Information betreffend entfernte Daten bezeichnet. Jedoch reicht die Information betreffend entfernte Daten nicht aus, um zu bestimmen, ob Änderungen an der aktuellen Version des Datenelementes im Anschluss an ein Klonen einer Datenelementversion vorgenommen wurden.
FÜR EINE ABFRAGE UNTERHALTENE DATEN
Jede Abfrage weist einen Kontext auf, der deren Ausführungsumgebung beschreibt. Gemäß einer Ausführungsform beinhaltet die jeder Abfrage zugehörige Kontextinformation das Folgende:

1) SPEICHERAUSZUG-BEZEICHNENDE-ZEIT-DEN-ABFRAGE-SEHEN-MUSS: gibt den Zeitpunkt an, der dem Speicherauszug der Datenbank zugehörig ist, der von der Abfrage gesehen werden muss. Falls beispielsweise die SPEICHERAUSZUG-BEZEICHNENDE-ZEIT-DEN-ABFRAGE-SEHEN-MUSS der Abfrage 10 ist, dann muss die Abfrage alle Änderungen sehen, deren Festschreiben in der Datenbank bei oder vor T = 10 erfolgt ist, und sie kann keine Änderungen sehen, deren Festschreiben in der Datenbank nach T = 10 erfolgt sind. Die SPEICHERAUSZUG-BEZEICHNENDE-ZEIT-DEN-ABFRAGE-SEHEN-MUSS ist für gewöhnlich auf den Zeitpunkt gesetzt, zu dem eine Abfrage begonnen wird, und ist für gewöhnlich auf den aktuellen Wert der globalen Systemzeit gesetzt.
2) TRANSAKTION-ZU-DER-ABFRAGE-GEHÖRT: Falls die Abfrage Teil einer Transaktion ist, ist die Transaktion durch TRANSAKTION-ZU-DER-ABFRAGE-GEHÖRT identifiziert. Falls die Abfrage nicht Teil einer Transaktion ist, dann wird die TRANSAKTION-ZU-DER-ABFRAGE-GEHÖRT nicht verwendet.
3) LAUFNUMMER-VON-LETZTER-ÄNDERUNG: Die Laufnummer der höchsten Änderung, welche die Abfrage sehen muss, die von der Transaktion, zu der die Abfrage gehört, vorgenommen wurde.

BERECHNUNGEN
Die KLON-ZEIT und der LETZTE-SICHT-ZEITSTEMPEL können in einem System verwendet werden, das die Information betreffend entfernte Daten und die Abfrage-Kontextinformation unterhält, die zuvor beschrieben wurden, um in effizienter Weise eine einer Abfrage zu liefernde Datenelementversion zu identifizieren.
Wie später noch detaillierter beschrieben wird, kann diese Information nicht nur verwendet werden, um zu identifizieren, welche Datenelementversionen verwendet werden können, sondern auch, um zu identifizieren, welche Datenelementversionen die geringste Anzahl an Rollback-Vorgängen erfordern. In diese Berechnungen ist die Information betreffend entfernte Daten, die den Datenelementversionen zugeordnet ist, und die Kontextinformation, die den Abfragen zugehörig ist, involviert. Diese Berechnungen sind wie folgt:

1. Speicherauszugszeit <= JÜNGSTE-AUFNAHMEZEIT &&
2. LETZTE-SICHT-ZEITSTEMPEL <= KLON-ZEIT &&
3. (TRANSAKTION-ZU-DER-ABFRAGE-GEHÖRT gibt keine Transaktion für Abfrage an || keine LETZE-FEHLENDE-TRANSAKTION für Klon || TRANSAKTION-ZU-DER-ABFRAGE-GEHÖRT <> LETZE-FEHLENDE-TRANSAKTION) dann Datenelementversion kann verwendet werden.

Für die zuvor beschriebenen logischen Operationen wurden die folgenden nachstehend angegebenen Symbole verwendet:

1) "=" bedeutet "gleich groß wie"
2) "<" bedeutet "kleiner als"
3) ">" bedeutet "größer als"
4) "<>" bedeutet "nicht gleich groß wie"
5) ">=" wird verwendet für "größer oder gleich"
6) "<=" bedeutet "kleiner oder gleich"
7) && bedeutet "UND-Logikoperation"
8) || bedeutet "ODER-Logikoperation"

DER VEKTOR
Gemäß einer Ausführungsform wird ein Informationsvektor bereitgestellt, um dem "Verteilten Sperrungsmanager" (Distributed Lock Manager, nachfolgend als DLM bezeichnet) zu ermöglichen, zu bestimmen, welcher Knoten der beste Kandidat ist, um über eine Datenelementversion zu verfügen, die den Anforderungen einer Abfrage bei minimalem Arbeitsaufwand genügt. Der Vektor ist einem speziellen Datenelement zugeordnet und enthält Information betreffend die Datenelementversionen dieses speziellen Datenelementes. Insbesondere enthält der Vektor eine Liste von Knotenkennungen für alle im Cluster vorhandene Knoten und führt ein Zuordnen von KLON-ZEITEN zu diesen Knotenkennungen für alle Datenelementversionen für dieses spezielle Datenelement in jedem Knoten durch.
Beispielsweise weist, Bezug nehmend auf 3, ein Vektor 300 für ein spezielles Datenelement drei Knoten auf: Knoten 1 310, Knoten 2 320, Knoten 3 330. Knoten 1 310 enthält drei Versionen des speziellen Datenelementes in seinem Cache. Diese Datenelementversionen weisen jeweils eine ihnen zugeordnete KLON-ZEIT auf. Die KLON-ZEITEN werden im Vektor 300 widergespiegelt und sind Knoten 1 310 zugeordnet. Insbesondere enthält die Klon-Zeit-von-Knoten/Vektor-Zuordnung 311 die KLON-ZEIT von 1, die Klon-Zeit-von-Knoten/Vektor-Zuordnung 312 enthält die KLON-ZEIT von 3, die Klon-Zeit-von-Knoten/Vektor-Zuordnung 313 enthält die KLON-ZEIT von 4.
Knoten 2 320 enthält eine einzige Datenelementversion in seinem Cache. Die Datenelementversion weist eine KLON-ZEIT von 15 auf, die im Vektor 300 widergespiegelt wird und dem Knoten 2 320 zugeordnet ist. Die Klon-Zeit-von-Knoten/Vektor-Zuordnung 314 enthält die KLON-ZEIT von 15.
Knoten 3 330 enthält zwei Datenelementversionen in seinem Cache. Diese Datenelementversionen weisen jeweils eine ihnen zugeordnete KLON-ZEIT auf, die im Vektor 300 widergespiegelt werden und Knoten 2 330 zugeordnet sind. Die Klon-Zeit-von-Knoten/Vektor-Zuordnung 315 enthält die KLON-ZEIT von 16, und die Klon-Zeit-von-Knoten/Vektor-Zuordnung 316 enthält die KLON-ZEIT von 20.
VERWENDUNG DES VEKTORS ZUM AUFFINDEN DES BESTEN KANDIDATEN
Datenelementversionen, die alles beinhalten, was eine Abfrage sehen muss, sind Kandidaten für eine Lieferung an die Abfrage. Obschon dies mit beliebigen Kandidaten funktioniert, wird im Allgemeinen bevorzugt, den besten Kandidaten auszuwählen. Im Allgemeinen ist ein erster Kandidat besser als ein zweiter Kandidat, falls zum Liefern des ersten Kandidaten an die Abfrage ein geringerer Overhead benötigt wird, als erforderlich ist, um den zweiten Kandidaten zu liefern. Eine Komponente des Overhead beinhaltet, dass mittels Rollback Änderungen entfernt werden, die die Abfrage nicht sehen kann. Im Allgemeinen ist, je geringer die Anzahl von Änderungen, die mittels Rollback entfernt werden müssen, desto besser der Kandidat. 4 stellt ein Datenbanksystem 400 dar, das drei Knoten aufweist (Knoten 1 310, Knoten 2 320, Knoten 3 330) und einen DLM (Distributed Lock Manager) 440 aufweist. Jeder Knoten weist einen "Lokalen Sperrungsmanager" (Local Lock Manager, nachfolgend als LLM bezeichnet), welcher dem DLM 440 zugehörig ist, und einen Cache auf.
Knoten 1 310 weist einen Cache 411 und einen LLM 441 auf. Knoten 2 320 weist einen Cache 421 und einen LLM 442 auf. Knoten 3 330 weist einen Cache 431 und einen LLM 443 auf. Die LLMs 441, 442 und 443 sind nicht nur den drei Knoten (310, 320, 330) zugeordnet, sondern auch dem DLM 440.
Für die Zwecke dieses Szenarios sei angenommen, dass der Vektor 300 in 3 durch den DLM 440 verwendet wird. Zweitens sei angenommen, dass eine Abfrage 450 beim Knoten 2 320 ausgeführt wird. Die Abfrage 450, beim Knoten 2 320, weist die folgenden Kontext-Werte auf:

LETZTE-SICHT-ZEITSTEMPEL 9

ZEIT-DIE-SPEICHERAUSZUG-BEZEICHNETDEN-ABFRAGE-SEHEN-MUSS 8

TRANSAKTION-ZU-DER-ABFRAGE-GEHÖRT TXB

LAUFNUMMER-VON-LETZTER-ÄNDERUNG 71
Beim Knoten 1 310 wird eine Datenelementversion 460 im Cache 411 geklont, nachdem Abfrage 450 beginnt, die Datenelementversion 460 zu erzeugen. Es sei angenommen, dass die folgenden Werte der Datenelementversion 460 zugehörig sind:

KLON-ZEIT 12

JÜNGSTE-AUFNAHMEZEIT 9

LETZTE-FEHLENDE-TRANSAKTION TXD

LAUFNUMMER-VON-JÜNGSTER-FEHLENDER-ÄNDERUNG 73

ROLLBACK-INDIKATOR-WEITERER-TRANSAKTIONEN nicht gesetzt
Es sei ebenfalls angenommen, dass keine Rollback-Vorgänge durchgeführt wurden, so dass die Datenelementversionen LETZTE-AUFNAHMEZEITen aufweisen, die gleich groß sind wie die KLON-ZEITen in den in 3 dargestellten Klon-Zeit-für-Knoten/Vektor-Zuordnungen.
Unter den zuvor beschriebenen Annahmen führt die Abfrage 450 ein Anfordern des Datenelementes vom DLM 440 durch. Der DLM 330 überprüft den Vektor und findet heraus, dass Knoten 1 310 eine JÜNGSTE-AUFNAHMEZEIT von 11 für eine dem Knoten 1 zugeordnete Datenelementversion aufweist (siehe 3, die KLON-ZEIT in der Klon-Zeit-für-Knoten/Vektor-Zuordnung 313 beträgt 11). Da die JÜNGSTE-AUFNAHMEZEIT sich am nächsten von allen JÜNSTEN-AUFNAHMEZEITen zum LETZTE-SICHT-ZEITSTEMPEL der Abfrage befindet, leitet der DLM 440 die Anforderung der Abfrage an Knoten 1 310 weiter. Die Verarbeitung beim Knoten 1 310 fahrt damit fort, den Cache 411 zu scannen, um eine Datenelementversion zu finden, die den Anforderungen der Abfrage am besten genügt. Der Prozess nimmt nicht an, dass die Datenelementversion mit der JÜNGSTEN-AUFNAHMEZEIT 11 (siehe 3, die Klon-Zeit-für-Knoten/Vektor-Zuordnung 313) die beste Wahl ist, da zu dem Zeitpunkt, zu dem die Anforderung für Abfrage 450 beim Knoten 1 310 ankommt, möglicherweise eine bessere Datenelementversion verfügbar ist. Beim dargestellten Szenario ist genau dies der Fall. Insbesondere beinhaltet Knoten 1 310 eine Datenelementversion mit einer KLON-ZEIT von 10, die näher an dem LETZTE-SICHT-ZEITSTEMPEL der Abfrage ist, die 9 beträgt. Die Durchführung der Berechnungen erfolgt, wie im Absatz BERECHNUNGEN kurz angerissen wird, indem die Werte der Abfrage mit den Werten der Datenelementversion verglichen werden. Basierend auf diesen Berechnungen wird bestimmt, dass bei der Datenelementversion 460 ein Erfüllen der Anforderungen von Abfrage 450 gegeben ist, sobald Rollback-Vorgänge durchgeführt wurden. Änderungen, bei denen die LAUFNUMMER-VON-LETZTER-ÄNDERUNG größer als 71 ist, würden mittels Rollback entfernt, und die Anzahl der Rollback-Vorgänge würde von der Laufnummer der Änderungen abhängen. Da die Datenelementversion 460 verwendet werden kann, um den Erfordernissen von Abfrage 450 zu genügen, wird die Datenelementversion 460 zum Knoten 2 320 transportiert.
WEITERE ANWENDUNGEN
Für die Erfindung bestehen, abgesehen von den hier angeführten Beispielen, viele Anwendungen. Beispielsweise können die hier beschriebenen Verfahren in einem beliebigen Kontext verwendet werden, bei dem Daten für eine Sitzung (Session) in einem System unterhalten werden. Diese Verfahren können auch in einem beliebigen Mehrknotensystem verwendet werden, das einen verteilten Cache fährt und welches Daten, die sich in den verschiedenen Cache-Speichern befinden, die den verteilten Cache beinhalten, synchronisieren muss.
HARDWARE-ÜBERSICHT
5 ist ein Blockdiagramm, das ein Computersystem 500 darstellt, auf dem eine Ausführungsform der Erfindung implementiert werden kann. Das Computersystem 500 beinhaltet einen Bus 502 oder einen anderen Kommunikationsmechanismus zum Weiterleiten von Information, und einem mit dem Bus 502 verbundenen Prozessor 503 zum Verarbeiten von Informationen. Das Computersystem 500 beinhaltet auch einen Hauptspeicher 506, wie beispielsweise einen RAM (Direktzugriffsspeicher) oder eine andere dynamische Speichervorrichtung, die mit dem Bus 502 verbunden ist, um Informationen und durch den Prozessor 503 auszuführende Anweisungen zu speichern. Der Hauptspeicher 506 kann auch zum Speichern von temporären Variablen oder anderen Zwischeninformationen während eines Ausführens von durch den Prozessor 503 auszuführenden Anweisungen verwendet werden. Das Computersystem 500 beinhaltet weiter einen ROM (Nur-Lese-Speicher) 508 oder eine andere mit dem Bus 502 verbundene statische Speichervorrichtung zum Speichern statischer Informationen und Anweisungen für den Prozessor 503. Eine Speichervorrichtung 510, wie beispielsweise eine Magnetplatte oder eine optische Platte, ist vorgesehen und mit dem Bus 502 verbunden, um Informationen und Anweisungen zu speichern.
Das Computersystem 500 kann über einen Bus 502 mit einer Anzeigeeinrichtung 512 wie beispielsweise einer Kathodenstrahlröhre (CRT) verbunden sein, um einem Computerbenutzer Informationen anzuzeigen. Eine Eingabevorrichtung 513, die alphanumerische und weitere Tasten beinhaltet, ist mit dem Bus 502 verbunden, um Informationen und ausgewählte Befehle an den Prozessor 503 zu übermitteln. Ein weiterer Typ vom Benutzereingabevorrichtung ist eine Cursorsteuerung 516, wie beispielsweise ein Maus, ein Trackball oder Cursor-Richtungstasten, um Richtungsinformationen und ausgewählte Befehle an den Prozessor 503 zu übermitteln und die Cursorbewegung auf der Anzeigevorrichtung 512 zu steuern. Diese Eingabevorrichtung weist typischerweise zwei Freiheitsgrade in zwei Achsen auf, einer ersten Achse (z. B. x) und einer zweiten Achse (z. B. y), was ermöglicht, dass die Vorrichtung Positionen in einer Ebene bezeichnen kann.
Die Erfindung betrifft die Verwendung eines Computersystems 500 zum Auswählen einer speziellen Version eines an eine Transaktion zu liefernden Datenelementes. Gemäß einer Ausführungsform der Erfindung erfolgt das Auswählen einer speziellen Version eines an eine Transaktion zu liefernden Datenelementes durch ein Computersystem 500, und zwar reagierend darauf, dass der Prozessor 503 eine oder mehrere Sequenzen von einer oder mehreren im Hauptspeicher 506 enthaltenen Anweisungen ausführt. Derartige Anweisungen können in den Hauptspeicher 506 von einem weiteren computerlesbaren Medium, wie beispielsweise einer Speichervorrichtung 510, eingelesen werden. Ein Ausführen der im Hauptspeicher 506 enthaltenen Anweisungssequenzen bewirkt, dass der Prozessor 503 die hier beschriebenen Prozessschritte durchführt. Einer oder mehrere Prozessoren in einer Mehrfach-Verarbeitungsanordnung können auch verwendet werden, um die im Hauptspeicher 506 enthaltenen Befehlsabfolgen auszuführen. Bei alternativen Ausführungsformen kann eine fest verdrahtete Schaltungsanordnung verwendet werden, und zwar anstelle von Softwareanweisungen oder in Kombination mit diesen, um die Erfindung zu implementieren. Daher sind die Ausführungsformen der Erfindung nicht auf irgendeine spezielle Kombination aus Hardware-Schaltungsanordnung und Software eingeschränkt.
Der Begriff "computerlesbares Medium", wie hier verwendet, betrifft ein beliebiges Medium, das daran beteiligt ist, Anweisungen an den Prozessor 503 zum Ausführen zu liefern. Ein derartiges Medium kann viele Formen annehmen, einschließlich, jedoch nicht eingeschränkt auf nichtflüchtige Medien, flüchtige Medien und Übertragungsmedien. Nichtflüchtige Medien beinhalten beispielsweise optische oder magnetische Platten, wie beispielsweise die Speichervorrichtung 510. Flüchtige Medien beinhalten einen dynamischen Speicher, wie beispielsweise den Hauptspeicher 506. Übertragungsmedien beinhalten Koaxialkabel, Kupferdraht- und Glasfaserkabel, einschließlich der Drähte, die den Bus 502 beinhalten. Übertragungsmedien können auch die Form von akustischen Wellen oder Lichtwellen annehmen, beispielsweise solche, die während Radiowellen- und Infrarot-Datenkommunikationen erzeugt werden.
Übliche Formen vom computerlesbaren Medien beinhalten beispielsweise eine Floppy-Disk, eine Diskette, eine Festplatte, ein Magnetband oder ein beliebiges anderes magnetisches Medium, eine CD-ROM, ein beliebiges anderes optisches Medium, Lochkarten, Papierband, ein beliebiges anderes physisches Medium mit Lochmustern, ein RAM, ein PROM und ein EPROM, ein FLASH-EPROM, einen beliebigen anderen Speicherchip oder eine -kassette, eine Trägerwelle wie nachfolgend beschrieben, oder ein beliebiges anderes Medium, von dem ein Computer lesen kann.
Verschiedene Formen von computerlesbaren Medien können daran beteiligt sein, eine oder mehrere Sequenzen von einer oder mehreren Anweisungen zum Prozessor 503 zur Ausführung zu transportieren. Beispielsweise können sich die Anweisungen zu Anfang auf einer Magnetscheibe eines entfernt angeordneten Computers befinden. Der entfernt angeordnete Computer kann die Anweisungen in seinen dynamischen Speicher laden und die Anweisungen über eine Telefonleitung unter Verwendung eines Modems senden. Ein Modem, das sich lokal beim Computersystem 500 befindet, kann die auf der Telefonleitung befindlichen Daten empfangen und eine Infrarot-Übertragungseinrichtung verwenden, um die Daten in ein Infrarotsignal umzuwandeln. Eine Infrarot-Erfassungseinrichtung, die mit Bus 502 verbunden ist, kann die im Infrarotsignal transportierten Daten empfangen, und eine geeignete Schaltungsanordnung kann die Daten auf dem Bus 502 platzieren. Der Bus 502 transportiert die Daten zum Hauptspeicher 506, von dem aus der Prozessor 503 die Anweisungen ausliest und ausführt. Die vom Hauptspeicher 506 empfangenen Anweisungen können optional in der Speichervorrichtung 510 gespeichert werden, und zwar entweder vor oder nach dem Ausführen durch den Prozessor 503.
Das Computersystem 500 beinhaltet auch eine Kommunikationsschnittstelle 518, die mit dem Bus 502 verbunden ist. Die Kommunikationsschnittstelle 518 sorgt für eine Zweiweg-Datenkommunikationsverbindung zu einem Netzwerk-Verbindungsglied 520, das mit einem lokalen Netz 522 verbunden ist. Beispielsweise kann die Kommunikationsschnittstelle 518 eine ISDN-(Integrated Services Digital Network)-Karte oder ein Modem sein, um eine Datenkommunikationsverbindung zu einem entsprechenden Typ von Telefonleitung bereitzustellen. Als weiteres Beispiel kann die Kommunikationsschnittstelle 518 eine LAN-(Local Area Network)-Karte sein, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN bereitzustellen. Drahtlose Verkehrsverbindungen können auch implementiert sein. Bei jeder derartigen Implementierung sendet und empfängt die Kommunikationsschnittstelle 518 elektrische, elektromagnetische oder optische Signale, welche digitale Datenströme transportieren, die verschiedene Typen von Information repräsentieren.
Das Netzwerk-Verbindungsglied 520 sorgt typischerweise für eine Datenkommunikation über eines oder mehrere Netze zu anderen Datenvorrichtungen. Beispielsweise kann das Netzwerk-Verbindungsglied 520 eine Verbindung über ein lokales Netz 522 zu einem Host-Computer 524 oder zu einer Datenanlage bereitstellen, die durch einen Internetdienstanbieter (ISP) 526 betrieben wird. Der ISP 526 stellt seinerseits Datenkommunikationsdienste über das weltweite Paketdaten-Kommunikationsnetz bereit, das heutzutage allgemein als "Internet" 528 bezeichnet wird. Das lokale Netz 522 und das Internet 528 verwenden beide elektrische, elektromagnetische oder optische Signale, welche digitale Datenströme transportieren. Die über die verschiedenen Netzwerke übertragenen Signale, und die beim Netzwerk-Verbindungsglied 520 und über die Kommunikationsschnittstelle 518 übertragenen Signale, welche die digitalen Signale vom Computersystem 500 weg und zu diesem hin transportieren, sind beispielhafte Formen von die Informationen transportierenden Trägerwellen.
Das Computersystem 500 kann Nachrichten senden und Daten, einschließlich Programmcode empfangen, und zwar über das/die Netzwerk(e), das Netzwerk-Verbindungsglied 520 und die Kommunikationsschnittstelle 518. Beim Beispiel des Internet könnte ein Server 530 einen angeforderten Code für ein Anwendungsprogramm über das Internet 528, den ISP 526, das lokale Netz 522 und die Kommunikationsschnittstelle 518 übertragen. In Übereinstimmung mit der Erfindung sorgt eine einzige derartige heruntergeladene Anwendung für das Auswählen einer speziellen Version eines Datenelementes, das an eine Transaktion zu liefern ist, wie hier beschrieben wurde.
Der empfangene Code kann durch den Prozessor 503 bei seinem Empfang ausgeführt werden, und/oder in der Speichervorrichtung 510 oder einem anderen nichtflüchtigen Speicher zur späteren Ausführung gespeichert werden. Auf diese Weise kann das Computersystem 500 Anwendungscode in Form einer Trägerwelle erhalten.
ERGEBNIS
Mit den hier beschriebenen Verfahren wird in effizienter Weise bestimmt, welche Datenelementversionen einer Abfrage geliefert werden können, und sie können verwendet werden, um zu bestimmen, welche Datenelementversionen den geringsten Arbeitsaufwand erfordern, um der Abfrage zu genügen, und zwar durch:

1) Zuordnen eines ersten neuen Feldes zu jedem Klon, wobei das erste neue Feld den Zeitpunkt angibt, zu dem eine Datenelementversion aktuell war,
2) Zuordnen eines zweiten neuen Feldes zu jeder Abfrage, wobei das zweite neue Feld die letzte von einer Transaktion vorgenommene Änderung angibt, die die Abfrage sehen muss, und
3) Verwenden des Wertes des ersten neuen Feldes eines Klons, und des Wertes des zweiten neuen Feldes der Abfrage, um zu bestimmen, ob der Klon der Abfrage geliefert werden kann.

Mit diesem Mechanismus wurde das Ziel erreicht, ohne:

1) ein Rundsenden von Nachrichten an alle in einem Cluster befindlichen Knoten durchzuführen, um ein Aktualisieren oder Ungültigmachen aller nicht-aktueller Versionen des/der Datenelemente(s) auszulösen,
2) Sperrungen (Locks) zu erlangen, oder
3) exzessive Rollback-Vorgänge durchzuführen.

Somit ist der Mechanismus in der Lage, eine geeignete Datenelementversion zu liefern, um mit minimalem Arbeitsaufwand einer Abfrage zu genügen.

Claims

Ein Verfahren zur Verwendung in einer Datenbankumgebung, die mehrere Versionen eines Datenelements aufweist, einschließlich einer aktuellen Version des Datenelements, die alle Veränderungen wiedergibt, die an dem Datenelement vorgenommen worden sind, wobei das Verfahren dazu dient, zu bestimmen, welche Version des Datenelements verwendet werden soll, um eine Anfrage zu beantworten, die in einer Transaktion ausgeführt wird, welche nicht in der Lage sein darf, die von gleichzeitig ablaufenden Transaktionen ausgeführten Veränderungen zu sehen, bis diese Transaktionen festgeschrieben werden, wobei das Verfahren die computerimplementierten Schritte aufweist: Unterhalten eines der Anfrage zugeordneten LETZTE-SICHT-ZEITSTEMPELS, der die Zeit der letzten in der Transaktion ausgeführten Veränderung angibt, die von der Anfrage gesehen werden muss; Unterhalten einer KLON-ZEIT zu einer Datenelementversion, wobei die KLON-ZEIT eine Zeit angibt, zu der die Datenelementversion aktuell war, wobei: falls die Datenelementversion von einem anderen Klon geklont worden ist, die KLON-ZEIT der Datenelementversion die dem anderen Klon zugeordnete KLON-ZEIT ist; und falls die Datenelementversion von der aktuellen Version des Datenelements geklont worden ist, die KLON-ZEIT der Datenelementversion die Zeit wiedergibt, zu der die Datenelementversion von der aktuellen Version des Datenelements geklont worden ist; und Feststellen, dass die Datenelementversion auf die Anfrage geliefert werden soll, nachdem jedwede Änderungen, die die Anfrage nicht sehen kann, von der Datenelementversion entfernt worden sind; wobei der Schritt des Feststellens, dass die Datenelementversion auf die Anfrage geliefert werden soll, zumindest zum Teil auf einem Vergleich zwischen der KLON-ZEIT und dem LETZTE-SICHT-ZEITSTEMPEL beruht, so dass die ausgewählte Datenelementversion in die Kategorie von Versionen fällt, die alles enthalten, was die Anfrage sehen muss, wobei die KLON-ZEIT der Datenelementversion, die auf die Anfrage geliefert werden soll, eine Zeit wiedergibt, die zumindest so wenig zurückliegend wie der LETZTE-SICHT-ZEITSTEMPEL der Anfrage ist.
Das Verfahren nach Anspruch 1, bei dem der Schritt des Bestimmens ein auf dem Vergleich zwischen der KLON-ZEIT und dem LETZTE-SICHT-ZEITSTEMPEL beruhendes Auswählen der Datenelementversion von einer Mehrzahl von Datenelementversionen aufweist, die dafür geeignet sind, für die Transaktion bereitgestellt zu werden.
Das Verfahren nach Anspruch 1, ferner mit dem Schritt, die KLON-ZEIT beruhend auf einer globalen Uhr zu setzen, wenn die Datenelementversion von einer aktuellen Version geklont wird.
Das Verfahren nach Anspruch 1, bei dem: eine Mehrzahl von Knoten in einem Cluster Datenelementversionen für das Datenelement aufweisen; und das Verfahren ferner die Schritte umfasst: Unterhalten von KLON-ZEIT-Informationen für das Datenelement für jeden Knoten der Mehrzahl von Knoten; und beruhend auf den KLON-ZEIT-Informationen beruhendes Auswählen, an welchen Knoten eine Anfrage nach dem Datenelement gesendet werden soll.
Das Verfahren nach Anspruch 4, bei dem der Schritt des Unterhaltens von KLON-ZEIT-Informationen das Unterhalten eines Vektors für das Datenelement umfasst, der Knoten und KLON-ZEITEN einander zuordnet, wobei die KLON-ZEITEN, die einem bestimmten Knoten in dem Vektor zugeordnet sind, KLON-ZEITEN sind, die Datenelementversionen zugeordnet sind, die sich in dem bestimmten Knoten befinden.
Das Verfahren nach Anspruch 1, bei dem der Schritt des Bestimmens aufweist: beruhend auf Informationen über entfernte Daten ausgeführtes Bestimmen, ob Veränderungen, die gesehen werden müssen, von der Datenelementversion entfernt worden sind; und beruhend auf der KLON-ZEIT ausgeführtes Bestimmen, ob es möglich ist, dass Informationen, die gesehen werden müssen, in eine aktuelle Version des Datenelements nach der Erzeugung der Datenelementversion eingebracht worden sind.
Das Verfahren nach Anspruch 1, bei dem der Schritt des Bestimmens aufweist: beruhend auf der der Datenelementversion zugeordneten KLON-ZEIT ausgeführtes Bestimmen, ob Veränderungen, die von der Anfrage gesehen werden müssen, möglicherweise an dem Datenelement nach der Erzeugung der Datenelementversion vorgenommen worden sind; und auf einer JÜNGSTEN-AUFNAHMEZEIT, die der Datenelementversion zugeordnet ist, beruhendes Bestimmen, ob Veränderungen, die von der Anfrage gesehen werden müssen, möglicherweise aus der Datenelementversion entfernt worden sind.
Das Verfahren nach Anspruch 7, bei dem der Schritt des Auswählens eine Verwendung der KLON-ZEIT-Informationen umfasst, um einen Kandidaten auszuwählen, bei dem weniger Änderungen als bei den anderen Kandidaten entfernt werden müssen.
Ein computerlesbares Medium mit Instruktionen, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren dazu veranlassen, die in einem der Ansprüche 1-8 erwähnten Schritte auszuführen.