DE69901291T2

DE69901291T2 - Verfahren und vorrichtung zur datenübertragung zwischen der caches von netzwerkknoten

Info

Publication number: DE69901291T2
Application number: DE69901291T
Authority: DE
Inventors: J. Bamford; Boris Klots
Original assignee: Oracle Corp
Current assignee: Oracle International Corp
Priority date: 1998-02-13
Filing date: 1999-02-12
Publication date: 2002-12-05
Anticipated expiration: 2019-02-13
Also published as: HK1039812A1; CA2320240A1; US6411968B2; US20010037342A1; US20020016795A1; JP2002503846A; US20010047380A1; DE69929095T2; US6567827B2; HK1061724A1; DE69901291D1; HK1041534B; US20010042066A1; US20010037343A1; US6609136B2; HK1041535A1; WO1999041664A1; US6507853B2; DE69929095D1; DE69918470T2

Description

Gebiet der Erfindung

Die Erfindung betrifft Techniken zum Reduzieren der Nachteile, welche damit assoziiert sind, wenn ein Knoten Daten von einem Datenspeicher anfordert, wenn sich die neueste Version der angeforderten Daten im Zwischenspeicher eines anderen Knotens befindet.

Hintergrund der Erfindung

Um die Skalierbarkeit zu verbessern, erlauben manche Datenbank-Systeme es mehr als einem Datenbankserver (von denen jeder separat läuft) konkurrierend auf gemeinsam benutzten Speicher, wie sie zum Beispiel auf Plattenmedien gespeichert sind, zuzugreifen. Jeder Datenbankserver hat einen Zwischenspeicher zum Zwischenspeichern gemeinsam benutzter Ressourcen, wie zum Beispiel Plattenblöcke. Solche Systeme werden hierin als Parallel-Server-Systeme bezeichnet.
Ein Problem, welches mit Parallel-Server-Systemen assoziiert ist, ist die Möglichkeit für sogenannte "Pings". Ein Ping tritt auf, wenn die Version einer Ressource, welche sich in dem Zwischenspeicher eines Servers befindet, zu dem Zwischenspeicher eines anderen Servers geliefert werden muss. Dadurch tritt ein Ping auf, sobald, nachdem ein Datenbankserver A eine Ressource x in seinem Zwischenspeicher modifiziert hat, ein Datenbankserver B die Ressource x zum modifizieren anfordert. Datenbankserver A und B werden typischerweise auf verschiedenen Knoten laufen, können aber auch in manchen Fällen auf demselben Knoten laufen.
Ein Ansatz, Pings zu handhaben wird hierin als der "Platten- Interventions"-Ansatz bezeichnet. Der Platten-Interventions- Ansatz verwendet eine Platte als intermediären Speicher, um die letzte Version von einer Ressource zwischen zwei Zwischenspeichern zu übertragen. Daher erfordert der Platten- Interventions-Ansatz, im oben beschriebenen Beispiel, einen Datenbankserver 1, um die Version der Ressource X aus seinem Zwischenspeicher Platte zu schreiben und einen Datenbankserver 2, um diese Version von Platte in seinen Zwischenspeicher zu laden. Das Stützen des Platten-Interventions-Ansatzes auf zwei Platten E/As je Zwischenserver-Übertragung einer Ressource limitiert die Skalierbarkeit von Parallel-Server-Systemen. Insbesondere sind die Platten E/As, welche benötigt werden, um ein Ping zu handhaben, relativ teuer und zeitraubend und je mehr Datenbankserver zu dem System hinzugefügt werden, desto höher wird die Anzahl der Pings.
Jedoch sorgt der Platten-Interventions-Ansatz für eine relativ effiziente Wiederherstellung von EinzelDatenbankserver- Ausfällen, indem für solch ein Wiederherstellen nur das Ausführen des Wiederherstellungsprotokoll (Wiederholungsprotokoll) des abgestürzten Datenbankservers nötig ist. Das Ausführen bringen des Wiederholungsprotokolls des abgestürzten Datenbankservers stellt sicher, dass alle durchgeführten Änderungen, welche Transaktionen auf dem abgestürzten Datenbankserver an den Ressourcen in dem Zwischenspeicher des abgestürzten Server gemacht haben, wiederhergestellt werden. Das Verwenden von Wiederholungsprotokollen während einer Wiederherstellung ist im Detail in der U.S. Patentanmeldung Nr. 08/784,611 beschrieben mit dem Titel "Caching Data in Recoverable Objects", eingereicht am 21. Januar 1997.
Parallel Server Systeme, welche den Platten-Interventions- Ansatz anwenden, verwenden typischerweise ein Protokoll, in welchem jede global Entscheidung, welche den Ressourcenzugriff und Ressourcenmodifikationen betrifft, mittels eines Verteilten-Sperrmanagers (DLM) durchgeführt wird. Die Funktion eines beispielhaften DLM ist im Detail in der am 24, Juni 1996 eingereichten U.S. Patentanmeldung Nummer 08/669,689 mit dem Titel "Method and Apparatus for Lock Caching" beschrieben.
In typischen Verteilten-Sperrmanager Systemen werden Informationen, welche irgendeine gegebene Ressource betreffen, in einem Sperr-Objekt gespeichert, welches mit der Ressource korrespondiert. Jedes Sperr-Objekt ist in dem Speicher eines einzelnen Knoten gespeichert. Der Sperrmanager, welcher in dem Knoten, in welchem ein Sperr-Objekt gespeichert ist, residiert, wird als Hauptserver des Sperr-Objekts und der Ressource die es umfasst bezeichnet.
In Systemen, welche den Platten-Interventions-Ansatz zum Handhaben von Pings anwenden, tendieren Pings dazu, den DLM in eine Vielzahl von sich auf Sperren beziehende Kommunikationen zu verwickeln. Insbesondere, wenn ein Datenbankserver (der "anfordernde Server") auf eine Ressource zugreifen muss, prüft der Datenbankserver, um zu sehen ob er die gewünschte Ressource in dem passenden Modus gesperrt hat: entweder gemeinschaftlich im Falle eines Lesens, oder ausschließlich im Falle eines Schreibens. Wenn der anfordernde Datenbankserver die gewünschte Ressource nicht in dem richtigen Modus gesperrt hat oder keinerlei Sperre auf die Ressource hat, dann sendet der anfordernde Server eine Anforderung zu dem Hauptserver für die Ressource, um die Sperre im spezifiziertem Mode zu erlangen.
Die Anforderung, welche von dem anfordernden Datenbankserver veranlasst wird, kann mit dem aktuellen Status der Ressource im Widerspruch stehen (z. B. könnte es einen anderen Datenbankserver geben, welcher jetzt eine Ausschließlich- Sperre auf die Ressource hält). Wenn es keinen Widerspruch gibt, erteilt der Hauptserver der Ressource die Sperre und speichert die Erteilung. Im Falle eines Widerspruchs initiiert der Hauptserver der Ressource ein Konflikt-Lösungs-Protokoll. Der Hauptserver der Ressource instruiert den Datenbankserver, welcher die im Widerspruch stehende Sperre hält (den "Halter") seine Sperre in einen niedrigeren, kompatiblen Modus herabzusetzen.
Unglücklicherweise kann, wenn der Halter (z. B. der Datenbankserver A) jetzt eine aktualisierte ("unreine") Version der gewünschten Ressource in seinem Zwischenspeicher hat, er nicht unmittelbar seine Sperre herabsetzen. Um seine Sperre herabzusetzen, durchläuft der Datenbankserver A etwas, was als "Hard-Ping" Protokoll bezeichnet wird. Gemäß dem Hard- Ping Protokoll, erzwingt Datenbankserver A, dass das Wiederholungsprotokoll, welches mit dem Aktualisieren assoziiert ist, auf die Platte geschrieben wird, schreibt die Ressource auf Platte, setzt seine Sperre herab und meldet dem Hauptserver, dass Datenbankserver A fertig ist. Nach Empfangen der Benachrichtigung, registriert der Hauptserver das Erteilen der Sperre und benachrichtigt den anfordernden Server, dass die angeforderte Sperre erteilt wurde. Zu diesem Punkt liest der anfordernde Server B die Ressource von der Platte in seinen Zwischenspeicher.
Wie oben beschrieben erlaubt der Platten-Interventions-Ansatz nicht, dass eine Ressource, welche mittels eines Datenbankserver aktualisiert wurde (eine "unreine Ressource"), direkt an einen anderen Datenbankserver versendet wird. Solch ein direktes Versenden wird wegen Problemen, welche mit dem Wiederherstellen verbunden sind, als undurchführbar betrachtet. Beispielsweise angenommen, dass eine Ressource am Datenbankserver A modifiziert wird und dann direkt zum Datenbankserver B versendet wird. Am Datenbankserver B wird die Ressource ebenfalls modifiziert und dann zum Datenbankserver A zurückgesendet. Im Datenbankserver A wird die Ressource ein drittes Mal modifiziert. Ferner angenommen, dass jeder Server alle Wiederholungsprotokolle auf Platte schreibt, bevor er die Ressource zu einem anderen Server sendet, um es dem Empfänger zu ermöglichen, sich auf frühere Änderungen zu verlassen.
Nach der dritten Aktualisierung angenommen (nimm an) dass der Datenbankserver A abstürzt. Das Protokoll des Datenbankservers A enthält Berichte der Modifikationen an der Ressource mit einer Lücke. Insbesondere enthält das Protokoll des Servers A nicht solche Modifikationen, welche vom Datenbankserver B gemacht wurden. Vielmehr sind die Modifikationen, welche vom Server B gemacht wurden, in dem Protokoll des Datenbankservers B gespeichert. An diesem Punkt müssen, um die Ressource wiederherzustellen, die zwei Protokolle erst zusammengefügt werden, bevor sie angewandt werden. Diese Protokoll- Zusammenfüg-Operation würde, wenn realisiert, Zeit und Hilfsmittel proportional zu der Gesamtenzahl von Datenbankservern, inklusive derer die nicht abgestürzt sind, benötigen.
Der oben beschriebene Platten-Interventions-Ansatz vermeidet das Problem, welches mit dem Zusamenfügen von Wiederherstellungsprotokollen nach einem Absturz verbunden ist, aber verschlechtert die Leistungsfähigkeit von sich im Dauerzustand (Normalzustand) befindenden Parallel-Server- Systemen zu Gunsten einer leichten und effizienten Wiederherstellung. Der Direkt-Versendungs-Ansatz vermeidet den Overhead, welcher mit dem Platten-Interventions-Ansatz assoziiert ist, aber hat im Falle von Abstürzen komplexe und nicht skalierbare Wiederherstellungs-Operationen zur Folge.
Basierend auf dem Vorhergehenden ist es klar wünschenswert ein System und Verfahren zum Reduzieren des Overheads, welcher mit einem Ping assoziiert ist, bereitzustellen, ohne die Komplexität und die Dauer der Wiederherstellungsoperationen stark zu erhöhen.

