DE69929095T2 - Verwaltung eines durch eine Mehrzahl von Knoten benutzten Betriebsmittels - Google Patents

Verwaltung eines durch eine Mehrzahl von Knoten benutzten Betriebsmittels Download PDF

Info

Publication number
DE69929095T2
DE69929095T2 DE69929095T DE69929095T DE69929095T2 DE 69929095 T2 DE69929095 T2 DE 69929095T2 DE 69929095 T DE69929095 T DE 69929095T DE 69929095 T DE69929095 T DE 69929095T DE 69929095 T2 DE69929095 T2 DE 69929095T2
Authority
DE
Germany
Prior art keywords
node
resource
permission
copy
holding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69929095T
Other languages
English (en)
Other versions
DE69929095D1 (de
Inventor
Roger J. Woodside Bamford
Boris Belmont Klots
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle International Corp
Original Assignee
Oracle International Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oracle International Corp filed Critical Oracle International Corp
Publication of DE69929095D1 publication Critical patent/DE69929095D1/de
Application granted granted Critical
Publication of DE69929095T2 publication Critical patent/DE69929095T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80—Database-specific techniques
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/912—Applications of a database
    • Y10S707/913—Multimedia
    • Y10S707/915—Image
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99938—Concurrency, e.g. lock management in shared database
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99953—Recoverability
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99954—Version management

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 so genannte „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 Einzel-Datenbankserver-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 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 beschrieben in dem U.S. Patent 5,832,516 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 beschrieben in dem U.S. Patent 5,596,754 mit dem Titel „Method for Performing Private Lock Management".
  • Das Dokument US-A-5,327,566 lehrt eine schnelle Technik zum Übertragen von Einheiten von Daten zwischen Transaktionssystemen in einer Mehrbenutzer-Platten-Umgebung, wo Zugriff auf die Mehrbenutzer-Ressourcen unter Verwendung eines globalen Lock-Management-Systems in Verbindung mit lokalen Lock-Managern verwaltet wird. Jede Seite ist mit einem bestimmten Signalspeicher verknüpft, welcher individuell für jede Seite den Zugriff zu dieser Seite durch Angabe entweder einer Genehmigung zum gemeinsamen Verwenden oder einer Genehmigung zum ausschließenden Sperren steuert.
  • 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 darauf, 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 Modus zu erlangen.
  • Die Anforderung, welche von dem anfordernden Datenbankserver veranlasst wird, kann mit dem aktuellen Status der Ressource im Konflikt stehen (z.B. könnte es einen anderen Datenbankserver geben, welcher jetzt eine Ausschließlich-Sperre auf die Ressource hält). Wenn es keinen Konflikt gibt, erteilt der Hauptserver der Ressource die Sperre und speichert die Erteilung. Im Falle eines Konflikts 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 wird 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 wird 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 wird angenommen, dass der Datenbankserver A abstürzt. Das Protokoll des Datenbankservers A enthält Datensätze 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 Gesamtanzahl von Datenbankservern, inklusive derer, die nicht abgestürzt sind, benötigen.
  • Der oben beschriebene Platten-Interventions-Ansatz vermeidet das Problem, welches mit dem Zusammenfü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 anschaulich 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
  • Gemäß der Erfindung, welche im Detail in den anhängenden unabhängigen Ansprüchen definiert ist, werden 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, 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 hat (Halter), 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:
  • 1 ein Blockdiagramm ist, welches Zwischenspeicher zu Zwischenspeicher Übertragungen der neuesten Versionen von Ressourcen erläutert;
  • 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;
  • 3 ein Flussdiagramm ist, welches Schritte zum Freigeben früherer Abbilder von Ressourcen gemäß einem Ausführungsbeispiel der Erfindung erläutert;
  • 4 ein Flussdiagramm ist, welches Schritte zum Wiederherstellen nach einem Absturz eines einzelnen Servers gemäß einem Ausführungsbeispiel der Erfindung erläutert;
  • 5 ein Blockdiagramm ist, welches einen Prüfpunkt-Zyklus, gemäß einem Ausführungsbeispiel der Erfindung, erläutert; und
  • 6 ein Blockdiagramm eines Computersystems ist, auf welchem ein Ausführungsbeispiel der Erfindung realisiert werden kann.
  • Detaillierte Beschreibung des bevorzugten Ausführungsbeispiels
  • Es werden 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. In anderen Datenbankservern werden allseits bekannte Strukturen und Vorrichtungen in Blockdiagrammform gezeigt, um unnötiges 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.
  • Zum Zweck der Erläuterung wird eine Kopie einer Ressource, welche im Zwischenspeicher nicht ersetzt werden kann, hierin als eine „festgehaltene" Ressource bezeichnet. Die Handlung, eine festgehaltene Ressource ersetzbar 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 des Verwendens 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.
  • Bezug nehmend auf 2 erläutert sie die Schritte, welche in Antwort auf ein Ping in einem Datenbank-System, welches Mund W-Sperren gemäß einem Ausführungsbeispiel der Erfindung, verwendet, ausgeführt werden. In 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. In 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.
  • In Schritt 204 schickt der Halter die aktuelle Version der Ressource und die M-Sperre zu dem Anforderer. In Schritt 206, informiert der Halter den Hauptserver über die Übertragung der M-Sperre. In 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, PI-Ressourcen auf Platte zu speichern. Eine Technik zum Freigeben von PI-Ressourcen unter diesen Umständen ist in 3 erläutert.
  • Bezugnehmend auf 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 wird 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 1 beschrieben werden soll, realisiert werden Bezug nehmend auf 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 dem dargestellten Zeitpunkt 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 wird 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 einen 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 Versendens 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 wieder verwendet 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ößerem 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, vorausgesetzt, 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 einem 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 Einfluss auf das zweite und dritte Kriterium und umgekehrt. Dadurch ist ein Kompromiss notwendig. Gemäß einem Ausführungsbeispiel der Erfindung kann, gekoppelt mit einer Kontrolle über den gesamten E/A-Haushalt, ein selbst-abgestimmter 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 wieder verwendet 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, wobei die Modi entweder kompatibel sind oder im Konflikt 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ößerem 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 Widerstreit, 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-Benachrichtigungssystem weicht signifikant von der herkömmlichen Zweiweg-Kommunikation ab, bei welcher die Antwort auf eine Sperren-Anforderung von dem Datenbankserver erwartet wird, welche 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 dem 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, weiß der Hauptserver nicht immer das exakte globale Bild der Sperren Erteilungen. Vielmehr weiß 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ührungsbeispiel 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ößerem Detail beschrieben.
  • Absturz-Wiederherstellung
  • Innerhalb der Erfindung wird davon gesprochen, 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ührungsbeispiel werden Einzel-Server-Abstürze wie in 4 erläutert gehandhabt. Bezugnehmend auf 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 durchgeführten Ä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 liegt, 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-Absturzes, 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 brauchen 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.
  • Beispielhafter Betrieb
  • Zum Zwecke der Erläuterung soll im Bezug auf 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 1 Bezug nehmend 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 Protokollieren der 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 weiß.
  • Indessen wird 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 weiß, ob die Ressource dort ist oder noch nicht. Aber Datenbankserver D weiß, 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, wird angenommen, dass ein Prüfpunktmechanismus an Datenbankserver C entscheidet, die Ressource auf Platte zu schreiben. Hinsichtlich der oben beschriebenen asynchronen Ereignisse, wird angenommen, 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 5 erläutert.
  • Bezugnehmend auf 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 weiß 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) richtet sich an den 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-Kopie-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 weiß der Hauptserver, welcher Datenbankserver die letzte Kopie der Ressource besitzt. In dem Zustand 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 ist, 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 Zustands 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 zum Sperren-basierten Schema
  • Verschiedenartige Techniken für direktes Verschicken unreiner Kopien von Ressourcen zwischen Datenbankservern wurden im Zusammenhang mit einem Sperren-Schema 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 Sperren-basierte 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 Markern verwaltet werden, wobei jeder Marker einen besonderen Typ von Genehmigung repräsentiert. Der Marker 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
  • 6 ist ein Blockdiagramm, welches ein Computersystem 600 erläutert, in welchem ein Ausführungsbeispiel der Erfindung realisiert werden kann. Das Computersystem 600 enthält einen Bus 602 oder einen anderen Kommunikationsmechanismus zum Kommunizieren von Information und einen Prozessor 604, welcher zum Prozessieren von Informationen mit dem Bus 602 gekoppelt ist. Das 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. Der 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. Das 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.
  • Das Computersystem 600 kann zum Anzeigen von Informationen für einen Benutzer mittels des 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 einem Display 612, ist eine 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 des Computersystems 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 einer Speichervorrichtung 610, in den Hauptspeicher 606 eingelesen werden. Ausführen der Sequenzen von Instruktionen, welche im Hauptspeicher 606 enthalten sind, veranlassen den Prozessor 604, die Prozessschritte, welche hierin beschrieben sind, auszuführen. In alternativen Ausführungsbeispielen können hart-verdrahtete 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 „Computer-lesbares 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. die Speichervorrichtung 610 ein. Flüchtige Medien schließen dynamische Speicher, wie zum Beispiel den Hauptspeicher 606 ein. Übertragungsmedien schließen Koaxialkabel, Kupferkabel und Lichtwellenleiter, inklusive der Kabel, welche der 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 Computer-lesbaren Medien schließen zum Beispiel eine Floppy-Disk, eine flexible 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 Computer-lesbaren 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 auf den Bus 602 führt. 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.
  • Das 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.
  • Das Computersystem 600 weist auch eine an den Bus 602 gekoppelte Kommunikations-Schnittstelle 618 auf. Die Kommunikations-Schnittstelle 618 stellt eine bidirektionale Daten-Kommunikationsverbindung zu einer Netzwerk-Verbindung 620 bereit, welche mit einem lokalen Netzwerk 622 gekoppelt ist. Zum Beispiel kann Kommunikations-Schnittstelle 618 eine Dienste-integrierendes-digitales-Nachrichtennetz-(ISDN) harte oder ein Modem sein, um eine Datenkommunikationsverbindung zu einer entsprechenden Art von Telephonleitung bereitzustellen. Als ein anderes Beispiel kann die 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 die Netzwerk-Verbindung 620 mittels des lokalen Netzwerks 622 eine Verbindung zu einem Zentralrechner 624 oder zu Datenvorrichtungen, welche von einem Internet-Service-Provider (ISP) 626 betrieben werden, bereitstellen. Im Gegenzug stellt ISP 626 Datenkommunikationsservices mittels des Weltweiten-Datenpaket-Kommunikations-Netzwerkes, jetzt gemeinhin als „Internet" 628 bezeichnet, bereit. Das Lokale 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.
  • Das 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 der Speichervorrichtung 610 oder anderen nichtflüchtigen Speichern zum späteren Ausführen gespeichert werden. Auf diese Weise kann das Computersystem 600 Anwendungscode in Form einer Trägerwelle erhalten.
  • Gemäß einem anderen Aspekt der Erfindung wird ein Verfahren zum Verwalten einer Ressource, die von einer Mehrzahl von Knoten verwendet wird, offenbart. Das Verfahren weist die Schritte auf: Empfangen einer Anforderung für die Ressource von einem ersten Knoten der Mehrzahl von Knoten, wobei der erste Knoten einen ersten Zwischenspeicher aufweist; Identifizieren eines zweiten Knotens der Mehrzahl von Knoten, wobei der zweite Knoten einen zweiten Zwischenspeicher aufweist, der eine erste Kopie der Ressource aufweist; Veranlassen, dass der zweite Knoten eine zweite Kopie der Ressource von dem zweiten Zwischenspeicher an den ersten Zwischenspeicher überträgt, ohne zuerst die Ressource von dem zweiten Zwischenspeicher in einem anhaltenden Speicher dauerhaft zu speichern; und Veranlassen, dass mindestens eine Kopie der Ressource in dem zweiten Zwischenspeicher beibehalten wird, bis die erste Kopie der Ressource oder ein Versionsnachfolger von ihr dauerhaft gespeichert ist.
  • Der erste Knoten kann ein erster Datenbank-Server sein und der zweite Knoten kann ein zweiter Datenbank-Server sein.
  • Das Verfahren kann ferner die Schritte aufweisen: Empfangen, von einem dritten Knoten der Mehrzahl von Knoten, einer zusätzlichen Anforderung für eine Erlaubnis, wobei der dritte Knoten eine dritte Kopie der Ressource in einem dritten Zwischenspeicher aufweist und wobei die Erlaubnis es dem dritten Knoten ermöglicht, die Ressource auf Platte zu schreiben, aber es dem dritten Knoten nicht ermöglicht, die Ressource zu verändern; Identifizieren eines vierten Knotens der Mehrzahl von Knoten, wobei der vierte Knoten eine vierte Kopie der Ressource in einem vierten Zwischenspeicher aufweist und wobei die vierte Kopie mindestens so neu wie die dritte Kopie ist; und Veranlassen, dass der vierte Knoten die vierte Kopie auf Platte schreibt.
  • Darüber hinaus kann das Verfahren den Schritt aufweisen: Veranlassen, dass alle Kopien der Ressource, die älter sind als die vierte Kopie, freigegeben werden, als Reaktion darauf, dass der vierte Knoten die vierte Kopie auf Platte schreibt.
  • Außerdem kann der vierte Knoten der dritte Knoten sein oder kann nicht der dritte Knoten sein.
  • Die vierte Kopie der Ressource kann ein früheres Abbild der Ressource sein.
  • Ferner kann das frühere Abbild der Ressource mindestens so neu wie jedes andere frühere Abbild der Ressource sein, das aktuell von der Mehrzahl von Knoten beibehalten wird.
  • Die vierte Kopie der Ressource kann eine aktuelle Version der Ressource sein.
  • Der Schritt des Veranlassens, dass der vierte Knoten die vierte Kopie auf Platte schreibt, kann den Schritt aufweisen: Bereitstellen einer zusätzlichen Erlaubnis für den vierten Knoten, die es dem vierten Knoten ermöglicht, die vierte Kopie auf Platte zu schreiben, wobei die zusätzliche Erlaubnis es dem vierten Knoten nicht ermöglicht, die vierte Kopie zu verändern.
  • Die zusätzliche Erlaubnis, die für den vierten Knoten bereitgestellt wird, kann eine Schreibsperre sein, die es dem vierten Knoten ermöglicht, die vierte Kopie auf Platte zu schreiben, wobei die Schreibsperre es dem vierten Knoten nicht ermöglicht, die vierte Kopie zu verändern.
  • Alternativ kann die zusätzliche Erlaubnis, die für den vierten Knoten bereitgestellt wird, ein Schreib-Token sein, der es dem vierten Knoten ermöglicht, die vierte Kopie auf Platte zu schreiben, wobei der Schreib-Token es dem vierten Knoten nicht ermöglicht, die vierte Kopie zu verändern.
  • Der Schritt des Veranlassens, dass der vierte Knoten die vierte Kopie auf Platte schreibt, kann den Schritt aufweisen: Zuordnen eines Zustands zu der vierten Kopie, wobei der Zustand es dem vierten Knoten ermöglicht, die vierte Kopie auf Platte zu schreiben.
  • Das Verfahren kann ferner die Schritte aufweisen: Bereitstellen, vor dem Empfangen der Anforderung, einer ersten Erlaubnis für den zweiten Knoten, die es diesem Knoten ermöglicht, die erste Kopie zu verändern, wobei die erste Erlaubnis es dem zweiten Knoten nicht ermöglicht, die erste Kopie auf Platte zu schreiben; und vor dem Veranlassen, dass der zweite Knoten die zweite Kopie an den ersten Zwischenspeicher überträgt, Bereitstellen einer zweiten Erlaubnis für den zweiten Knoten, die es erfordert, dass der zweite Knoten die zweite Kopie beibehält, wobei die zweite Erlaubnis es dem zweiten Knoten nicht ermöglicht, die zweite Kopie zu verändern und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf Platte zu schreiben.
  • Die erste Erlaubnis, die dem zweiten Knoten bereitgestellt wird, kann eine Änderungssperre sein, die es dem zweiten Knoten ermöglicht, die erste Kopie zu verändern, die Änderungssperre ermöglicht es dem zweiten Knoten nicht, die erste Kopie auf Platte zu schreiben, die zweite Erlaubnis kann eine Haltesperre sein, die es erfordert, dass der zweite Knoten die zweite Kopie beibehält, und wobei die Haltesperre es dem zweiten Knoten nicht ermöglicht, die zweite Kopie zu verändern, und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf Platte zu schreiben.
  • Die erste Erlaubnis, die dem zweiten Knoten bereitgestellt wird, kann ein Änderungs-Token sein, der es dem zweiten Knoten ermöglicht, die erste Kopie zu verändern, der Änderungs-Token ermöglicht es dem zweiten Knoten nicht, die erste Kopie auf Platte zu schreiben, die zweite Erlaubnis kann ein Halte-Token sein, der es erfordert, dass der zweite Knoten die zweite Kopie beibehält, und wobei der Halte-Token es dem zweiten Knoten nicht ermöglicht, die zweite Kopie zu verändern, und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf Platte zu schreiben.
  • Das Verfahren kann ferner die Schritte aufweisen: vor dem Empfangen der Anforderung, Zuordnen eines ersten Zustands zu der ersten Kopie, der es dem zweiten Knoten ermöglicht, die erste Kopie zu verändern, und es dem zweiten Knoten ermöglicht, die erste Kopie auf Platte zu schreiben; und vor dem Veranlassen, dass der zweite Knoten die zweite Kopie an den ersten Zwischenspeicher überträgt, Zuordnen eines zweiten Zustands zu der ersten Kopie, der es dem zweiten Knoten ermöglicht, die erste Kopie auf Platte zu schreiben, wobei der zweite Zustand es dem zweiten Knoten nicht ermöglicht, die erste Kopie zu verändern oder zu überschreiben.
  • Der erste Zustand kann ein aktueller Zustand sein, der es dem zweiten Knoten ermöglicht, die erste Kopie zu verändern, und es dem zweiten Knoten ermöglicht, die erste Kopie auf Platte zu schreiben, und der zweite Zustand kann ein schreibbarer Früheres-Abbild-Zustand sein, der es dem zweiten Knoten ermöglicht, die erste Kopie auf Platte zu schreiben, wobei der schreibbare Früheres-Abbild-Zustand es nicht ermöglicht, dass der zweite Knoten die erste Kopie verändert oder überschreibt.
  • Das Verfahren kann ferner den Schritt aufweisen: Veranlassen, dass der zweite Knoten eine Änderungs-Erlaubnis von dem zweiten Knoten an den ersten Knoten überträgt.
  • Das Verfahren kann ferner den Schritt aufweisen: Empfangen einer Nachricht von dem zweiten Knoten, dass der zweite Knoten die Änderungs-Erlaubnis an den ersten Knoten übertragen hat.
  • Die Nachricht, dass der zweite Knoten die Änderungs-Erlaubnis an den ersten Knoten übertragen hat, kann empfangen werden, nachdem der zweite Knoten die Änderungs-Erlaubnis an den ersten Knoten überträgt.
  • Das Verfahren kann ferner die Schritte aufweisen: Speichern von Daten, die anzeigen, dass der erste Knoten die Änderungs-Erlaubnis enthält.
  • Gemäß einem anderen Aspekt der Erfindung wird ein computerlesbares Medium, das eine Folge oder mehrere Folgen von Befehlen zum Verwalten einer Ressource, die von einer Mehrzahl von Knoten verwendet wird, enthält, vorgeschlagen, wobei die Ausführung der einen Folge oder der mehreren Folgen von Befehlen mittels eines Prozessors oder mehrerer Prozessoren den einen Prozessor oder die mehreren Prozessoren dazu veranlasst, die Schritte auszuführen: Empfangen einer Anforderung für die Ressource von einem ersten Knoten der Mehrzahl von Knoten, wobei der erste Knoten einen ersten Zwischenspeicher aufweist; Identifizieren eines zweiten Knotens der Mehrzahl von Knoten, wobei der zweite Knoten einen zweiten Zwischenspeicher aufweist, der eine erste Kopie der Ressource aufweist; Veranlassen, dass der zweite Knoten eine zweite Kopie der Ressource von dem zweiten Zwischenspeicher an den ersten Zwischenspeicher überträgt, ohne zuerst die Ressource von dem zweiten Zwischenspeicher in einem andauernden Speicher dauerhaft zu speichern; und Veranlassen, dass mindestens eine Kopie der Ressource in dem zweiten Zwischenspeicher beibehalten wird, bis die erste Kopie der Ressource oder ein Versionsnachfolger von ihr dauerhaft gespeichert ist.
  • Der erste Knoten kann ein erster Datenbank-Server sein und der zweite Knoten kann ein zweiter Datenbank-Server sein.
  • Das computerlesbare Medium kann ferner Befehle aufweisen, die, wenn sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren veranlassen, die Schritte auszuführen: Empfangen, von einem dritten Knoten der Mehrzahl von Knoten, einer zusätzlichen Anforderung für eine Erlaubnis, wobei der dritte Knoten eine dritte Kopie der Ressource in einem dritten Zwischenspeicher aufweist und wobei die Erlaubnis es dem dritten Knoten ermöglicht, die Ressource auf Platte zu schreiben, aber es dem dritten Knoten nicht ermöglicht, die Ressource zu verändern; Identifizieren eines vierten Knotens der Mehrzahl von Knoten, wobei der vierte Knoten eine vierte Kopie der Ressource in einem vierten Zwischenspeicher aufweist und wobei die vierte Kopie mindestens so neu wie die dritte Kopie ist; und Veranlassen, dass der vierte Knoten die vierte Kopie auf Platte schreibt.
  • Das computerlesbare Medium kann ferner Befehle aufweisen, die, wenn sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren veranlassen, die Schritte auszuführen: Veranlassen, dass alle Kopien der Ressource, die älter sind als die vierte Kopie, freigegeben werden, als Reaktion darauf, dass der vierte Knoten die vierte Kopie auf Platte schreibt.
  • Der vierte Knoten kann der dritte Knoten sein oder kann nicht der dritte Knoten sein.
  • Die vierte Kopie der Ressource kann ein früheres Abbild der Ressource sein.
  • Das frühere Abbild der Ressource kann mindestens so neu wie jedes andere frühere Abbild der Ressource sein, das aktuell von der Mehrzahl von Knoten beibehalten wird.
  • Die vierte Kopie der Ressource kann eine aktuelle Version der Ressource sein.
  • Bei dem computerlesbaren Medium können die Befehle zum Veranlassen, dass der vierte Knoten die vierte Kopie auf Platte schreibt, ferner Befehle aufweisen, die, wenn sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren veranlassen, den Schritt auszuführen: Bereitstellen einer zusätzlichen Erlaubnis für den vierten Knoten, die es dem vierten Knoten ermöglicht, die vierte Kopie auf Platte zu schreiben, wobei die zusätzliche Erlaubnis es dem vierten Knoten nicht ermöglicht, die vierte Kopie zu verändern.
  • Die zusätzliche Erlaubnis, die für den vierten Knoten bereitgestellt wird, kann eine Schreibsperre sein, die es dem vierten Knoten ermöglicht, die vierte Kopie auf Platte zu schreiben, wobei die Schreibsperre es dem vierten Knoten nicht ermöglicht, die vierte Kopie zu verändern.
  • Die zusätzliche Erlaubnis, die für den vierten Knoten bereitgestellt wird, kann ein Schreib-Token sein, der es dem vierten Knoten ermöglicht, die vierte Kopie auf Platte zu schreiben, wobei der Schreib-Token es dem vierten Knoten nicht ermöglicht, die vierte Kopie zu verändern.
  • Bei dem computerlesbaren Medium können die Befehle zum Veranlassen, dass der vierte Knoten die vierte Kopie auf Platte schreibt, ferner Befehle aufweisen, die, wenn sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren veranlassen, den Schritt auszuführen: Zuordnen eines Zustands zu der vierten Kopie, wobei der Zustand es dem vierten Knoten ermöglicht, die vierte Kopie auf Platte zu schreiben.
  • Das computerlesbare Medium kann ferner Befehle aufweisen, die, wenn sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren veranlassen, die Schritte auszuführen: Bereitstellen, vor dem Empfangen der Anforderung, einer ersten Erlaubnis für den zweiten Knoten, die es dem zweiten Knoten ermöglicht, die erste Kopie zu verändern, wobei die erste Erlaubnis es dem zweiten Knoten nicht ermöglicht, die erste Kopie auf Platte zu schreiben; und vor dem Veranlassen, dass der zweite Knoten die zweite Kopie an den ersten Zwischenspeicher überträgt, Bereitstellen einer zweiten Erlaubnis für den zweiten Knoten, die es erfordert, dass der zweite Knoten die zweite Kopie beibehält, und wobei die zweite Erlaubnis es dem zweiten Knoten nicht ermöglicht, die zweite Kopie zu verändern, und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf Platte zu schreiben.
  • Die erste Erlaubnis, die dem zweiten Knoten bereitgestellt wird, kann eine Änderungssperre sein, die es dem zweiten Knoten ermöglicht, die erste Kopie zu verändern, die Änderungssperre ermöglicht es dem zweiten Knoten nicht, die erste Kopie auf Platte zu schreiben, die zweite Erlaubnis kann eine Haltesperre sein, die es erfordert, dass der zweite Knoten die zweite Kopie beibehält, und wobei die Haltesperre es dem zweiten Knoten nicht ermöglicht, die zweite Kopie zu verändern, und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf Platte zu schreiben.
  • Die erste Erlaubnis, die dem zweiten Knoten bereitgestellt wird, kann ein Änderungs-Token sein, der es dem zweiten Knoten ermöglicht, die erste Kopie zu verändern, der Änderungs-Token ermöglicht es dem zweiten Knoten nicht, die erste Kopie auf Platte zu schreiben, die zweite Erlaubnis kann ein Halte-Token sein, der es erfordert, dass der zweite Knoten die zweite Kopie beibehält, und wobei der Halte-Token es dem zweiten Knoten nicht ermöglicht, die zweite Kopie zu verändern, und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf Platte zu schreiben.
  • Das computerlesbare Medium kann ferner Befehle aufweisen, die, wenn sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren veranlassen, die Schritte auszuführen: vor dem Empfangen der Anforderung, Zuordnen eines ersten Zustands zu der ersten Kopie, der es dem zweiten Knoten ermöglicht, die erste Kopie zu verändern, und es dem zweiten Knoten ermöglicht, die erste Kopie auf Platte zu schreiben; und vor dem Veranlassen, dass der zweite Knoten die zweite Kopie an den ersten Zwischenspeicher überträgt, Zuordnen eines zweiten Zustands zu der ersten Kopie, der es dem zweiten Knoten ermöglicht, die erste Kopie auf Platte zu schreiben, wobei der zweite Zustand es dem zweiten Knoten nicht ermöglicht, die erste Kopie zu verändern oder zu überschreiben.
  • Der erste Zustand kann ein aktueller Zustand sein, der es dem zweiten Knoten ermöglicht, die erste Kopie zu verändern, und es dem zweiten Knoten ermöglicht, die erste Kopie auf Platte zu schreiben, und der zweite Zustand kann ein schreibbarer Früheres-Abbild-Zustand sein, der es dem zweiten Knoten ermöglicht, die erste Kopie auf Platte zu schreiben, wobei der schreibbare Früheres-Abbild-Zustand es nicht ermöglicht, dass der zweite Knoten die erste Kopie verändert oder überschreibt.
  • Das computerlesbare Medium kann ferner Befehle aufweisen, die, wenn sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren veranlassen, die Schritte auszuführen: Veranlassen, dass der zweite Knoten eine Änderungs-Erlaubnis von dem zweiten Knoten an den ersten Knoten überträgt.
  • Das computerlesbare Medium kann ferner Befehle aufweisen, die, wenn sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren veranlassen, die Schritte auszuführen: Empfangen einer Nachricht von dem zweiten Knoten, dass der zweite Knoten die Änderungs-Erlaubnis an den ersten Knoten übertragen hat.
  • Die Nachricht, dass der zweite Knoten die Änderungs-Erlaubnis an den ersten Knoten übertragen hat, kann empfangen werden, nachdem der zweite Knoten die Änderungs-Erlaubnis an den ersten Knoten überträgt.
  • Das computerlesbare Medium kann ferner Befehle aufweisen, die, wenn sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren veranlassen, die Schritte auszuführen: Speichern von Daten, die anzeigen, dass der erste Knoten die Änderungs-Erlaubnis enthält.
  • 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 usw. haben, 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 Platten E/A auftritt.
  • Die direkten Versendungstechniken, 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.
  • In der vorangegangenen Ausführung wurde die Erfindung mit Bezug auf spezifische Ausführungsbeispiele hiervon beschrieben. Es wird jedoch klar sein, dass dazu verschiedenartige Modifikationen und Änderungen gemacht werden können. Die Ausführung und Figuren sind gemäß mehr in einem erklärenden als in einem einschränkenden Sinne zu beachten.