Zusammenfassung der Erfindung

Die Erfindung ist in den angefügten unabhängigen Ansprüchen abgegrenzt. Ein Verfahren und eine Vorrichtung zum Übertragen einer Ressource von dem Zwischenspeicher eines Datenbankservers zu dem Zwischenspeicher eines anderen Datenbankservers, ohne die Ressource zuerst auf Platte zu schreiben, werden bereitgestellt. Wenn ein Datenbankserver (Nachfrager) wünscht, eine Ressource zu modifizieren, fragt der Nachfrager nach der aktuellen Version der Ressource. Der Datenbankserver, welcher die aktuelle Version (Halter) hat, versendet die aktuelle Version direkt an den Nachfrager. Nach Versenden der Version, verliert der Halter die Genehmigung, die Ressource zu modifizieren, aber behält weiterhin eine Kopie der Ressource im Speicher. Wenn die behaltene Version der Ressource oder eine spätere Version davon auf Platte geschrieben wird, kann der Halter die behaltene Version der Ressource verwerfen. Anderenfalls verwirft der Halter die behaltene Version nicht. Im Falle eines Serverabsturzes, werden, so notwendig, die früheren Kopien aller Ressourcen mit Modifikationen in dem Wiederherstellungsprotokoll des abgestürzten Server als Startpunkt zum Ausführen des Wiederherstellungsprotokolls des abgestürzten Servers verwendet. Unter Verwenden dieser Technik werden Einzel- Server-Abstürze (die üblichste Form von Abstürzen) wiederhergestellt, ohne dass die Wiederherstellungsprotokolle der verschiedenen Datenbankserver, welche Zugriff auf die Ressource hatten, zusammengefügt werden müssen.

Kurzbeschreibung der Figuren

Die Erfindung ist mittels Beispiels und nicht mittels Einschränkung anhand der Figuren der beiliegenden Zeichnungen erläutert, in welchen gleiche Bezugszeichen sich auf ähnliche Elemente beziehen und in welchen:
Fig. 1 ein Blockschaubild ist, welches Zwischenspeicher zu Zwischenspeicher Übertragungen der neuesten Versionen von Ressourcen erläutert;
Fig. 2 ein Flussdiagramm ist, welches Schritte zum Übertragen einer Ressource von einem Zwischenspeicher zu einem anderen, ohne Platten-Intervention gemäß einem Ausführungsbeispiel der Erfindung erläutert;
Fig. 3 ein Flussdiagramm ist, welches Schritte zum Freigeben früherer Abbilder von Ressourcen gemäß einem Ausführungsbeispiel der Erfindung erläutert;
Fig. 4 ein Flussdiagramm ist, welches Schritte zum Wiederherstellen nach einem Absturz eines einzelnen Servers gemäß einem Ausführungsbeispiel der Erfindung erläutert;
Fig. 5 ein Blockschaubild ist, welches einen Anhaltepunkt- Umlauf, gemäß einem Ausführungsbeispiel der Erfindung, erläutert;
Fig. 6 ein Blockschaubild eines Computersystems ist, auf welchem ein Ausführungsbeispiels der Erfindung realisiert werden kann.

Detaillierte Beschreibung des bevorzugten Ausführungsbeispiels

Es wird ein Verfahren und eine Vorrichtung zum Reduzieren des Overheads, welcher mit einem Ping assoziiert ist, beschrieben. In der folgenden Beschreibung werden zum Zweck der Erläuterung zahlreiche spezifische Details erklärt, um ein vollständiges Verständnis der Erfindung zu schaffen. Es wird jedoch für einen Fachmann ersichtlich sein, dass die Erfindung ohne diese spezifischen Details umgesetzt werden kann. Andererseits werden Datenbankservern, allseits bekannte Strukturen und Vorrichtungen, in Blockdiagrammform gezeigt, um unnötiges Unklarmachen (Verschleiern) der Erfindung zu verhindern.

Funktioneller Überblick

Gemäß einem Aspekt der Erfindung, werden Pings mittels direkten Versendens von aktualisierten Versionen der Ressourcen, ohne vorher auf Platte gespeichert worden zu sein, direkt zwischen Datenbankservern gehandhabt, wodurch der E/A Overhead, welcher mit dem Platten-Interventions-Ansatz assoziiert ist, vermieden wird. Ferner werden die Schwierigkeiten, welche mit dem Wiederherstellen eines Einzelinstanz-Absturzes assoziiert sind, vermieden, indem, sogar wenn die Ressource zu einem anderen Zwischenspeicher übertragen wurde, verhindert wird, dass eine modifizierte Version der Ressource im Zwischenspeicher ersetzt wird, bis die modifizierte Ressource oder irgendein Nachfolger davon auf Platte geschrieben wurde.
Zur Erläuterung, eine Kopie einer Ressource, welche im Zwischenspeicher nicht ersetzt (überschrieben) werden kann, wird hierin als eine "festgehaltene" Ressource bezeichnet. Die Handlung eine festgehaltene Ressource ersetzbar (überschreibbar) zu machen, wird als "freigeben" der Ressource bezeichnet.

Der M- und W-Sperren-Ansatz

Gemäß einem Aspekt der Erfindung sind die Genehmigungen zum Modifizieren und Auf-Platte-Schreiben für eine Ressource getrennt. Daher hat ein Datenbankserver, welcher die Genehmigung hat, eine aktualisierte Version einer Ressource vom Zwischenspeicher auf Platte zu schreiben, nicht Notwendigerweise die Genehmigung die Ressource zu aktualisieren. Umgekehrt hat ein Datenbankserver, welcher die Genehmigung hat, eine zwischengespeicherte Version einer Ressource zu modifizieren, nicht Notwendigerweise die Genehmigung diese zwischengespeicherte Version auf Platte zu schreiben.
Gemäß einem Ausführungsbeispiel wird diese Trennung der Genehmigungen mittels das Verwenden von speziellen Sperren durchgesetzt. Insbesondere kann die Genehmigung eine Ressource zu modifizieren mittels einer "M"-Sperre erteilt werden, während die Genehmigung eine Ressource auf Platte zu schreiben mittels einer "W"-Sperre erteilt werden kann. Es ist jedoch zu bemerken, dass das Benutzen von M- und W-Sperren wie hierin beschrieben nur einen Mechanismus darstellt, welcher eine übertragene Version einer Ressource davor schützt, im Zwischenspeicher ersetzt zu werden, bis diese Version oder ein Nachfolger davon auf Platte geschrieben wurde.
Bezugnehmend auf Fig. 2, sie erläutert die Schritte welche in Antwort auf ein Ping in einem Datenbank-System, welches M- und W-Sperren gemäß einem Ausführungsbeispiel der Erfindung, verwendet ausgeführt werden. An Schritt 200 fordert ein Datenbankserver, welcher wünscht eine Ressource zu modifizieren, die M-Sperre vom Hauptserver der Ressource (d. h. dem Datenbankserver, welcher die Sperren der Ressource verwaltet) an. An Schritt 202 instruiert der Hauptserver den Datenbankserver, welcher gerade die M-Sperre der Ressource hält ("der Halter"), die M-Sperre zusammen mit der zwischengespeicherten Version der Ressource mittels direkter Übertragung über den Kommunikationskanal (-kanäle), welche(r) die zwei Server koppelt(n) (die "Verbindung"), zu dem anfordernden Datenbankserver zu übertragen.
An Schritt 204 schickt der Halter die aktuelle Version der Ressource und die M-Sperre zu dem Anforderer. An Schritt 206, informiert der Halter den Hauptserver über die Übertragung der M-Sperre. An Schritt 208 aktualisiert der Hauptserver die Sperren Information für die Ressource, um anzuzeigen, dass der Anforderer nun die M-Sperre hält.

PI-Ressourcen

Der Halter der M-Sperre hat nicht Notwendigerweise die W- Sperre und mag daher nicht die Genehmigung haben, die Version der Ressource, welche in seinem Zwischenspeicher enthalten ist, auf Platte heraus zu schreiben. Der übertragende Datenbankserver (d. h. der Datenbankserver, welcher zuletzt die M-Sperre hielt) setzt daher fort seine Version der Ressource im dynamischen Speicher festzuhalten, weil er, wie unten beschrieben, zu einem Zeitpunkt in der Zukunft aufgefordert werden könnte, seine Version herauszuschreiben. Die Version der Ressource, welche in dem übertragenden Datenbankserver verbleibt, wird veraltet werden, wenn der empfangende Datenbankserver seine Kopie der Ressource modifiziert. Der übertragende Datenbankserver wird nicht Notwendigerweise wissen, wann der empfangende Datenbankserver (oder ein Nachfolger von ihm) die Ressource modifiziert, daher behandelt er seine verbleibende Version von der Zeit an, wo der übertragende Datenbankserver eine Kopie der Ressource schickt, als "möglicherweise veraltet". Solche möglicherweise veralteten Versionen einer Ressource werden hierin als Frühere-Abbild-Ressourcen (PI-Ressourcen) bezeichnet.

Freigeben von PI-Ressourcen

Nachdem eine zwischengespeicherte Version einer Ressource freigegeben ist, kann sie mit neuen Daten überschrieben werden. Typischerweise kann eine unreine Version einer Ressource mittels Schreibens der Ressource auf Platte freigegeben werden. Jedoch haben Datenbankserver mit PI- Ressourcen im Zwischenspeicher nicht Notwendigerweise das Recht, um PI-Ressourcen auf Platte zu speichern. Eine Technik zum Freigeben von PI-Ressourcen unter diesen Umständen ist in Fig. 3 erläutert.
Bezugnehmend auf Fig. 3, schickt ein Datenbankserver, wenn er wünscht eine PI-Ressource in seinem Zwischenspeicher freizugeben, eine Anforderung für die W-Sperre (Schritt 300) an den Verteilten-Sperrmanager (DLM). Im Schritt 302 beauftragt der DLM dann den anfordernden Datenbankserver, oder irgendeinen Datenbankserver, welcher eine neuere Version der Ressource (ein Nachfolger) in seinem Zwischenspeicher hat, die Ressource auf Platte herauszuschreiben. Dem Datenbankserver, welcher so aufgefordert wird, die Ressource auf Platte zu schreiben, wird die W-Sperre erteilt. Nachdem der Datenbankserver, welchem die W-Sperre erteilt wurde, die Ressource auf Platte geschrieben hat, gibt der Datenbankserver die W-Sperre frei.
Der DLM sendet dann eine Nachricht zu allen Datenbankservern aus, welche die Version der Ressource anzeigt, welche herausgeschrieben wurde (Schritt 304), so dass alle früheren PI-Versionen der Ressource freigegeben werden können (Schritt 306). Beispielsweise angenommen dass die Version, welche zur Zeit T10 modifiziert wurde, auf Platte geschrieben wurde. Ein Datenbankserver mit einer Version der Ressource, welche zuletzt zu einer früheren Zeit T5 modifiziert wurde, könnte jetzt den Puffer, in welchem sie gespeichert ist, für andere Daten verwenden. Ein Datenbankserver mit einer Version, welche zu einer späteren Zeit T11 modifiziert wurde, müsste jedoch fortfahren, seine Version der Ressource in seinem Speicher zu halten.

Ping Management unter dem M- und W-Sperren-Ansatz

Gemäß einem Ausführungsbeispiel der Erfindung, kann, um Pings zu handhaben, der M- und W-Sperren-Ansatz, wie er nun mit Bezug auf Fig. 1 beschrieben werden soll, realisiert werden Bezugnehmend auf Fig. 1 ist es ein Blockschaltbild, welches vier Datenbankserver A, B, C, und D erläutert, von denen alle Zugang zu einer Datenbank haben, welche eine spezielle Ressource enthält. Zu der dargestellten Zeit hat jeder der Datenbankserver A, B und C Versionen der Ressource. Die Version, welche im Zwischenspeicher des Datenbankservers A gehalten wird, ist die vor der kürzesten Zeit modifizierte Version der Ressource (modifiziert zur Zeit T10). Die Versionen, welche in den Datenbankservern B und C gehalten werden, sind PI-Versionen der Ressource. Datenbankserver D ist der Hauptserver der Ressource.
Zu diesem Punkt, angenommen dass ein anderer Datenbankserver (der "Anforderer") wünscht, die Ressource zu modifizieren. Der Anforderer fordert die Modifizier-Sperre vom Hauptserver an. Der Hauptserver schickt ein Befehl zum Datenbankserver A die Sperre wegen der im Widerspruch stehenden Anforderung des Anforderers herabzukonvertieren (ein "BAST"). In Antwort auf das Herabkonvertierungskommando, wird das aktuelle Abbild der Ressource (egal ob sauber oder unrein) vom Datenbankserver A zusammen mit der Genehmigung, die Ressource zu modifizieren, zu dem Anforderer gesandt. Die so gesandte Genehmigung schließt keine Genehmigung ein, die Ressource auf Platte zu schreiben.
Wenn Datenbankserver A die M-Sperre zu dem Anforderer weiterreicht, setzt Datenbankserver A seine M-Sperre zu einer "Halte"-Sperre (und "H-Sperre") herab. Die H-Sperre zeigt an, dass der Datenbankserver A eine festgehaltene PI-Kopie hält. Besitz einer H-Sperre verpflichtet den Besitzer die PI-Kopie in seinem Puffer-Zwischenspeicher zu halten, aber gibt dem Datenbankserver keinerlei Rechte die PI-Kopie auf Platte zu schreiben. Es kann mehrere gleichzeitige H-Halter für die gleiche Ressource geben, aber zu einer Zeit kann nicht mehr als ein Datenbankserver die Ressource schreiben, daher kann nur ein Datenbankserver eine W-Sperre an der Ressource halten.
Bevor die Ressource versendet wird, stellt der Datenbankserver A sicher, dass die Sperre durchgesetzt ist (d. h. dass das Wiederherstellungsprotokoll, welches für die Änderungen der Ressource erzeugt wurde, welche mittels des Datenbankservers A gemacht wurden, dauerhaft gespeichert wird). Mittels Weiterreichens der Modifikations-Genehmigung, verliert Datenbankserver A sein eigenes Recht die Ressource zu modifizieren. Die Kopie der Ressource (wie sie gerade zum Zeitpunkt des Versenden war) wird immer noch im verschickenden Datenbankserver A gehalten. Nach dem Verschicken der Ressource, ist die Kopie der Ressource, welche im Datenbankserver A gehalten wird, eine PI-Ressource.

Gefälligkeits-Schreiben

Nachdem ein Datenbankserver eine unreine Ressource direkt zu einem anderen Datenbankserver geschickt hat, wird die zurückgehaltene Kopie der Ressource eine festgehaltene Ressource, deren Puffer, bis sie freigegeben wird, nicht für eine andere Ressource genutzt werden kann. Die Puffer, welche PI-Ressourcen enthalten werden hierin als PI Puffer bezeichnet. Diese Puffer belegen wertvollen Platz in den Zwischenspeichern der Datenbankserver und müssen letztlich für andere Daten wiederverwendet werden.
Um PI-Puffer im Puffer-Zwischenspeicher (welcher als veraltet gekennzeichnet oder zu überprüfen ist) zu ersetzen, wird ein neues Platten-Schreib-Protokoll angewendet, welches hierin als "Gefälligkeits-Schreiben" bezeichnet wird. Gemäß dem Gefälligkeits-Schreib-Protokoll sendet der Datenbankserver, wenn ein Datenbankserver eine Ressource auf Platte schreiben muss, eine Anforderung an den DLM. Der DLM wählt eine Version der Ressource aus, welche auf Platte geschrieben werden soll, findet den Datenbankserver, welcher die ausgewählte Version hat und veranlasst im Interesse des Datenbankservers, welcher die Schreibanforderung initiiert hat, diesen Datenbankserver die Ressource auf Platte zu schreiben. Der Datenbankserver, welcher die Ressource wirklich auf Platte schreibt, kann, abhängig von der letzten Trajektorie der Ressource, der Datenbankserver, welcher das Schreiben angefordert hat, oder irgendein anderer Datenbankserver sein.
Schreiben der ausgewählten Version einer Ressource auf Platte, gibt alle PI-Versionen, welche gleich alt oder älter als die ausgewählte Version sind, der Ressource, welche auf Platte geschrieben wurde, in allen Puffer-Zwischenspeichern eines Clusters frei. Die Kriterien, welche verwendet werden, um die Version zu wählen, welche auf Platte geschrieben wird, sollen nachfolgend in größeren Detail beschrieben werden. Jedoch kann die ausgewählte Version entweder die neueste PI-Version, welche dem Hauptserver bekannt ist, oder die aktuelle Version ("CURR") der Ressource sein. Ein Vorteil des Auswählens einer anderen Version als der aktuellen Version ist, dass die Auswahl einer anderen Version die aktuelle Kopie ununterbrochen für Modifikationen verfügbar lässt.
Ein Datenbankserver, welcher eine PI-Ressource hält, kann, vorrausgesetzt, dass er eine W-Sperre auf die Ressource erlangt hat, seine PI-Kopie herausschreiben. Die Schreibvorgänge der Ressource sind von der Migration des CURR- Ressourcen-Abbildes zwischen den verschiedenen Datenbankservern entkoppelt.

Effektivitätsfaktoren

Es besteht keine Notwendigkeit, jedes mal, wenn eine Ressource zu einen anderen Datenbankserver verschickt wird, eine PI- Kopie zu schreiben. Folglich ist das Ziel vom dauerhaften Speichern von Ressourcen die Plattenkopien aktuell genug zu halten und die Anzahl von nicht-überschreibbaren Ressourcen in den Puffer-Zwischenspeichern vernünftig zu halten.
Verschiedene Faktoren bestimmen die Effizienz eines Systems, welches das oben beschriebene Gefälligkeits-Schreib-Protokoll anwendet. Insbesondere ist es wünschenswert:
(1) E/A Aktivität, welche durch das Schreiben von unreinen Ressourcen auf Platte verursacht wird, zu minimieren
(2) die Plattenversionen der Ressourcen ausreichend aktuell halten, um die Wiederherstellungs-Operationen nach einem Absturz zu beschleunigen; und
(3) Überlauf des Puffer-Zwischenspeichers mit festgehaltenen PI-Ressourcen zu verhindern.
Maximieren des ersten Kriteriums hat einen negativen Einfluß auf das zweite und dritte Kriterium und umgekehrt. Dadurch ist ein Handel (Kompromiss) notwendig. Gemäß einem Ausführungsbeispiel der Erfindung kann, gekoppelt mit einer Kontrolle über den gesamten E/A-Haushalt, ein selbstabgestimmter Algorithmus, welcher verschiedene Techniken von mit Prüfpunkten versehen kombiniert (LRU gemischt mit zufälligen kontinuierlichen mit Prüfpunkten versehen), verwendet werden.

Der Aktuell-Schreiben-Ansatz