Claims (20)

  1. Verfahren zum Verwalten einer Ressource, die von einer Mehrzahl von Knoten (A, B, C, D) benutzt wird, wobei das Verfahren die Schritte aufweist: Erteilen einer Schreib-Genehmigung für die Mehrbenutzer-Ressource getrennt vom Erteilen einer Modifizierungs-Genehmigung für die Mehrbenutzer-Ressource; wobei Besitzen der Schreib-Genehmigung es einem Knoten (A, B, C, D), der die Schreib-Genehmigung besitzt, erlaubt, eine Kopie der Mehrbenutzer-Ressource, die in einem Zwischenspeicher des Knotens (A, B, C, D), der die Schreib-Genehmigung besitzt, bereitgehalten wird, auf Platte (655) zu schreiben, wobei Besitzen der Schreib-Genehmigung es dem Knoten (A, B, C, D), der die Schreib-Genehmigung besitzt, nicht erlaubt, die Kopie der Mehrbenutzer-Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Schreib-Genehmigung besitzt, bereitgehalten wird, zu modifizieren; und wobei Besitzen der Modifizierungs-Genehmigung es einem Knoten (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, erlaubt, eine Kopie der Mehrbenutzer-Ressource, die in einem Zwischenspeicher des Knotens (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, bereitgehalten wird, zu modifizieren, wobei Besitzen der Modifizierungs-Genehmigung es dem Knoten (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, nicht erlaubt, die Kopie der Mehrbenutzer-Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, bereitgehalten wird, auf Platte (655) zu schreiben.
  2. Verfahren gemäß Anspruch 1, wobei die Schreib-Genehmigung für die Mehrbenutzer-Ressource stets nur einem einzigen Knoten (A, B, C, D) der Mehrzahl von Knoten (A, B, C, D) erteilt wird und wobei die Modifizierungs-Genehmigung für die Mehrbenutzer-Ressource stets nur einem einzigen Knoten (A, B, C, D) der Mehrzahl von Knoten (A, B, C, D) erteilt wird.
  3. Verfahren gemäß Anspruch 1, wobei die Schreib-Genehmigung und die Modifizierungs-Genehmigung von verschiedenen Knoten (A, B, C, D) der Mehrzahl von Knoten (A, B, C, D) besessen werden.
  4. Verfahren gemäß Anspruch 1, wobei die Schreib-Genehmigung und die Modifizierungs-Genehmigung vom gleichen Knoten (A, B, C, D) der Mehrzahl von Knoten (A, B, C, D) besessen werden.
  5. Verfahren gemäß Anspruch 1, welches ferner den Schritt aufweist: Erteilen einer Halte-Genehmigung für die Mehrbenutzer-Ressource getrennt vom Erteilen der Schreib-Genehmigung für die Mehrbenutzer-Ressource und getrennt vom Erteilen der Modifizierungs-Genehmigung für die Mehrbenutzer-Ressource; und wobei Besitzen der Halte-Genehmigung es erfordert, dass ein Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, eine Kopie der Ressource, die in einem Zwischenspeicher des Knotens (A, B, C, D), der die Halte-Genehmigung besitzt, bereitgehalten wird, behält.
  6. Verfahren gemäß Anspruch 1, welches ferner den Schritt aufweist Erteilen einer Halte-Genehmigung für die Mehrbenutzer-Ressource an jeden Knoten (A, B, C, D) einer Gruppe von Knoten (A, B, C, D) aus der Mehrzahl von Knoten (A, B, C, D) getrennt vom Erteilen der Schreib-Genehmigung für die Mehrbenutzer-Ressource und getrennt vom Erteilen der Modifizierungs-Genehmigung für die Mehrbenutzer-Ressource; und wobei Besitzen der Halte-Genehmigung es erfordert, dass jeder Knoten (A, B, C, D) der Gruppe von Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, eine Kopie der Mehrbenutzer-Ressource, die in einem Zwischenspeicher eines jeden Knotens (A, B, C, D) der Gruppe von Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, bereitgehalten wird, behält.
  7. Verfahren gemäß Anspruch 5, wobei Besitzen der Halte-Genehmigung es erfordert, dass der Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, die Kopie der Mehrbenutzer-Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Halte-Genehmigung besitzt, bereitgehalten wird, behält, bis die Kopie der Mehrbenutzer-Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Halte-Genehmigung besitzt, bereitgehalten wird, oder ein Nachfolger davon dauerhaft gespeichert ist.
  8. Computerlesbares Medium, das eine Folge oder mehrere Folgen von Befehlen zum Verwalten einer Ressource, die von einer Mehrzahl von Knoten (A, B, C, D) benutzt wird, enthält, wobei die Ausführung der einen Folge oder der mehreren Folgen von Befehlen mittels eines Prozessors oder mehrerer Prozessoren (604) den einen Prozessor oder die mehreren Prozessoren (604) veranlasst, die Schritte auszuführen: Erteilen einer Schreib-Genehmigung für die Mehrbenutzer-Ressource getrennt vom Erteilen einer Modifizierungs-Genehmigung für die Mehrbenutzer-Ressource; wobei Besitzen der Schreib-Genehmigung es einem Knoten (A, B, C, D), der die Schreib-Genehmigung besitzt, erlaubt, eine Kopie der Mehrbenutzer-Ressource, die in einem Zwischenspeicher des Knotens (A, B, C, D), der die Schreib-Genehmigung besitzt, bereitgehalten wird, auf Platte (655) zu schreiben, wobei Besitzen der Schreib-Genehmigung es dem Knoten (A, B, C, D), der die Schreib-Genehmigung besitzt, nicht erlaubt, die Kopie der Mehrbenutzer-Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Schreib-Genehmigung besitzt, bereitgehalten wird, zu modifizieren; und wobei Besitzen der Modifizierungs-Genehmigung es einem Knoten (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, erlaubt, eine Kopie der Mehrbenutzer-Ressource, die in einem Zwischenspeicher des Knotens (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, bereitgehalten wird, zu modifizieren, wobei Besitzen der Modifizierungs-Genehmigung es dem Knoten (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, nicht erlaubt, die Kopie der Mehrbenutzer-Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, bereitgehalten wird, auf Platte (655) zu schreiben.
  9. Computerlesbares Medium gemäß Anspruch 8, wobei die Schreib-Genehmigung für die Mehrbenutzer-Ressource stets nur einem einzigen Knoten (A, B, C, D) der Mehrzahl von Knoten (A, B, C, D) erteilt wird und wobei die Modifizierungs- Genehmigung für die Mehrbenutzer-Ressource stets nur einem einzigen Knoten (A, B, C, D) der Mehrzahl von Knoten (A, B, C, D) erteilt wird.
  10. Computerlesbares Medium gemäß Anspruch 8, wobei die Schreib-Genehmigung und die Modifizierungs-Genehmigung von verschiedenen Knoten (A, B, C, D) der Mehrzahl von Knoten (A, B, C, D) besessen werden.
  11. Computerlesbares Medium gemäß Anspruch 8, wobei die Schreib-Genehmigung und die Modifizierungs-Genehmigung vom gleichen Knoten (A, B, C, D) der Mehrzahl von Knoten (A, B, C, D) besessen werden.
  12. Computerlesbares Medium gemäß Anspruch 8, ferner aufweisend Befehle, die, wenn sie mittels des einen Prozessors oder der mehreren Prozessoren (604) ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren (604) veranlassen, die Schritte auszuführen: Erteilen einer Halte-Genehmigung für die Mehrbenutzer-Ressource getrennt vom Erteilen der Schreib-Genehmigung für die Mehrbenutzer-Ressource und getrennt vom Erteilen der Modifizierungs-Genehmigung für die Mehrbenutzer-Ressource; und wobei Besitzen der Halte-Genehmigung es erfordert, dass ein Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, eine Kopie der Ressource, die in einem Zwischenspeicher des Knotens (A, B, C, D), der die Halte-Genehmigung besitzt, bereitgehalten wird, behält.
  13. Computerlesbares Medium gemäß Anspruch 8, ferner aufweisend Befehle, die, wenn sie mittels des einen Prozessors oder der mehreren Prozessoren (604) ausgeführt werden, den einen Prozessor oder die mehreren Prozessoren (604) veranlassen, die Schritte auszuführen: Erteilen einer Halte-Genehmigung für die Mehrbenutzer-Ressource an jeden Knoten (A, B, C, D) einer Gruppe von Knoten (A, B, C, D) aus der Mehrzahl von Knoten (A, B, C, D) getrennt vom Erteilen der Schreib-Genehmigung für die Mehrbenutzer-Ressource und getrennt vom Erteilen der Modifizierungs-Genehmigung für die Mehrbenutzer-Ressource; und wobei Besitzen der Halte-Genehmigung es erfordert, dass jeder Knoten (A, B, C, D) der Gruppe von Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, eine Kopie der Mehrbenutzer-Ressource, die in einem Zwischenspeicher eines jeden Knotens (A, B, C, D) der Gruppe von Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, bereitgehalten wird, behält.
  14. Computerlesbares Medium gemäß Anspruch 12, wobei Besitzen der Halte-Genehmigung es erfordert, dass der Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, die Kopie der Mehrbenutzer-Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Halte-Genehmigung besitzt, bereitgehalten wird, behält, bis die Kopie der Mehrbenutzer-Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Halte-Genehmigung besitzt, bereitgehalten wird, oder ein Nachfolger davon dauerhaft gespeichert ist.
  15. System zum Verwalten einer Ressource, die von einer Mehrzahl von Knoten (A, B, C, D) benutzt wird, wobei das System aufweist einen Mechanismus zum Erteilen von Schreib-Genehmigungen für die Mehrbenutzer-Ressource getrennt vom Erteilen von Modifizierungs-Genehmigungen für die Mehrbenutzer-Ressource; wobei eine Schreib-Genehmigung es einem Knoten (A, B, C, D), der die Schreib-Genehmigung besitzt, erlaubt, eine Kopie der Ressource, die in einem Zwischenspeicher des Knotens (A, B, C, D), der die Schreib-Genehmigung besitzt, bereitgehalten wird, auf Platte (655) zu schreiben, wobei die Schreib-Genehmigung es dem Knoten (A, B, C, D), der die Schreib-Genehmigung besitzt, nicht erlaubt, die Kopie der Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Schreib-Genehmigung besitzt, bereitgehalten wird, zu modifizieren; und wobei eine Modifizierungs-Genehmigung es einem Knoten (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, erlaubt, eine Kopie der Ressource, die in einem Zwischenspeicher des Knotens (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, bereitgehalten wird, zu modifizieren, wobei Besitzen der Modifizierungs-Genehmigung es dem Knoten (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, nicht erlaubt, die Kopie der Ressource, die in dem Zwischenspeicher des Knotens (A, B, C, D), der die Modifizierungs-Genehmigung besitzt, bereitgehalten wird, auf Platte (655) zu schreiben.
  16. System gemäß Anspruch 15, wobei der Mechanismus ferner eingerichtet ist, stets lediglich eine einzige Schreib-Genehmigung für die Mehrzahl von Knoten (A, B, C, D) zu erteilen und stets lediglich eine einzige Modifizierungs-Genehmigung für die Mehrzahl von Knoten (A, B, C, D) zu erteilen.
  17. System gemäß Anspruch 15, wobei der Mechanismus ferner eingerichtet ist, eine Halte-Genehmigung zu erteilen, die es erfordert, dass ein Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, eine dritte Kopie der Ressource, die in einem dritten Zwischenspeicher des Knotens (A, B, C, D), der die Halte-Genehmigung besitzt, bereitgehalten wird, behält.
  18. System gemäß Anspruch 17, wobei die Halte-Genehmigung es erfordert, dass der Knoten (A, B, C, D), der die Halte-Genehmigung besitzt, die dritte Kopie der Ressource behält, bis die dritte Kopie der Ressource oder ein Nachfolger davon dauerhaft gespeichert ist.
  19. System gemäß Anspruch 15, wobei der Mechanismus ferner eingerichtet ist, eine Mehrzahl von Halte-Genehmigungen zu erteilen, wobei jede Halte-Genehmigung der Mehrzahl von Halte-Genehmigungen einem Knoten (A, B, C, D) der Mehrzahl von Knoten (A, B, C, D) erteilt wird und wobei jede Halte-Genehmigung es erfordert, dass ein Knoten (A, B, C, D), der eine der Mehrzahl von Halte-Genehmigungen besitzt, eine weitere Kopie der Ressource, die in einem Zwischenspeicher des Knotens (A, B, C, D), der eine der Mehrzahl von Halte-Genehmigungen besitzt, bereitgehalten wird, behält.
  20. System gemäß Anspruch 19, wobei jede Halte-Genehmigung der Mehrzahl von Halte-Genehmigungen es erfordert, dass der Knoten, der eine der Mehrzahl von Halte-Genehmigungen besitzt, die weitere Kopie der Ressource behält, bis die weitere Kopie der Ressource oder ein Nachfolger davon dauerhaft gespeichert ist.
DE69929095T 1998-02-13 1999-02-12 Verwaltung eines durch eine Mehrzahl von Knoten benutzten Betriebsmittels Expired - Lifetime DE69929095T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US7458798P 1998-02-13 1998-02-13
US74587P 1998-02-13
US09/199,120 US6353836B1 (en) 1998-02-13 1998-11-24 Method and apparatus for transferring data from the cache of one node to the cache of another node
US199120 1998-11-24

Publications (2)

Publication Number Publication Date
DE69929095D1 DE69929095D1 (de) 2006-01-26
DE69929095T2 true DE69929095T2 (de) 2006-08-17

Family

ID=26755827

Family Applications (6)

Application Number Title Priority Date Filing Date
DE69939226T Expired - Lifetime DE69939226D1 (de) 1998-02-13 1999-02-12 Rückgewinnung von Daten von einem oder mehreren fehlerhaften Caches
DE69901291T Expired - Lifetime DE69901291T2 (de) 1998-02-13 1999-02-12 Verfahren und vorrichtung zur datenübertragung zwischen der caches von netzwerkknoten
DE69917333T Expired - Lifetime DE69917333T2 (de) 1998-02-13 1999-02-12 Übertragung einer Ressource von einem ersten Zwischenspeicher an einen zweiten Zwischenspeicher
DE69917342T Expired - Lifetime DE69917342T2 (de) 1998-02-13 1999-02-12 Managen der Wiederherstellung von Daten nach einem Absturz von einem oder mehreren Zwischenspeichern
DE69918470T Expired - Lifetime DE69918470T2 (de) 1998-02-13 1999-02-12 Verwalten einer Ressource, welche von einer Mehrzahl von Knoten verwendet wird
DE69929095T Expired - Lifetime DE69929095T2 (de) 1998-02-13 1999-02-12 Verwaltung eines durch eine Mehrzahl von Knoten benutzten Betriebsmittels

Family Applications Before (5)

Application Number Title Priority Date Filing Date
DE69939226T Expired - Lifetime DE69939226D1 (de) 1998-02-13 1999-02-12 Rückgewinnung von Daten von einem oder mehreren fehlerhaften Caches
DE69901291T Expired - Lifetime DE69901291T2 (de) 1998-02-13 1999-02-12 Verfahren und vorrichtung zur datenübertragung zwischen der caches von netzwerkknoten
DE69917333T Expired - Lifetime DE69917333T2 (de) 1998-02-13 1999-02-12 Übertragung einer Ressource von einem ersten Zwischenspeicher an einen zweiten Zwischenspeicher
DE69917342T Expired - Lifetime DE69917342T2 (de) 1998-02-13 1999-02-12 Managen der Wiederherstellung von Daten nach einem Absturz von einem oder mehreren Zwischenspeichern
DE69918470T Expired - Lifetime DE69918470T2 (de) 1998-02-13 1999-02-12 Verwalten einer Ressource, welche von einer Mehrzahl von Knoten verwendet wird

Country Status (8)

Country Link
US (7) US6353836B1 (de)
EP (1) EP1055173B1 (de)
JP (1) JP3815967B2 (de)
AU (1) AU768747B2 (de)
CA (1) CA2320240C (de)
DE (6) DE69939226D1 (de)
HK (5) HK1039812B (de)
WO (1) WO1999041664A1 (de)

Families Citing this family (112)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6574654B1 (en) 1996-06-24 2003-06-03 Oracle Corporation Method and apparatus for lock caching
US6353836B1 (en) 1998-02-13 2002-03-05 Oracle Corporation Method and apparatus for transferring data from the cache of one node to the cache of another node
AU2003213536B2 (en) * 1998-02-13 2007-05-10 Oracle International Corporation Method and apparatus for transferring data from the cache of one node to the cache of another node
US7200623B2 (en) * 1998-11-24 2007-04-03 Oracle International Corp. Methods to perform disk writes in a distributed shared disk system needing consistency across failures
US7930278B2 (en) 1998-02-13 2011-04-19 Oracle International Corporation Methods to perform disk writes in a distributed shared disk system needing consistency across failures
AU2007202588B2 (en) * 1998-02-13 2008-11-06 Oracle International Corporation Method and apparatus for transferring data from the cache of one node to the cache of another node
US6633891B1 (en) 1998-11-24 2003-10-14 Oracle International Corporation Managing replacement of data in a cache on a node based on caches of other nodes
US7065540B2 (en) * 1998-11-24 2006-06-20 Oracle International Corporation Managing checkpoint queues in a multiple node system
US7003721B1 (en) * 1999-06-15 2006-02-21 Microsoft Corporation Safe save method of HTML files using recovery files including a list with temporary and final names for replacement files
US6405219B2 (en) * 1999-06-22 2002-06-11 F5 Networks, Inc. Method and system for automatically updating the version of a set of files stored on content servers
US6609126B1 (en) 2000-11-15 2003-08-19 Appfluent Technology, Inc. System and method for routing database requests to a database and a cache
US6961728B2 (en) * 2000-11-28 2005-11-01 Centerboard, Inc. System and methods for highly distributed wide-area data management of a network of data sources through a database interface
US6965893B1 (en) 2000-12-20 2005-11-15 Oracle International Corporation Techniques for granting shared locks more efficiently
US6850938B1 (en) * 2001-02-08 2005-02-01 Cisco Technology, Inc. Method and apparatus providing optimistic locking of shared computer resources
CA2440277C (en) * 2001-03-07 2011-05-17 Oracle International Corporation Managing checkpoint queues in a multiple node system
US6772363B2 (en) * 2001-03-12 2004-08-03 Hewlett-Packard Development Company, L.P. Fast failover database tier in a multi-tier transaction processing system
US7107319B2 (en) * 2001-05-31 2006-09-12 Oracle Corporation Method and apparatus for reducing latency and message traffic during data and lock transfer in a multi-node system
US7076510B2 (en) * 2001-07-12 2006-07-11 Brown William P Software raid methods and apparatuses including server usage based write delegation
US7325064B2 (en) * 2001-07-17 2008-01-29 International Business Machines Corporation Distributed locking protocol with asynchronous token prefetch and relinquish
US6721851B2 (en) * 2001-08-07 2004-04-13 Veritas Operating Corporation System and method for preventing sector slipping in a storage area network
US7363447B1 (en) 2001-08-07 2008-04-22 Symantec Operating Corporation System and method for providing safe data movement using third party copy techniques
US6820114B2 (en) * 2001-09-27 2004-11-16 Sap Aktiengesellschaft Identifying object suppliers in a network
US7496645B2 (en) * 2001-10-18 2009-02-24 Hewlett-Packard Development Company, L.P. Deployment of business logic software and data content onto network servers
US7028300B2 (en) * 2001-11-13 2006-04-11 Microsoft Corporation Method and system for managing resources in a distributed environment that has an associated object
US6748470B2 (en) * 2001-11-13 2004-06-08 Microsoft Corporation Method and system for locking multiple resources in a distributed environment
US7406519B2 (en) * 2001-11-13 2008-07-29 Microsoft Corporation Method and system for locking resources in a distributed environment
US20030105871A1 (en) * 2001-11-13 2003-06-05 Microsoft Corporation, Method and system for modifying lock properties in a distributed environment
US8086579B1 (en) * 2002-01-22 2011-12-27 Oracle International Corporation Semantic response to lock requests to reduce coherence overhead in multi-node systems
US20030188096A1 (en) * 2002-03-15 2003-10-02 Otto Lehner Distributing access rights to mass storage
CA2377649C (en) * 2002-03-20 2009-02-03 Ibm Canada Limited-Ibm Canada Limitee Dynamic cluster database architecture
US7181452B1 (en) * 2002-04-04 2007-02-20 Ncr Corp. Locking mechanism using predefined locks for aggregate materialized views in a database system
US6988165B2 (en) * 2002-05-20 2006-01-17 Pervasive Software, Inc. System and method for intelligent write management of disk pages in cache checkpoint operations
US7448077B2 (en) * 2002-05-23 2008-11-04 International Business Machines Corporation File level security for a metadata controller in a storage area network
US6981104B2 (en) * 2002-07-12 2005-12-27 Hewlett-Packard Development Company, L.P. Method for conducting checkpointing within a writeback cache
US7565406B2 (en) * 2002-07-24 2009-07-21 Sun Microsystems, Inc. Last thread lock management for multi-threaded process and distributed data systems
US7093230B2 (en) * 2002-07-24 2006-08-15 Sun Microsystems, Inc. Lock management thread pools for distributed data systems
US20040019660A1 (en) * 2002-07-24 2004-01-29 Sandhya E. Lock holding multi-threaded processes for distibuted data systems
US8095657B2 (en) * 2002-07-24 2012-01-10 Oracle America, Inc. First thread lock management for distributed data systems
ATE332534T1 (de) * 2002-09-09 2006-07-15 Sap Ag Verfahren, vorrichtungen und programme zur regelung des zugriffs auf datenobjekte unter verwendung von sperren
US7457933B2 (en) * 2002-09-09 2008-11-25 Sap Ag Methods and systems for archiving data
US20060149696A1 (en) * 2002-09-09 2006-07-06 Thorsten Pferdekaemper Method and systems for controlling access to a data object by means of locks
US7653667B2 (en) * 2002-09-09 2010-01-26 Sap Ag Methods and systems for data moving using locks
US7693881B2 (en) * 2002-09-09 2010-04-06 Sap Ag Methods and systems for moving data using locks
US7756813B2 (en) * 2002-09-09 2010-07-13 Sap Ag Electronic data structure for controlling access to data objects using locks
US7707184B1 (en) * 2002-10-09 2010-04-27 Netapp, Inc. System and method for snapshot full backup and hard recovery of a database
US7451359B1 (en) 2002-11-27 2008-11-11 Oracle International Corp. Heartbeat mechanism for cluster systems
DE10256148A1 (de) * 2002-11-29 2004-06-17 Basf Ag Gegenstand der vorliegenden Erfindung sind Zusammensetzungen enthaltend mindestens ein Copolymer (A) und mindestens ein Copolymer (B) sowie deren Verwendung in kosmetischen Zubereitungen
US7822612B1 (en) 2003-01-03 2010-10-26 Verizon Laboratories Inc. Methods of processing a voice command from a caller
US7281050B2 (en) * 2003-04-08 2007-10-09 Sun Microsystems, Inc. Distributed token manager with transactional properties
US7039773B2 (en) 2003-04-29 2006-05-02 Oracle International Corporation Method and mechanism for efficient implementation of ordered records
US7124131B2 (en) * 2003-04-29 2006-10-17 International Business Machines Corporation Discipline for lock reassertion in a distributed file system
US7447786B2 (en) * 2003-05-09 2008-11-04 Oracle International Corporation Efficient locking of shared data that is accessed for reads in a cluster database
US7376744B2 (en) 2003-05-09 2008-05-20 Oracle International Corporation Using local locks for global synchronization in multi-node systems
US7139772B2 (en) 2003-08-01 2006-11-21 Oracle International Corporation Ownership reassignment in a shared-nothing database system
US7343432B1 (en) * 2003-09-19 2008-03-11 Emc Corporation Message based global distributed locks with automatic expiration for indicating that said locks is expired
US7324995B2 (en) * 2003-11-17 2008-01-29 Rackable Systems Inc. Method for retrieving and modifying data elements on a shared medium
US7447710B2 (en) * 2003-12-11 2008-11-04 Sybase, Inc. Database system providing self-tuned parallel database recovery
US7299378B2 (en) 2004-01-15 2007-11-20 Oracle International Corporation Geographically distributed clusters
US7421562B2 (en) * 2004-03-01 2008-09-02 Sybase, Inc. Database system providing methodology for extended memory support
US20050251495A1 (en) * 2004-05-06 2005-11-10 Bea Systems, Inc. System and method for unified file management
US7428733B2 (en) * 2004-05-13 2008-09-23 Bea Systems, Inc. System and method for custom module creation and deployment
US7814484B2 (en) * 2004-05-14 2010-10-12 Bea Systems, Inc. System and method for web application extensibility
US8181162B2 (en) * 2004-06-14 2012-05-15 Alcatel Lucent Manager component for checkpoint procedures
JP2006004031A (ja) * 2004-06-16 2006-01-05 Hitachi Ltd データ処理方法およびシステム並びにストレージ装置方法およびその処理プログラム
US7809690B2 (en) * 2004-07-13 2010-10-05 Oracle International Corporation Performance metric-based selection of one or more database server instances to perform database recovery
US8688662B2 (en) * 2004-09-28 2014-04-01 International Business Machines Corporation Copy on access to locked objects
US7567986B2 (en) * 2004-10-07 2009-07-28 Microsoft Corporation Method and system for limiting resource usage of a version store
US8566326B2 (en) 2004-11-05 2013-10-22 Oracle International Corporation High-performance log-based processing
US7506202B1 (en) 2005-02-08 2009-03-17 Symantec Operating Corporation Compression of temporal dimension in a temporal storage device
US7631021B2 (en) * 2005-03-25 2009-12-08 Netapp, Inc. Apparatus and method for data replication at an intermediate node
US7209990B2 (en) * 2005-04-05 2007-04-24 Oracle International Corporation Maintain fairness of resource allocation in a multi-node environment
US7752625B2 (en) * 2005-06-17 2010-07-06 International Business Machines Corporation Caching resources requested by applications
US7596712B1 (en) * 2006-03-23 2009-09-29 Network Appliance, Inc. Method and system for efficiently accessing a storage redundancy group
US8296269B2 (en) * 2006-05-12 2012-10-23 Oracle International Corporation Apparatus and method for read consistency in a log mining system
US20080034053A1 (en) * 2006-08-04 2008-02-07 Apple Computer, Inc. Mail Server Clustering
US7788243B2 (en) * 2006-09-08 2010-08-31 Sybase, Inc. System and methods for optimizing data transfer among various resources in a distributed environment
US8156082B2 (en) * 2006-10-06 2012-04-10 Sybase, Inc. System and methods for temporary data management in shared disk cluster
US7831772B2 (en) * 2006-12-12 2010-11-09 Sybase, Inc. System and methodology providing multiple heterogeneous buffer caches
GB0625330D0 (en) * 2006-12-20 2007-01-24 Ibm System,method and computer program product for managing data using a write-back cache unit
JP2008276456A (ja) * 2007-04-27 2008-11-13 Hitachi Software Eng Co Ltd ファイル管理システム及び方法、並びに携帯端末装置
US8195610B1 (en) * 2007-05-08 2012-06-05 IdeaBlade, Inc. Method and apparatus for cache management of distributed objects
US8914565B2 (en) * 2007-06-08 2014-12-16 Sap Ag Locking or loading an object node
US7975025B1 (en) 2008-07-08 2011-07-05 F5 Networks, Inc. Smart prefetching of data over a network
US20100082560A1 (en) * 2008-09-19 2010-04-01 Sony Computer Entertainment America Inc. Software change management, configuration substitution and remote administration of datacenters
US20100088270A1 (en) * 2008-10-03 2010-04-08 Carsten Ziegler Data versioning concept including time dependency and active and inactive states
US8429134B2 (en) * 2009-09-08 2013-04-23 Oracle International Corporation Distributed database recovery
US8510334B2 (en) * 2009-11-05 2013-08-13 Oracle International Corporation Lock manager on disk
US8527460B2 (en) * 2010-02-19 2013-09-03 Jason Laurence Noble Method for carrying out database version control
US9026510B2 (en) * 2011-03-01 2015-05-05 Vmware, Inc. Configuration-less network locking infrastructure for shared file systems
JP5772458B2 (ja) * 2011-09-29 2015-09-02 富士通株式会社 データ管理プログラム、ノード、および分散データベースシステム
US9342411B2 (en) 2012-10-22 2016-05-17 International Business Machines Corporation Reducing memory overhead of highly available, distributed, in-memory key-value caches
US9311014B2 (en) 2012-11-29 2016-04-12 Infinidat Ltd. Storage system and methods of mapping addresses of snapshot families
US9146877B2 (en) * 2012-11-29 2015-09-29 Infinidat Ltd. Storage system capable of managing a plurality of snapshot families and method of snapshot family based read
US9330055B2 (en) * 2013-06-04 2016-05-03 International Business Machines Corporation Modular architecture for extreme-scale distributed processing applications
US9767178B2 (en) 2013-10-30 2017-09-19 Oracle International Corporation Multi-instance redo apply
JP5800058B2 (ja) * 2014-05-26 2015-10-28 富士通株式会社 情報処理装置、制御方法および制御プログラム
US10599630B2 (en) 2015-05-29 2020-03-24 Oracle International Corporation Elimination of log file synchronization delay at transaction commit time
US10698829B2 (en) 2015-07-27 2020-06-30 Datrium, Inc. Direct host-to-host transfer for local cache in virtualized systems wherein hosting history stores previous hosts that serve as currently-designated host for said data object prior to migration of said data object, and said hosting history is checked during said migration
US10169138B2 (en) 2015-09-22 2019-01-01 Walmart Apollo, Llc System and method for self-healing a database server in a cluster
US10268744B2 (en) * 2015-09-22 2019-04-23 Walmart Apollo, Llc System for maintaining consistency across a decentralized database cluster and method therefor
US10394817B2 (en) 2015-09-22 2019-08-27 Walmart Apollo, Llc System and method for implementing a database
US10083201B2 (en) * 2015-09-22 2018-09-25 Walmart Apollo, Llc System for maintaining consistency across a decentralized database cluster and method therefor
US10116736B2 (en) 2015-09-22 2018-10-30 Walmart Apollo, Llc System for dynamically varying traffic routing modes in a distributed cluster and method therefor
KR101758558B1 (ko) * 2016-03-29 2017-07-26 엘에스산전 주식회사 에너지 관리 서버 및 그를 갖는 에너지 관리 시스템
US9971645B2 (en) 2016-08-23 2018-05-15 Seagate Technology Llc Auto-recovery of media cache master table data
US10223272B2 (en) 2017-04-25 2019-03-05 Seagate Technology Llc Latency sensitive metadata object persistence operation for storage device
US10459810B2 (en) 2017-07-06 2019-10-29 Oracle International Corporation Technique for higher availability in a multi-node system using replicated lock information to determine a set of data blocks for recovery
US11126505B1 (en) * 2018-08-10 2021-09-21 Amazon Technologies, Inc. Past-state backup generator and interface for database systems
US11188516B2 (en) 2018-08-24 2021-11-30 Oracle International Corproation Providing consistent database recovery after database failure for distributed databases with non-durable storage leveraging background synchronization point
US11334445B2 (en) * 2018-10-19 2022-05-17 Oracle International Corporation Using non-volatile memory to improve the availability of an in-memory database
CN113728604B (zh) 2019-02-05 2023-09-08 卡萨系统公司 用于恢复网络关联信息的方法和装置
US11593309B2 (en) * 2020-11-05 2023-02-28 International Business Machines Corporation Reliable delivery of event notifications from a distributed file system

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3039168A1 (de) 1980-10-16 1982-05-13 Agfa-Gevaert Ag, 5090 Leverkusen Fotografisches material, herstellungsverfahren sowie verfahren zur herstellung fotografischer bilder
EP0348628A3 (de) * 1988-06-28 1991-01-02 International Business Machines Corporation Cache-Speicheranordnung
US5193162A (en) * 1989-11-06 1993-03-09 Unisys Corporation Cache memory with data compaction for use in the audit trail of a data processing system having record locking capabilities
US5297269A (en) 1990-04-26 1994-03-22 Digital Equipment Company Cache coherency protocol for multi processor computer system
US5261069A (en) 1990-08-13 1993-11-09 Hewlett-Packard Company Method of maintaining consistency of cached data in a database system
US5276835A (en) 1990-12-14 1994-01-04 International Business Machines Corporation Non-blocking serialization for caching data in a shared cache
US5287473A (en) 1990-12-14 1994-02-15 International Business Machines Corporation Non-blocking serialization for removing data from a shared cache
JPH0827755B2 (ja) 1991-02-15 1996-03-21 インターナショナル・ビジネス・マシーンズ・コーポレイション データの単位を高速度でアクセスする方法
US5280611A (en) 1991-11-08 1994-01-18 International Business Machines Corporation Method for managing database recovery from failure of a shared store in a system including a plurality of transaction-based systems of the write-ahead logging type
US5630124A (en) 1993-12-06 1997-05-13 International Business Machines Corporation System and method for assuring atomicity of distributed update requests in a parallel database
JPH08185359A (ja) 1994-10-31 1996-07-16 Toshiba Corp メモリサブシステム
US5680576A (en) 1995-05-05 1997-10-21 Silicon Graphics, Inc. Directory-based coherence protocol allowing efficient dropping of clean-exclusive data
JP3085899B2 (ja) 1995-06-19 2000-09-11 株式会社東芝 マルチプロセッサシステム
JPH0926910A (ja) 1995-07-11 1997-01-28 Canon Inc 情報処理装置及びその方法及び情報処理システム及びその制御方法
US5903910A (en) * 1995-11-20 1999-05-11 Advanced Micro Devices, Inc. Method for transferring data between a pair of caches configured to be accessed from different stages of an instruction processing pipeline
US5832516A (en) 1997-01-21 1998-11-03 Oracle Corporation Caching data in recoverable objects
US5966706A (en) * 1997-02-19 1999-10-12 At&T Corp Local logging in a distributed database management computer system
US6067550A (en) 1997-03-10 2000-05-23 Microsoft Corporation Database computer system with application recovery and dependency handling write cache
US5933849A (en) * 1997-04-10 1999-08-03 At&T Corp Scalable distributed caching system and method
US5987477A (en) * 1997-07-11 1999-11-16 International Business Machines Corporation Parallel file system and method for parallel write sharing
US6256712B1 (en) 1997-08-01 2001-07-03 International Business Machines Corporation Scaleable method for maintaining and making consistent updates to caches
US5924096A (en) * 1997-10-15 1999-07-13 Novell, Inc. Distributed database using indexed into tags to tracks events according to type, update cache, create virtual update log on demand
US6279084B1 (en) 1997-10-24 2001-08-21 Compaq Computer Corporation Shadow commands to optimize sequencing of requests in a switch-based multi-processor system
US6052758A (en) * 1997-12-22 2000-04-18 International Business Machines Corporation Interface error detection and isolation in a direct access storage device DASD system
US6353836B1 (en) 1998-02-13 2002-03-05 Oracle Corporation Method and apparatus for transferring data from the cache of one node to the cache of another node
US6085198A (en) * 1998-06-05 2000-07-04 Sun Microsystems, Inc. Integrated three-tier application framework with automated class and table generation

Also Published As

Publication number Publication date
US6411968B2 (en) 2002-06-25
HK1032642A1 (en) 2001-07-27
DE69901291T2 (de) 2002-12-05
US20010047380A1 (en) 2001-11-29
DE69917333D1 (de) 2004-06-17
US20010037326A1 (en) 2001-11-01
DE69901291D1 (de) 2002-05-23
CA2320240C (en) 2006-01-24
HK1041535A1 (en) 2002-07-12
US6564234B2 (en) 2003-05-13
DE69917333T2 (de) 2005-05-12
CA2320240A1 (en) 1999-08-19
US6564230B2 (en) 2003-05-13
AU2672399A (en) 1999-08-30
US20010037342A1 (en) 2001-11-01
US20020016795A1 (en) 2002-02-07
HK1061724A1 (en) 2004-09-30
JP2002503846A (ja) 2002-02-05
US20010042066A1 (en) 2001-11-15
HK1039812A1 (en) 2002-05-10
WO1999041664A1 (en) 1999-08-19
US6609136B2 (en) 2003-08-19
EP1055173B1 (de) 2002-04-17
DE69917342D1 (de) 2004-06-17
DE69918470T2 (de) 2005-08-18
DE69939226D1 (de) 2008-09-11
US6567827B2 (en) 2003-05-20
HK1041534A1 (en) 2002-07-12
US6353836B1 (en) 2002-03-05
US6507853B2 (en) 2003-01-14
AU768747B2 (en) 2004-01-08
DE69917342T2 (de) 2005-05-12
US20010037343A1 (en) 2001-11-01
DE69918470D1 (de) 2004-08-05
DE69929095D1 (de) 2006-01-26
HK1039812B (zh) 2004-10-08
HK1041535B (zh) 2004-10-08
EP1055173A1 (de) 2000-11-29
JP3815967B2 (ja) 2006-08-30
HK1041534B (zh) 2009-04-24

Similar Documents

Publication Publication Date Title
DE69929095T2 (de) Verwaltung eines durch eine Mehrzahl von Knoten benutzten Betriebsmittels
DE69728176T2 (de) Verfahren und gerät das verteilte steuerung von gemeinsamen betriebsmitteln erlaubt
DE60312746T2 (de) Wiederherstellung nach fehlern in datenverarbeitungsanlagen
DE60117818T2 (de) Verwaltung des ersetzens von daten in einem zwischenspeicher auf einem knoten aufgrund von zwischenspeichern anderer knoten
DE4216871C2 (de) Ausführungsordnen zum Sicherstellen der Serialisierbarkeit verteilter Transaktionen
DE112010004947B4 (de) Wiederherstellung einer vollständigen Systemsicherung und inkrementeller Sicherungen unter Verwendung von mehreren gleichzeitigen Datenströmen von Einheiten
DE69722512T2 (de) Mehrrechnersystem mit einem die Anzahl der Antworten enthaltenden Kohärenzprotokoll
CA2460833C (en) System and method for implementing journaling in a multi-node environment
DE69636330T2 (de) Verfahren für On-line- und Echzeit-Datenmigration
DE69724846T2 (de) Mehrweg-Ein/Ausgabespeichersysteme mit Mehrweg-Ein/Ausgabeanforderungsmechanismus
DE60018872T2 (de) System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen
DE602005002532T2 (de) Cluster-datenbank mit ferndatenspiegelung
DE602005004508T2 (de) Speichersystem und Speichersteuerverfahren
DE10311082B4 (de) Elektronikdokumentmanagementverfahren
DE69733305T2 (de) System/Verfahren zur wirkungsvollen Übermittlung von Datenströmen in einem Multimediasystem
DE112010003837T5 (de) Verbundfamilien für eine Verbundauswahl und eine Kooperative Replikation
DE102005006176A1 (de) Transaktionsverarbeitungs-Systeme und -Verfahren, die einen Nicht-Platten-Dauerspeicher verwenden
EP1225511A1 (de) Verfahren und system zur akten-verwaltung in verteilten umgebungen
DE60006121T2 (de) System und verfahren zum synchronisieren von datenkopien in einem rechnersystem
DE112020001089T5 (de) Verbessern von cache-trefferverhältnissen bei ausgewählten datenträgern in einem speichersystem
DE602005005325T2 (de) Schreibsatz-grenzenverwaltung für heterogene speichersteuerungen bei der unterstützung einer asynchronen aktualisierung von sekundärspeicherung
DE112018006357T5 (de) Verwaltung von daten, die bei fernkopiervorgängen über eine busschnittstelle in eine speichersteuereinheit geschrieben werden
DE112007002327T5 (de) Persistente Sperren auf Ressourcen zur Steuerung der Nebenläufigkeit
EP1162539B1 (de) Rückgewinnung von Daten von einem oder mehreren fehlerhaften Caches
DE102005036291B9 (de) Verfahren zum Speichern von Wiederherstelldaten in einem System

Legal Events

Date Code Title Description
8327 Change in the person/name/address of the patent owner

Owner name: ORACLE INTERNATIONAL CORP., REDWOOD SHORES, CALIF.

8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: DENDORFER & HERRMANN PATENTANWAELTE PARTNERSCHAFT,