Eine Alternative zu dem oben beschriebenen Gefälligkeits- Schreib-Protokoll wird hierin als der Aktuell-Schreiben-Ansatz bezeichnet. Gemäß dem Aktuell-Schreiben-Ansatz haben alle Datenbankserver die Genehmigung ihre PI-Ressourcen auf Platte zu schreiben. Bevor sie dies jedoch machen, erlangt ein Datenbankserver eine Sperre auf die plattenresidente Kopie der Ressource. Nach Erlangen der Sperre vergleicht der Datenbankserver die Plattenversion mit der PI-Version, welche er zu schreiben wünscht. Wenn die Plattenversion älter ist, dann wird die PI-Version auf Platte geschrieben. Wenn die Plattenversion neuer ist, dann kann die PI-Version abgelegt werden und der Puffer, welcher belegt ist, kann wiederverwendet werden.
Im Gegensatz zu dem Gefälligkeits-Schrei-Protokoll erlaubt der Aktuell-Schreiben-Ansatz einem Datenbankserver seine eigene PI-Version freizugeben, entweder indem er sie auf Platte schreibt oder indem er feststellt, dass die Plattenversion neuer ist. Jedoch erhöht der Aktuell-Schreiben-Ansatz den Wettstreit um die Sperre der plattenresidenten Kopie und kann ein Platten-E/A nach sich ziehen, welcher mit dem Gefälligkeits-Schreib-Ansatz nicht aufgetreten wäre.

Genehmigungsketten

Typische DLMs verwalten den Zugang zu Ressourcen mittels des Verwendens einer begrenzten Anzahl von Sperrmodi, wo die Modi entweder kompatibel sind oder im Widerstreit stehen. Gemäß einem Ausführungsbeispiel ist, um Sperr-Modi mittels einer Ansammlung von verschiedenen Arten von Genehmigungen und Verpflichtungen zu ersetzen, der Mechanismus zum Verwalten des Zugangs zu Ressourcen erweitert. Die Genehmigungen und Verpflichtungen können zum Beispiel die Genehmigung zum Schreiben einer Ressource, zum Modifizieren einer Ressource, zum Halten einer Ressource im Zwischenspeicher, usw. sein. Spezifische Genehmigungen und Verpflichtungen werden im Folgenden in größeren Detail beschrieben.
Gemäß einem Ausführungsbeispiel sind Genehmigungen und Verpflichtungen in Genehmigungsketten kodiert. Eine Genehmigungskette kann, weil viele Genehmigungen sich eher auf eine Version einer Ressource als auf die Ressource selbst beziehen, mittels einer Ressourcen-Versions-Nummer verlängert werden. Zwei verschiedene Genehmigungsketten stehen in Wiederstreit, wenn sie die gleiche exklusive Genehmigung für die gleiche Version der Ressource verlangen (z. B. aktuelle Version zur Modifikation oder ein Plattenzugriff zum Schreiben). Anderenfalls sind sie kompatibel.

Gemeinschaftliches Verwenden von Genehmigungs-Transfers

Wie oben beschrieben instruiert der Hauptserver, wenn eine Ressource an einem Datenbankserver modifiziert wird und sie für weitere Modifikationen von einem anderen Datenbankserver angefordert wird, den Datenbankserver, welcher die aktuelle Kopie (CURR-Kopie) der Ressource hält, seine M-Sperre (das Recht zu modifizieren) zusammen mit der CURR-Kopie der Ressource zu dem anderen Datenbankserver weiterzugeben. Signifikanterweise wird, obgleich die Anforderung für die M- Sperre an den Hauptserver gesendet wird, das Erteilen mittels irgendeines anderen Datenbankservers (den vorherigen M-Sperren Halter) getan. Dieses Dreiecks-Benachrichtigungsystem weicht signifikant von der herkömmlichen Zweiweg-Kommunikation ab, bei welcher die Antwort auf eine Sperren-Anforderung von dem Datenbankserver erwartet wird, welcher den Sperrmanager enthält, zu welchen die Sperren-Anforderung anfänglich gesendet wurde.
Gemäß einem Ausführungsbeispiel der Erfindung benachrichtigt Datenbankserver A den Hauptserver, dass die M-Sperre transferiert wurde, wenn der Halter der CURR Kopie der Ressource (z. B. Datenbankserver A) die M-Sperre an einen anderen Datenbankserver weiterreicht. Jedoch wartet der Datenbankserver A nicht auf Bestätigung, dass der Hauptserver die Benachrichtigung erhalten hat, sondern sendet die CURR- Kopie und die M-Sperre vor Erhalt einer solchen Bestätigung. Mittels des nicht Abwartens erlegt die Schleifenkommunikation zwischen den Hauptserver und Datenbankserver A der Übertragung keine Verzögerung auf, wodurch sich eine beträchtliche Einsparung von Protokoll-Wartezeiten ergibt.
Da Genehmigungen direkt vom aktuellen Halter der Genehmigung zu dem Anforderer der Genehmigung übertragen werden, weis der Hauptserver nicht immer das exakte globale Bild der Sperren Erteilungen. Vielmehr weis der Hauptserver nur von der Trajektorie der M-Sperre, von den Datenbankservern, welche "sie gerade vor Kurzem hielten", aber nicht von dem exakten Standort der Sperre zu jeder gegebenen Zeit. Gemäß einem Ausführungsbeispiels ist dieses "träge" Benachrichtigungsschema auf die M-Sperren anwendbar aber nicht auf die W-, X- oder S-Sperren (oder ihren Entsprechungen). Verschiedenartige Ausführungsbeispiele eines Sperrenschemas sind im Folgenden in größeren Detail beschrieben.

Absturz-Wiederherstellung

Innerhalb des Kontextes der Erfindung wird gesagt, dass ein Datenbankserver abgestürzt ist, wenn ein Zwischenspeicher, welcher mit dem Server assoziiert ist, unzugänglich wird. Datenbanksysteme, welche das direkte Zwischen-Server- Verschicken von unreinen Ressourcen mittels Verwendens der hierin beschriebenen Techniken anwenden, vermeiden die Notwendigkeit des Zusammenfügens von Wiederherstellungsprotokollen in Antwort auf einen Einzel- Server-Absturz. Gemäß einem Ausführungsbeispiels werden Einzel-Server-Abstürze wie in Fig. 4 erläutert gehandhabt. Bezugnehmend auf Fig. 4 führt das Wiederherstellungsverfahren, nach einem Einzel-Datenbankserver Absturz, für jede Ressource, welche in dem Zwischenspeicher des abgestürzten Datenbankservers gehalten wurde, das Folgende aus:
(Schritt 400) Bestimmen des Datenbankservers, welcher die aktuellste Version der Ressource hält;
(Schritt 402) wenn der Datenbankserver, welcher in Schritt 400 bestimmt wurde, nicht der abgestürzte Datenbankserver ist, dann (Schritt 404) schreibt der bestimmte Datenbankserver seine zwischengespeicherte Version der Ressource auf Platte und (Schritt 406) alle PI-Versionen der Ressource werden freigegeben. Diese Version wird alle an der Ressource begangenen Änderungen haben (inklusive derer, welche mittels des abgestürzten Datenbankservers gemacht wurden) und daher braucht kein Wiederherstellungsprotokoll irgendeines Datenbankservers angewandt werden.
Wenn der Datenbankserver, welcher in Schritt 402 bestimmt wurde, der abgestürzte Datenbankserver ist, dann (Schritt 408) schreibt der Datenbankserver, welcher die letzte PI-Version der Ressource hält, seine zwischengespeicherte Version der Ressource auf Platte heraus und (Schritt 410) alle früheren PI-Versionen werden freigegeben. Die Version, welche auf Platte herausgeschrieben wurde, wird die begangenen Änderungen haben, welche von allen Datenbankservern außer dem abgestürzten Datenbankserver an der Ressource durchgeführt wurden. Das Wiederherstellungsprotokoll des abgestürzten Datenbankservers wird angewandt (Schritt 412), um die begangenen Änderungen, welche mittels des abgestürzten Datenbankservers durchgeführt wurden, wiederherzustellen.
Alternativ kann die letzte PI-Version der Ressource als Startpunkt zur Wiederherstellung der aktuellen Version eher im Zwischenspeicher als auf Platte verwendet werden. Insbesondere können die entsprechenden Aufzeichnungen des Wiederherstellungsprotokolls des abgestürzten Datenbankservers direkt auf die letzte PI-Version, welche im Zwischenspeicher residiert, angewandt werden, wodurch die aktuelle Version im Zwischenspeicher des Datenbankservers, welcher die letzte PI- Version hält, rekonstruiert wird.

Mehrere-Datenbankserver-Absturz

Im Falle eines Mehrere-Server-Absturz, wenn weder die letzte PI-Kopie noch irgendeine CURR Kopie überlebt hat, kann es passieren, dass die Änderungen, welche an der Ressourcen gemacht wurden, über viele Protokolle der abgestürzten Datenbankserver verstreut sind. Unter diesen Umständen müssen die Protokolle der abgestürzten Datenbankserver zusammengefügt werden. Jedoch müssen nur die Protokolle der abgestürzten Datenbankserver zusammengefügt werden und nicht Protokolle von allen Datenbankservern. Dadurch ist der Umfang der Arbeit, welche für das Wiederherstellen benötigt wird, proportional zu dem Ausmaß des Absturzes und nicht zu der Größe der gesamten Konfiguration.
In Systemen, in denen es möglich ist, zu bestimmen, welche abgestürzten Datenbankserver die Ressource aktualisiert haben, müssen nur die Protokolle der abgestürzten Datenbankserver, welche die Ressource aktualisiert haben, zusammengefügt und angewandt werden. Gleichermaßen braucht in Systemen, in denen es möglich ist, zu bestimmen, welche der abgestürzten Datenbankservern die Ressource nach der dauerhaft gespeicherten Version der Ressource aktualisiert haben, nur die Protokolle der abgestürzten Datenbankserver, welche die Ressource nach der dauerhaft gespeicherten Version der Ressource aktualisiert haben, zusammengefügt und angewandt werden.

Exemplarische Operation

Zum Zwecke der Erläuterung soll im Bezug auf Fig. 1 eine exemplarische Serie von Ressourcen Übertragungen beschrieben werden. Während der Serie von Übertragungen wird an vielen Datenbankservern auf eine Ressource zugegriffen. Insbesondere wird die Ressource zum Modifizieren entlang eines Clusterknotens verschickt und dann verursacht ein Prüfpunkt an einem der Datenbankserver einen physischen E/A dieser Ressource.
Wieder auf die Fig. 1 bezugnehmend gibt es vier Datenbankserver: A, B, C und D. Datenbankserver D ist der Hauptserver der Ressource. Datenbankserver C modifiziert die Ressource zuerst. Datenbankserver C hat die Ressourcen Version 8. An diesem Punkt, hat Datenbankserver C auch eine M-Sperre (ein exklusives Modifikationsrecht) an dieser Ressource.
Angenommen, dass zu diesem Punkt Datenbankserver B die Ressource, welche derzeit Datenbankserver C hält, modifizieren möchte. Datenbankserver B sendet eine Anforderung (1) für eine M-Sperre an der Ressource. Datenbankserver D reiht die Anforderung in eine Modifizierer-Warteschlange ein, welche mit der Ressource assoziiert ist, und instruiert (Nachricht 2: BAST) Datenbankserver C zum:
(a) Weiterreichen der Modifikations-Genehmigung (M- Sperre) an Datenbankserver B,
(b) Senden des aktuellen Abbildes der Ressource an Datenbankserver B, und
(c) Herabsetzen der M-Sperre des Datenbankservers C auf eine H-Sperre
Nach dieser Herabsetzungs-Operation ist C verpflichtet seine Version der Ressource (die PI-Kopie) in seinem Puffer- Zwischenspeicher zu halten.
Datenbankserver C führt die angeforderten Operationen durch und kann zusätzlich das Log (die Sperre?)an die neuen Änderungen erzwingen. Zusätzlich benachrichtigt Datenbankserver C "träge" (3 AckM) den Hauptserver, dass er die Operationen (AST) durchgeführt hat. Die Benachrichtigung informiert den Hauptserver auch, dass Datenbankserver C die Version 8 hält. Datenbankserver C wartet nicht auf irgendeine Bestätigung vom Hauptserver. Als Konsequenz daraus ist es möglich, dass Datenbankserver B eine M-Sperre erhält, bevor der Hauptserver davon weis.
Indessen angenommen, dass Datenbankserver A auch entscheidet die Ressource zu modifizieren. Datenbankserver A sendet eine Nachricht (4) zu Datenbankserver D. Diese Nachricht kann vor der asynchronen Benachrichtigung vom Datenbankserver C bei Datenbankserver D ankommen.
Datenbankserver D (der Hauptserver) sendet eine Nachricht (5) zu Datenbankserver B den letzten bekannten Modifizierer dieser Ressource, die Ressource (nachdem B sie bekommen und modifiziert hat) an Datenbankserver A weiterzureichen. Zu beachten ist, dass Datenbankserver D nicht weis ob die Ressource dort ist oder noch nicht. Aber Datenbankserver D weis, dass die Ressource schließlich bei B ankommen wird.
Nachdem Datenbankserver B die Ressource bekommen hat und die beabsichtigten Änderungen gemacht hat (jetzt hat B die Version 9 der Ressource), setzt er seine eigene Sperre auf H herab, sendet (6) gemeinsam mit der M-Sperre die aktuelle Version der Ressource ("CURR-Ressource") zu Datenbankserver A.
Datenbankserver B sendet auch eine träge Benachrichtigung (6 AckM) an den Hauptserver.
Während die Ressource im Datenbankserver A modifiziert wird, nimm an dass ein Prüfpunktmechanismus an Datenbankserver C entscheidet, die Ressource auf Platte zu schreiben. Hinsichtlich der oben beschriebenen asynchronen Ereignisse, nimm an, dass 3AckM und 6AckM schon beim Hauptserver angekommen sind. Die Operationen, welche in Antwort auf die mit Prüfpunkt versehende Operation ausgeführt werden, werden unter Bezug auf Fig. 5 erläutert.
Bezugnehmend auf Fig. 5 sendet, weil der Datenbankserver C eine H-Sperre, welche kein Schreibprivileg beinhaltet, auf Version 8 hält, Datenbankserver C Nachricht 1 an den Hauptserver (D), womit er die W- (Schreib-) Sperre für seine Version anfordert. Zu diesen Zeitpunkt, weis der Hauptserver, dass die Ressource zu Datenbankserver A geschickt wurde (angenommen, dass die Benachrichtigung angekommen ist). Datenbankserver D sendet eine (unaufgeforderte) W-Sperre an Datenbankserver A (2 BastW) mit der Instruktion die Ressource zu schreiben.
Im allgemeinen Fall, wird diese Instruktion zu dem letzten Datenbankserver gesendet, dessen gesendete Benachrichtigung angekommen ist (oder zu dem Datenbankserver, welcher die Ressource vom letzten bekannten Sender erhalten soll).
Datenbankserver A schreibt (3) seine Version der Ressource. Die Ressource, welche vom Datenbankserver A geschrieben wird, ist Version 10 der Ressource. Zu dieser Zeit kann, wenn zusätzliche Anforderer die Ressource verlangt haben, die aktuelle Kopie der Ressource irgendwo anders sein. Die Platte bestätigt, wenn das Schreiben komplettiert ist (4Ack).
Wenn das Schreiben komplettiert ist, versorgt Datenbankserver A Datenbankserver D mit der Information, dass Version 10 jetzt auf Platte ist (5 AckW). Datenbankserver A setzt freiwillig seine W-Sperre herab (wofür er nicht zuerst um Erlaubnis fragt).
Der Hauptserver (D) geht zum Datenbankserver C und, anstelle des Erteilens der angeforderten W-Sperre, benachrichtigt C, dass das Schreiben komplettiert ist (6). Der Hauptserver teilt die aktuelle Versions-Nummer auf der Platte an die Halter aller PI-Kopien mit, so dass alle früheren PI-Kopien auf C freigegeben werden können. In diesem Szenario setzt es, da Datenbankserver C keine PI-Kopien älter als 10 hat, die Sperre des Datenbankservers C auf NULL.
Der Hauptserver sendet auch eine Bestätigungsnachricht zu Datenbankserver B, wobei er Datenbankserver B instruiert seine PI-Versionen, welche früher als 10 sind, freizugeben (7AckW(10)).

Der Verteilte-Sperrmanager

Im Gegensatz zur konventioneller DLM Logik, kann der Hauptserver in einem System, welches die Direkt- Verschickungstechniken, welche hierin beschrieben sind, realisiert, unvollständige Informationen über die Zustände der Sperren an den Datenbankservern haben. Gemäß einem Ausführungsbeispiel unterhält der Hauptserver einer Ressource die folgenden Informationen und Datenstrukturen:
(1) eine Warteschlange von CURR-Kopien Anforderern (entweder für Modifikationen oder für gemeinsamen Zugriff) (die obere Grenze der Warteschlangenlänge ist die Anzahl der Datenbankserver im Cluster). Diese Warteschlange wird hierin als Aktuelle-Anforderungs-Warteschlange (CQ) bezeichnet.
(2) wenn eine Ressource an einen anderen CURR Anforderer gesendet wird, benachrichtigen die Sender träge (asynchron im Sinne, dass diese nicht auf eine Bestätigung warten) den Hauptserver über das Ereignis. Der Hauptserver führt Buch über die letzten paar Sender. Dies ist ein Pointer auf die CQ.
(3) Die Versionsnummer der letzten Ressourcenversion auf Platte.
(4) W-Sperren Erteilungen und eine W-Anforderungs- Warteschlange. Gemäß einem Ausführungsbeispiel ist W- Genehmigung synchron: sie wird nur vom Hauptserver erteilt und der Hauptserver stellt sicher, dass es für diese Ressource nicht mehr als einen Schreiber in dem Cluster gibt. Der Hauptserver kann die nächste Erteilung nur machen, nachdem er benachrichtigt wurde, dass das vorherige Schreiben komplettiert und die W-Sperre freigegeben wurde. Wenn es mehr als einen Modifizierer gibt, wird eine W-Sperre für die Zeitdauer des Schreibens gegeben und freiwillig nach dem Schreiben freigegeben. Wenn da nur ein Modifizierer ist, kann der Modifizierer die W-Genehmigung behalten.
(5) eine Liste von H-Sperren Haltern mit deren entsprechenden Ressourcen Versions-Nummern. Dies stellt Informationen (obgleich Möglicherweise unvollständig) über die PI-Kopien in Puffer-Zwischenspeichern bereit.

Plattenerneuern

Da die direkten Verschickungstechniken, welche hierin beschrieben sind, signifikant die Lebensdauern der Puffer- Zwischenspeicher-Abbilder der Ressourcen und der Platten- Abbilder trennt, gibt es eine Notwendigkeit diese Wiederherstellungslücke zu überbrücken. Gemäß einem Ausführungsbeispiel wird ein neuer Schritt von Wiederherstellung zwischen DLM-Wiederherstellung und Puffer- Zwischenspeicher-Wiederherstellung hinzugefügt. Dieser neue Wiederherstellungsschritt wird hierein als "Plattenerneuern" bezeichnet.
Obwohl während normaler Zwischenspeicher-Operationen ein Hauptserver einer Ressource nur ungefähres Wissen über den Ort der Ressource und über die Verfügbarkeit von PI- und CURR- Kopien hat, sammelt bei DLM-Wiederherstellung (welche Zwischenspeicher-Wiederherstellung vorangeht) der Hauptserver einer Ressource komplette Informationen über die Verfügbarkeit der letzten PI- und CURR-Kopien in den Puffer- Zwischenspeichern überlebender Datenbankserver. Dies gilt egal ob der Hauptserver der Ressource ein neuer Hauptserver (wenn vor dem Absturz die Ressource von einem abgestürzten Datenbankserver gehandhabt wurde) oder ein überlebender Hauptserver ist.
Nach Sammeln dieser Informationen, weis der Hauptserver, welcher Datenbankserver die letzte Kopie der Ressource besitzt. Zum Stadium des "Plattenerneuerns", gibt der Hauptserver eine W-Sperre an den Besitzer dieser letzten Kopie der Ressource heraus (CURR wenn sie verfügbar ist und letzte PI-Kopie wenn die CURR-Kopie zusammen mit dem abgestürzten Datenbankserver verschwunden ist). Der Hauptserver instruiert dann diesen Datenbankserver die Ressource auf Platte zu schreiben. Wenn das Schreiben komplettiert, wandeln alle anderen Datenbankserver ihre H-Sperren in NULL-Sperren um (weil die geschriebene Kopie die Neueste verfügbare ist). Nachdem diese Sperren umgewandelt wurden, kann Zwischenspeicher-Wiederherstellung wie normal weitergehen.
Einige Optimierungen sind während des Stadiums des Plattenerneuerns möglich. Zum Beispiel muss die Ressource nicht Notwendigerweise auf Platte geschrieben werden, wenn das letzte Abbild in dem Puffer-Zwischenspeicher des Datenbankservers ist, welcher das Wiederherstellen durchführt.

Alternativen zu Sperren-basierten Schemen

Verschiedenartige Techniken für direktes Verschicken unreiner Kopien von Ressourcen zwischen Datenbankservern wurden im Zusammenhang mit einem Sperrenschema beschrieben, welches spezielle Typen von Sperren (M-, W-, und H-Sperren) verwendet. Insbesondere werden diese Spezialsperren verwendet, um sicherzustellen, dass (1) nur der Server mit der aktuellen Version der Ressource die Ressource modifiziert, (2) alle Server ihre PI-Versionen der Ressource halten bis dieselbe Version oder eine neuere Version der Ressource auf Platte geschrieben ist und (3) die plattenresidente Version der Ressource nicht von einer älteren Version der Ressource überschrieben wird.
Jedoch ist das sperrenbasierte Zugriffs-Steuerschema bloß ein Kontext, in welchem die Erfindung realisiert werden kann. Zum Beispiel können dieselben drei Regeln mittels irgendeiner Variation von Zugriffs-Steuerungsschemen durchgesetzt werden. Daher ist die Erfindung nicht auf irgendein besonderes Zugriffs-Steuerungsschema beschränkt.
Zum Beispiel kann Zugriff, eher als durch ein auf Sperren basierenden Verwalten des Zugriffes auf eine Ressource, mittels Marken verwaltet werden, wo jede Marke einen besonderen Typ von Genehmigung repräsentiert. Die Marken für eine bestimmte Ressource kann zwischen den Parallel-Servern in einer Weise übertragen werden, welche sicherstellt, dass die drei oben gegebenen Regeln durchgesetzt werden.
Gleichermaßen können die Regeln mittels Verwendens eines Zustands-basierten Schemas durchgesetzt werden. In einem Zustands-basierten Schema ändert eine Version einer Ressource den Zustand als Antwort auf Ereignisse, wobei der Zustand einer Version den Typ von Aktionen diktiert, welche an dieser Version durchgeführt werden können. Zum Beispiel empfängt ein Datenbankserver die aktuelle Version einer Ressource in ihrem "aktuellen" Zustand. Der aktuelle Zustand erlaubt Modifikation der Ressource und auf Platte schreiben der Ressource. Wenn ein Datenbankserver die aktuelle Version der Ressource zu einem anderen Knoten überträgt, ändert sich die gehaltene Version in einen "PI schreibbaren" Zustand. In dem PI schreibbaren Zustand kann die Version (1) nicht modifiziert werden, (2) kann nicht überschrieben werden aber (3) kann auf Platte geschrieben werden. Wenn irgendeine Version der Ressource auf Platte geschrieben wird, werden alle Versionen, welche in einem PI schreibbaren Zustand sind, welche gleich oder älter als die Version ist, welche auf Platte geschrieben wurde, in einem "PI freigegebenen" Zustand gesetzt. In dem PI freigegebenen Zustand können Versionen überschrieben werden, aber können nicht modifiziert oder auf Platte geschrieben werden.

Hardwareübersicht

Fig. 6 ist ein Blockdiagramm, welches ein Computersystem 600 erläutert, auf welchem ein Ausführungsbeispiel der Erfindung realisiert werden kann. Computersystem 600 enthält einen Bus 602 oder anderen Kommunikationsmechanismus zum Kommunizieren von Information und einen Prozessor 604, welcher zum Prozessieren von Informationen mit Bus 602 gekoppelt ist. Computersystem 600 weist auch einen Hauptspeicher 606, wie zum Beispiel einen Direktzugriffspeicher (RAM) oder eine andere mit dem Bus 602 gekoppelte dynamische Speichervorrichtung auf, zum Speichern von Informationen und Instruktionen, welche mittels des Prozessors 604 ausgeführt werden müssen. Hauptspeicher 606 kann auch zum zeitweiligen Speichern von Variablen oder anderen Zwischeninformationen während des Ausführens von Instruktionen verwendet werden, welche mittels des Prozessors 604 ausgeführt werden müssen. Computersystem 600 enthält ferner einen Festwertspeicher (ROM) 608 oder eine andere mit Bus 602 gekoppelte statische Speichervorrichtung zum Speichern statischer Informationen und Instruktionen für den Prozessor 604. Eine Speichervorrichtung 610, wie zum Beispiel eine Magnetplatte oder optische Platte ist bereitgestellt und mit dem Bus 602 gekoppelt, zum Speichern von Informationen und Instruktionen.
Computersystem 600 kann zum Anzeigen von Informationen für einen Benutzer mittels Bus 602 mit einer Anzeige 612, wie zum Beispiel einer Kathodenstrahlröhre (CRT), gekoppelt werden. Eine Eingabevorrichtung 614, welche alphanumerische und andere Tasten aufweist, ist zum Kommunizieren von Informationen und Befehlsauswahlen an den Prozessor 604, an den Bus 602 gekoppelt. Eine andere Art von Benutzer-Eingabevorrichtung, zum Kommunizieren von Richtungsinformationen und Befehlsauswahlen an den Prozessor 604 und zum Steuern von der Kursorbewegung auf Display 612, ist Kursorsteuerung 616 wie zum Beispiel eine Maus, ein Trackball oder Kursor-Richtungs- Tasten. Diese Eingabevorrichtung hat typischerweise zwei Freiheitsgrade entlang zweier Achsen, einer ersten Achse (z. B. X) und einer zweiten Achse (z. B. Y), welches der Vorrichtung erlaubt, Positionen in einer Ebene zu spezifizieren.
Die Erfindung betrifft das Benutzen eines Computersystems 600 zum Reduzieren des Overheads, welcher mit einem Ping assoziiert ist. Gemäß einem Ausführungsbeispiel der Erfindung wird der mit einem Ping assoziierte Overhead, mittels Computersystem 600 in Antwort auf das Ausführen einer oder mehrerer Sequenzen einer oder mehrerer Instruktionen, welche im Hauptspeicher 606 enthalten sind, des Prozessor 604, reduziert. Solche Instruktionen können von einem anderen computerlesbaren Medium, wie zum Beispiel Speichervorrichtung 610, in den Hauptspeicher 606 eingelesen werden. Ausführen der Sequenzen von Instruktionen, welche im Hauptspeicher 606 enthalten sind, veranlassen Prozessor 604 die Prozessschritte, welche hierin beschrieben sind, auszuführen. In alternativen Ausführungsbeispielen können hartverdrahtete Schaltkreise anstelle von oder in Kombination mit Softwareinstruktionen verwendet werden, um die Erfindung zu realisieren. Daher sind die Ausführungsbeispiele der Erfindung nicht auf irgendeine spezifische Kombination von Hardware-Schaltkreisen und Software begrenzt.
Der Ausdruck "Computerlesbares Medium" wie er hierin verwendet wird, bezieht sich auf jedes Medium, welches am Bereitstellen von Instruktionen zum Ausführen an den Prozessor 604 teilnimmt. Solch ein Medium kann viele Formen haben, welche einschließen aber nicht begrenzt sind auf, nichtflüchtige Medien, flüchtige Medien und Übertragungsmedien. Nichtflüchtige Medien schließen zum Beispiel optische oder magnetische Platten wie z. B. Speichervorrichtung 610 ein. Flüchtige Medien schließen dynamische Speicher, wie zum Beispiel Hauptspeicher 606 ein. Übertragungsmedien schließen Koaxialkabel, Kupferkabel und Lichtwellenleiter, inklusive der Kabel, welche Bus 602 aufweist, ein. Übertragungsmedien können ferner die Form von akustischen oder Lichtwellen annehmen, wie zum Beispiel solche, welche während Radiowellen- und Infrarot- Datenkommunikationen erzeugt werden.
Übliche Formen von Computerlesbaren Medien schließen zum Beispiel eine Diskette, eine Diskette, Festplatte, Magnetband oder jedes andere magnetische Medium, eine CD-ROM, jedes andere optische Medium, Lochkarten, Lochstreifen, jedes andere physische Medium mit einem Muster von Löchern, eine RAM, eine PROM und EPROM, eine FLASH-EPROM, jeden anderen Speicherchip oder Speicherkassette, eine Trägerwelle wie nachfolgend hierin beschrieben oder jedes andere Medium, von welchem ein Computer lesen kann, ein.
Verschiedenartige Formen von computerlesbaren Medien können in das Tragen einer oder mehrerer Sequenzen von einer oder mehrerer Instruktionen zum Prozessor 604 zum Ausführen einbezogen sein. Zum Beispiel können die Instruktionen anfänglich auf einer Magnetplatte eines entfernten Computers gespeichert sein. Der entfernte Computer kann die Instruktionen in seinen dynamischen Speicher laden und die Instruktionen mittels Verwendens eines Modems über eine Telefonleitung versenden. Ein Modem am Ort des Computersystems 600 kann die Daten über die Telefonleitung empfangen und einen Infrarot-Transmitter verwenden, um die Daten in ein Infrarotsignal umzuwandeln. Ein Infrarotdetektor kann die Daten, welche in dem Infrarotsignal enthalten sind, empfangen und ein passender Schaltkreis kann die Daten in den Bus 602 platzieren. Bus 602 trägt die Daten zum Hauptspeicher 606, von welchem Prozessor 604 die Instruktionen empfängt und ausführt. Die mittels des Hauptspeichers 606 empfangenen Instruktionen können, entweder vor oder nach dem Ausführen mittels des Prozessors 604 optional in einer Speichervorrichtung 610, gespeichert werden.
Computersystem 600 gehört zu einem Gemeinschafts- Plattensystem, in welchem Daten eines oder mehrerer Speichervorrichtungen (z. B. Plattenlaufwerken 655) für beide, Computersystem 600 und für eine oder mehrere CPUs (z. B. CPU 651), zugreifbar sind. In dem erläuterten System wird Gemeinschaftszugriff zu den Plattenlaufwerken 655 mittels eines Systemnetz-Bereiches 653 bereitgestellt. Jedoch können verschiedenartige Mechanismen alternativ genutzt werden, um Gemeinschaftszugriff bereitzustellen.
Computersystem 600 weist auch eine an den Bus 602 gekoppelte Kommunikations-Schnittstelle 618 auf. Kommunikations- Schnittstelle 618 stellt eine wechselseitige Daten- Kommunikationskopplung zu einer Netzwerk-Verbindung 620 bereit, welche mit einem lokalen Netzwerk 622 gekoppelt ist. Zum Beispiel kann Kommunikations-Schnittstelle 618 eine dienstintegrierendes-digitales-Nachrichtennetz- (ISDN) Karte oder ein Modem sein, um eine Datenkommunikationsverbindung zu einer entsprechenden Art von Telephonleitung bereitzustellen. Als ein anderes Beispiel kann Kommunikations-Schnittstelle 618 eine Lokales-Datennetz- (LAN) Karte sein, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN bereitzustellen. Ferner können drahtlose Verbindungen realisiert werden. In einer solchen Realisierung, sendet und empfängt Kommunikations-Schnittstelle 618 elektrische, elektromagnetische oder optische Signale, welche digitale Datenströme tragen, welche verschiedenartige Typen von Informationen repräsentieren.
Die Netzwerk-Verbindung 620 stellt typischerweise mittels eines oder mehrerer Netzwerke Datenkommunikation zu anderen Datenvorrichtungen bereit. Zum Beispiel kann Netzwerk- Verbindung 620 mittels lokalen Netzwerks 622 eine Verbindung zu einem Zentralrechner 624 oder zu Datenvorrichtungen, welche von einem Internet-Service-Provider (ISP) 626 betrieben werden, bereit. Im Gegenzug stellt ISP 626 Datenkommunikationsservices mittels des Weltweiten-Datenpaket- Kommunikations-Netzwerkes, jetzt gemeinhin als "Internet" 628 bezeichnet, bereit. Lokales Netzwerk 622 und Internet 628 nutzen beide elektrische, elektromagnetische oder optische Signale, welche digitale Datenströme tragen. Die Signale durch die verschiedenartigen Netzwerke und die Signale auf der Netzwerk-Verbindung 620 und durch Kommunikations-Schnittstelle 618, welche die digitalen Daten zu und weg vom Computersystem 600 tragen, sind exemplarisch als Trägerwellen ausgebildet, welche die Informationen tragen.
Computersystem 600 kann mittels des/der Netzwerk(e), Netzwerk- Verbindung 620 und Kommunikations-Schnittstelle 618 Nachrichten senden und Daten, inklusive Programmcode, empfangen. In dem Internetbeispiel kann ein Server 630 mittels Internet 628, ISP 626, lokales Netzwerk 622 und Kommunikations-Schnittstelle 618 einen angeforderten Code für ein Anwendungsprogramm übertragen.
Der empfangene Code kann mittels des Prozessors 604 so wie er empfangen wurde, ausgeführt werden, und/oder in Speichervorrichtung 610 oder anderen nichtflüchtigen Speichern zum späteren Ausführen gespeichert werden. Auf diese Weise kann Computersystem 600 Anwendungscode in Form einer Trägerwelle erhalten.
Während Techniken zum Handhaben von Pings hierin in Bezug auf Pings beschrieben wurden, welche auftreten, wenn Mehrfach- Datenbankserver auf eine gemeinsame, dauerhafte Speichervorrichtung Zugriff haben, sind diese Techniken nicht auf diesen Kontext beschränkt. Insbesondere können diese Techniken in jedem Umfeld angewandt werden, in welchem ein Prozess, welcher mit einem Zwischenspeicher assoziiert ist, eine Ressource anfordert, deren aktuelle Version sich in einem anderen Zwischenspeicher befindet. Solche Umfelder schließen zum Beispiel Umfelder, in welchen Textserver an verschiedenen Knoten zu dem selben Textmaterial Zugriff haben, Umfelder, in welchen Medienserver an verschiedenen Knoten Zugriff zu den selben Videodaten (Bilddaten) haben, usw. ein.
Handhaben von Pings mittels der hierin beschriebenen Techniken, stellt effektives Zwischen-Datenbankserver- Übertragen von Ressourcen bereit, so dass die Betriebszeit- Leistungsfähigkeit gut mit der ansteigenden Anzahl von Datenbankservern und Benutzern je Datenbankserver skaliert. Zusätzlich laufen die Techniken auf eine effiziente Wiederherstellung von Einzel-Datenbankserver-Abstürzen (dem häufigsten Typ von Abstürzen) heraus, welches gut mit der anwachsenden Zahl von Datenbankservern skaliert.
Signifikanterweise handhaben die hierin beschriebenen Techniken Pings mittels Sendens von Ressourcen über den IPC Transport und nicht mittels Platten-Intervention. Folglich sind Platten E/As für Ressourcen, welche in einem Ping enden, im Wesentlichen beseitigt. Ein synchroner E/A ist nur so lange involviert, wie er für das Erzwingen des Logs nötig ist. Zusätzlich verlangsamen solche E/A nicht das Puffer- Verschicken quer durch das Cluster, während durch Setzen von Prüfpunkten und Setzen von Puffer-Zwischenspeichern Plätten E/A auftritt.
Die direkten Verschickungstechniken, welche hierin beschrieben wurden tendieren auch dazu die Anzahl von Kontext- Umschaltungen, welche durch ein Ping auftreten, zu reduzieren. Insbesondere wird die Sequenz von Schleifen-Nachrichten zwischen den Teilnehmern des Protokolls (Anforderer und Halter) und dem Hauptserver mittels des Kommunikationsdreiecks ersetzt: Anforderer, Hauptserver, Halter, Anforderer.

Claims

1. Verfahren zum Übertragen einer Ressource von einem ersten Zwischenspeicher zu einem zweiten Zwischenspeicher, aufweisend die Schritte:

Beibehalten einer ersten Kopie (8, 9) der Ressource in dem ersten Zwischenspeicher während des Übertragens einer zweiten Kopie (9, 10) der Ressource von dem ersten Zwischenspeicher zu dem zweiten Zwischenspeicher, ohne die Ressource von dem ersten Zwischenspeicher vorher dauerhaft in einen persistenten Speicher zu speichern; und

Verhindern, dass die erste Kopie (8, 9) in dem ersten Zwischenspeicher ersetzt wird, bis die erste Kopie (8, 9) der Ressource oder ein Versionsnachfolger von ihr dauerhaft gespeichert ist.

2. Verfahren gemäß Anspruch 1, wobei der erste Zwischenspeicher ein Zwischenspeicher ist, der von einem ersten Datenbankserver (A, B, C) aufrechterhalten wird, und der zweite Zwischenspeicher ein Zwischenspeicher ist, der von einem zweiten Datenbankserver (A, B, C) aufrechterhalten wird.

3. Verfahren gemäß Anspruch 1, ferner aufweisend die Schritte:

Ermöglichen, dass die erste Kopie (8, 9) der Ressource in dem ersten Zwischenspeicher verändert wird, bevor die zweite Kopie (9, 10) zu dem zweiten Zwischenspeicher übertragen wird; und

Verhindern, dass die erste Kopie (8, 9) der Ressource verändert wird, nachdem die zweite Kopie (9, 10) zu dem zweiten Zwischenspeicher übertragen worden ist.

4. Verfahren gemäß Anspruch 1, ferner aufweisend die Schritte:

Senden einer Anforderung für die Genehmigung, die erste Kopie (8, 9) freizugeben, nachdem die zweite Kopie (9, 10) zu dem zweiten Zwischenspeicher übertragen worden ist;

Veranlassen, dass die erste Kopie (8, 9) oder ein Versionsnachfolger von ihr als Antwort auf die Anforderung dauerhaft gespeichert wird; und

Senden einer Nachricht, die anzeigt, dass die erste Kopie (8, 9) freigegeben werden kann, als Antwort darauf, dass der Versionsnachfolger dauerhaft gespeichert ist.

5. Verfahren gemäß Anspruch 4, wobei:

der Schritt des Sendens einer Anforderung für die Genehmigung zum Freigeben der ersten Kopie (8, 9) mittels eines sendenden Prozesses durchgeführt wird; und

der Schritt des Auslösens, dass die erste Kopie (8, 9) oder ein Versionsnachfolger von ihr dauerhaft gespeichert wird, den Schritt des Auslösens eines Prozesses, ein anderer als der sendende Prozess, zum Speichern eines Versionsnachfolgers der ersten Kopie (8, 9) der Ressource beinhaltet.

6. Verfahren gemäß Anspruch 1, wobei der Schritt des Verhinderns, dass die erste Kopie ersetzt wird, die Schritte aufweist:

Ermitteln, ob eine dauerhaft gespeicherte Kopie der Ressource neuer als die erste Kopie (8, 9) ist, bevor die erste Kopie (8, 9) dauerhaft gespeichert wird;

Freigeben der ersten Kopie (8, 9) ohne dauerhaftes Speichern der ersten Kopie (8, 9), wenn die dauerhaft gespeicherte Kopie neuer als die erste Kopie ist (8, 9) ist;

dauerhaftes Speichern der ersten Kopie (8, 9), wenn die dauerhaft gespeicherte Kopie nicht neuer als die erste Kopie (8, 9) ist.

7. Verfahren gemäß Anspruch 3, das ferner aufweist den Schritt des Übertragens einer Änderungsgenehmigung zusammen mit der zweiten Kopie (9, 10) der Ressource von einem sendenden Prozess, der in Verbindung mit dem ersten Zwischenspeicher steht, zu einem empfangenden Prozess, der in Verbindung mit dem zweiten Zwischenspeicher steht.

8. Verfahren gemäß Anspruch 7, wobei:

die Genehmigungen für das Zugreifen auf die Ressource mittels eines Hauptservers (D) geregelt werden; und

der Schritt des Übertragens der Änderungsgenehmigung zu dem empfangenden Prozess vor dem Empfangen der Bestätigung von dem Hauptserver (D) für die Übertragung der Änderungsgenehmigung zu dem empfangenden Prozess durchgeführt wird.

9. Verfahren des Anspruches 1, ferner aufweisend die Schritte:

ein empfangender Prozess, der in Verbindung mit dem zweiten Zwischenspeicher steht, sendet eine Anforderung für die Ressource an einen Hauptserver (D) der Ressource;

der Hauptserver (D) der Ressource sendet als Antwort auf die Anforderung des empfangenden Prozesses eine Nachricht zu einem sendenden Prozess, der in Verbindung mit dem ersten Zwischenspeicher steht; und

der sendende Prozess überträgt die zweite Kopie (9, 10) zu dem empfangenden Prozess als Antwort auf die Nachricht von dem Hauptserver (D).

10. Verfahren gemäß Anspruch 1, das ferner nach dem Schritt der Übertragung der zweiten Kopie (9, 10) zu dem zweiten Zwischenspeichers die Ausführung der folgenden Schritte aufweist:

ein sendender Prozess, der in Verbindung mit dem ersten Zwischenspeicher steht, fordert der eine Sperre von einem Sperrmanager an, wobei die Sperre die Genehmigung zum Schreiben der Ressource auf die Platte erteilt, aber nicht die Genehmigung zur Änderung der Ressource;

der Sperrmanager wählt einen Prozess aus, der eine Version, das heißt zumindest eine neuere als die erste Kopie (8, 9), der Ressource besitzt;

der Sperrmanager erteilt dem ausgewählten Prozess eine Sperre; und

der selektierte Prozess schreibt die Version der Ressource auf die Platte.

11. Verfahren gemäß Anspruch 10, ferner aufweisend den Schritt, dass der Sperrmanager als Antwort auf die Version der Ressource, die auf die Platte geschrieben wurde, veranlasst, dass alle Versionen der Ressource, die älter als die Version sind, freigegeben werden.

12. Verfahren gemäß Anspruch 1, ferner, nachdem ein Fehler eines Zwischenspeichers aufgetreten ist, der eine fehlerhafte Kopie der Ressource enthält, aufweisend die Schritte:

Ermitteln, ob der fehlerhafte Zwischenspeicher die letzte Version der Ressource hielt;

wenn der fehlerhafte Zwischenspeicher die letzte Version der Ressource hielt, dann:

Schreiben eines letzten früheren Abbildes der Ressource auf die Platte;

Freigeben aller vorherigen früheren Abbilder der Ressource; und

Anwenden eines Wiederherstellungsprotokolls des fehlerhaften Zwischenspeichers, zum Rekonstruieren der letzten Version der Ressource.

13. Verfahren gemäß Anspruch 12, ferner aufweisend die Schritte:

wenn der fehlerhafte Zwischenspeicher nicht die letzte Version der Ressource hielt, dann

Schreiben der letzten Version der Ressource auf die Platte; und

Freigeben aller früheren Abbilder der Ressource.

14. Verfahren gemäß Anspruch 1, ferner, nachdem ein Fehler bei einer Vielzahl von Zwischenspeichern auftrat, die fehlerhafte Versionen der Ressource enthalten, aufweisend die Schritte:

Ermitteln, ob einer der fehlerhaften Zwischenspeicher die letzte Version der Ressource hielt; und

wenn einer der fehlerhaften Zwischenspeicher die letzte Version der Ressource hielt, dann:

Zusammenführen und Anwenden der Wiederherstellungsprotokolle der fehlerhaften Zwischenspeicher, zum Rekonstruieren der letzten Version der Ressource.

15. Computerlesbares Medium, das eine oder mehrere Sequenzen von Befehlen für die Übertragung einer Ressource von einem ersten Zwischenspeicher zu einem zweiten Zwischenspeicher enthält, wobei die Ausführung der einen oder mehrerer Sequenzen der Befehle mittels eines oder mehrerer Prozessoren den oder die Prozessoren veranlasst, die folgenden Schritte durchzuführen:

Beibehalten einer ersten Kopie (8, 9) der Ressource in dem ersten Zwischenspeicher, während des Übertragens einer zweiten Kopie (9, 10) der Ressource von dem ersten Zwischenspeicher zu dem zweiten Zwischenspeicher, ohne zuerst die Ressource von dem ersten Zwischenspeicher in einen persistenten Speicher dauerhaft zu speichern; und

16. Computerlesbares Medium gemäß Anspruch 15, das ferner Sequenzen von Befehlen aufweist zum Durchführen der Schritte:

Ermöglichen des Änderns der ersten Kopie (8, 9) der Ressource in dem ersten Zwischenspeicher, vor dem Übertragen der zweiten Kopie (9, 10) zu dem zweiten Zwischenspeichers; und

Verhindern, dass die erste Kopie (8, 9) der Ressource nach der Übertragung der zweiten Kopie (9, 10) zu dem zweiten Zwischenspeicher verändert wird.

17. Computerlesbares Medium gemäß Anspruch 15, das ferner Sequenzen von Befehlen aufweist zum Durchführen der Schritte:

Senden einer Anforderung für die Genehmigung zur Freigabe der ersten Kopie (8, 9), nach dem Übertragen der zweiten Kopie (9, 10) zu dem zweiten Zwischenspeicher;

Veranlassen der ersten Kopie (8, 9) oder eines Versionsnachfolgers von ihr als Antwort auf die Anforderung, dauerhaft gespeichert zu werden; und

Senden einer Nachricht als Antwort auf die dauerhafte Speicherung des Versionsnachfolgers, die anzeigt, dass die erste Kopie (8, 9) ersetzt werden kann.

18. Computerlesbares Medium gemäß Anspruch 17, wobei:

der Schritt des Sendens einer Anforderung für die Genehmigung zur Freigabe der ersten Kopie (8, 9), der von einem sendenden Prozess durchgeführt wird; und

der Schritt des Veranlassens, dass die erste Kopie (8, 9) oder ein Versionsnachfolger von ihr dauerhaft gespeichert wird, den Schritt aufweist, einen anderen als den sendenden Prozess zu veranlassen, einen Versionsnachfolger der ersten Kopie (8, 9) der Ressource zu speichern.

19. Computerlesbares Medium gemäß Anspruch 15, wobei der Schritt des Verhinderns, dass die erste Kopie (8, 9) ersetzt wird, die Schritte aufweist:

Ermitteln, ob eine dauerhaft gespeicherte Kopie der Ressource neuer ist als die erste Kopie (8, 9), bevor versucht wird, die erste Kopie (8, 9) dauerhaft zu speichern;

Freigeben der ersten Kopie (8, 9) ohne dauerhaftes Speichern der ersten Kopie (8, 9), wenn die dauerhaft gespeicherte Kopie der Ressource neuer als die erste Kopie (8, 9) ist; und

dauerhaftes Speichern der ersten Kopie (8, 9), wenn die dauerhaft gespeicherte Kopie der Ressource nicht neuer als die erste Kopie (8, 9) ist.

20. Computerlesbares Medium gemäß Anspruch 16, das ferner Befehle zum Durchführen des Schrittes der Übertragung einer Änderungsgenehmigung zusammen mit der zweiten Kopie der Ressource von einem sendenden Prozess, der in Verbindung mit dem ersten Zwischenspeicher steht, zu einem empfangenden Prozess, der in Verbindung mit dem zweiten Zwischenspeicher steht, aufweist.

21. Computerlesbares Medium gemäß Anspruch 20, wobei:

die Genehmigungen für den Zugriff auf die Ressource mittels eines Hauptservers (D) geregelt werden; und

der Schritt des Übertragens der Änderungsgenehmigung zu dem empfangenden Prozess durchgeführt wird, bevor die Bestätigung von dem Hauptserver (D) für die Übertragung der Änderungsgenehmigung zu dem empfangenden Prozess empfangen wird.

22. Computerlesbares Medium gemäß Anspruch 15, das ferner Sequenzen von Befehlen aufweist zum Durchführen der Schritte:

ein empfangender Prozess, der in Verbindung mit dem zweiten Zwischenspeicher steht, sendet eine Anforderung für die Ressource zu einem Hauptserver (D) der Ressource;

der Hauptserver (D) der Ressource sendet als Antwort auf die Anforderung von dem empfangenden Prozess eine Nachricht zu einem sendenden Prozess, der in Verbindung mit dem ersten Zwischenspeicher steht; und

23. Computerlesbares Medium gemäß Anspruch 15, das ferner Befehle zum Durchführen der folgenden Schritte nach dem Schritt des Übertragens der zweiten Kopie (9, 10) zu dem zweiten Zwischenspeicher:

ein sendender Prozess, der in Verbindung mit dem ersten Zwischenspeicher steht, fordert eine Sperre von einem Sperrmanager an, wobei die Sperre die Genehmigung erteilt, die Ressource auf die Platte zu schreiben, aber nicht die Genehmigung, die Ressource zu ändern;

der Sperrmanager wählt einen Prozess aus, der eine Version der Ressource enthält, die zumindest neuer als die erste Kopie (8, 9) ist;

der Sperrmanager erteilt eine Sperre auf den ausgewählten Prozess; und

der ausgewählte Prozess schreibt die Version der Ressource auf die Platte.

24. Computerlesbares Medium gemäß Anspruch 23, das ferner Befehle zum Durchführen des Schrittes zum Veranlassen des Sperrmanagers aufweist, als Antwort auf die Version der Ressource, die auf die Platte geschrieben wurde, alle Versionen der Ressource, die älter als diese Version sind, freizugeben.

25. Computerlesbares Medium gemäß Anspruch 15, das ferner Sequenzen von Befehlen nach einem Fehler in einem Zwischenspeicher, der eine fehlerhafte Kopie der Ressource hält, aufweist zum Durchführen der Schritte:

Schreiben des letzten früheren Abbilds der Ressource auf die Platte, wenn der fehlerhafte Prozess die letzte Version der Ressource hielt;

Freigeben aller vorherigen früheren Abbilder der Ressource; und

26. Computerlesbares Medium gemäß Anspruch 25, das ferner Sequenzen von Befehlen aufweist zum Durchführen der Schritte:

Schreiben der letzten Version der Ressource auf die Platte; und

Freigeben aller früheren Abbilder der Ressource.

27. Computerlesbares Medium gemäß Anspruch 15, das ferner Sequenzen von Befehlen nach einem Fehler in einer Vielzahl von Zwischenspeichern, die fehlerhafte Versionen der Ressource halten, aufweist zum Durchführen der Schritte:

wenn einer der fehlerhaften Zwischenspeicher die letzte Version der Ressource hielt, dann