DE602004006404T2

DE602004006404T2 - Flashback-datenbank

Info

Publication number: DE602004006404T2
Application number: DE602004006404T
Authority: DE
Inventors: J. William Redwood Shores LEE; Juan Redwood City LOAIZA; Michael Belmont STEWART; Wei Palo Alto HU; William Alameda BRIDGE
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2003-04-30
Filing date: 2004-03-31
Publication date: 2008-01-10
Anticipated expiration: 2024-04-01
Also published as: DE602004006404D1; US7631018B2; CA2521552C; CN101221573B; AU2004237061A1; JP4594928B2; CN101221573A; EP1618475B1; JP2006525599A; HK1083652A1; EP1618475A2; US20070244918A1; CN1781081A; WO2004100020A3; WO2004100020A2; AU2004237061B2; CA2521552A1; US20040220961A1; CN100375048C; US7181476B2

Description

GEBIET DER ERFINDUNG
Die Erfindung betrifft Datenverwaltungssysteme und insbesondere Verfahren zum Wiederherstellen eines Satzes von Daten in einem früheren Zustand.
HINTERGRUND DER ERFINDUNG
Es gibt eine beliebige Anzahl von Problemen, die bei der Benutzung eines Computers auftreten können. Zwei allgemeinen Kategorien von Fehlern beinhalten computerbedingte Fehler und bedienpersonbedingte Fehler. Aufgrund des unterschiedlichen Charakters dieser zwei Fehlertypen ist ein Verfahren, das zum Beheben computerbedingter Fehler gestaltet ist, nicht notwendigerweise zum Beheben von durch eine Bedienperson verursachten Fehlern anwendbar.
Beispielsweise beinhaltet ein Verfahren, das verwendet wird, um eine Datenbank nach einem computerbedingten Fehler (wie beispielsweise einer Betriebsstörung eines Knotens oder Prozesses) wiederherzustellen, dass Operationsprotokolle geführt werden. Insbesondere wird ein Redo-Protokoll (Erneut-Ausführungs-Protokoll) geführt, so dass Änderungen, die im flüchtigen Speicher durch Transaktionen vorgenommen wurden, die vor einer Betriebsstörung abgeschlossen waren, nach der Betriebsstörung in der Datenbank dauerhaft gespeichert werden können. In ähnlicher Weise wird ein Undo-Protokoll (Rückgängigmachungs-Protokoll) geführt, so dass Änderungen, die bei Transaktionen dauerhaft gespeichert wurden, die nicht vor der Betriebsstörung abgeschlossen wurden, aus der Datenbank nach der Betriebsstörung entfernt werden können.
Das zuvor beschriebene protokollbasierte Wiederherstellungsverfahren ist nicht mit dem Problem bedienpersonbedingter Fehler befasst, da sich diese Fehler in Änderungen widerspiegeln, die durch die abgeschlossenen Transaktionen erfolgt sind. Sogar wenn eine abgeschlossene Transaktion, die einen bedienpersonbedingten Fehler widerspiegelt, von einem computerbedingten Fehler gefolgt wird, gewährleistet die protokollbasierte Wiederherstellungsoperation lediglich, dass diese fehlerhaft abgeschlossenen Änderun gen nach der Behebung des computerbedingten Fehlers weiterhin von der Datenbank widergespiegelt werden. Somit wird bei Fehlerbehebungsverfahren für computerbedingte Fehler darauf abgezielt, dass zwischen abgeschlossenen Änderungen und nicht-abgeschlossenen Änderungen unterschieden wird, und nicht zwischen korrekt abgeschlossenen Änderungen und fehlerhaft abgeschlossenen Änderungen.
Im Gegensatz zu Fehlerbehebungsverfahren für computerbedingte Fehler liegt bei Fehlerbehebungsverfahren für bedienpersonbedingte Fehler der Fokus darauf, dass aus der Datenbank sowohl abgeschlossene als auch nicht-abgeschlossene Änderungen entfernt werden. Insbesondere liegt bei Fehlerbehebungsverfahren für bedienpersonbedingte Fehler typischerweise der Schwerpunkt darauf, dass die Datenbank in einen konsistenten Zustand zurückversetzt wird, der zu einem speziellen Zeitpunkt in der Vergangenheit (vorzugsweise vor dem Zeitpunkt der Durchführung der Transaktion, die den bedienpersonbedingten Fehler enthielt) bestanden hat. Beispielsweise beinhaltet ein Fehlerbehebungsverfahren für einen bedienpersonbedingten Fehler, dass eine Sicherheitskopie (Backup) der Datenbank zu einem speziellen Zeitpunkt erstellt wird. Falls ein bedienpersonbedingter Fehler nach diesem Zeitpunkt eingebracht wird, kann der bedienpersonbedingte Fehler dadurch "entfernt" werden, dass man ein 'Zurückstellen' auf die Sicherungskopie der Datenbank durchführt.
Selbstverständlich ist es einem Datenbankadministrator selten im Vorfeld bekannt, dass bald ein bedienpersonbedingter Fehler eingebracht werden wird. Falls zu viel Zeit zwischen der letzten Backupoperation und dem Zeitpunkt des Fehlers verstrichen ist, ist es möglicherweise sehr unpraktisch und ineffizient, auf die Backup-Datenbank zurückzustellen und dann wieder alle Änderungen neu einzubringen, die auf die Backup-Operation folgend, jedoch vor Auftreten des Fehlers erfolgten.
Ein weiteres Verfahren beinhaltet das Führen einer "Spiegel"-Datenbank, deren Zustand relativ zur Primärdatenbank "nacheilt" (verzögert ist). Im Fall eines anwenderbedingten Fehlers kann man auf die Spiegel-Datenbank zurückgreifen. Falls jedoch die Zeit, die bis zur Entdeckung des Fehlers benötigt wird, größer als die Länge des Nacheilens ist, wird sogar in der nacheilenden Spiegel-Datenbank den Fehler widergespiegelt. Weiter ver bessert zwar eine lange Nacheilzeit die Wahrscheinlichkeit, dass der Fehler rechtzeitig erkannt wird, jedoch vergrößert dies auch die Ineffizienz, die mit einem Failover (= einem bei einer Betriebsstörung erfolgenden Umschalten) auf eine Spiegel-Datenbank einhergeht.
Eine Variation des Nacheil-Spiegelverfahrens beinhaltet das Führen von mehreren Nacheil-Spiegeldatenbanken, wobei jede Spiegeldatenbank eine unterschiedliche Nacheil-Zeitlänge aufweist. Die Verwendung mehrerer Spiegel-Datenbanken mit unterschiedlichen Nacheillängen vergrößert die Wahrscheinlichkeit, dass mindestens eine Spiegel-Datenbank einen Zustand repräsentiert, der vor, jedoch nicht weit vor dem Zeitpunkt des Auftretens des Fehlers liegt. Jedoch verbraucht das Führen derartiger Spiegel-Datenbanken mehr Ressourcen als möglicherweise für diesen Zweck zur Verfügung stehen.
Ein alternatives Verfahren beinhaltet das Speichern der Datenbank auf einem Speichersubsystem, das "Snapshots" (Speicherauszüge) unterstützt, und dann das Verwenden des Speicherauszugmechanismus des Subsystems, um das Speichersubsystem auf einen zeitlich vor dem Fehler liegenden Speicherauszug-Zeitpunkt zurückzustellen. Beispielsweise kann ein Speichersubsystem einen speziellen "Speicherauszug-Zeitpunkt" T5 einrichten. Nach T5 wird jede Änderung an einem Block des Subsystems dadurch gehandhabt, dass (1) bestimmt wird, ob der Block nach T5 bereits geändert wurde, und falls nicht, dann (2), bevor die Änderung am Block vorgenommen wird, die Vor-Änderungs-Version des Blockes aus dem Subsystem ausgelesen wird und diese in einen speziellen separaten Speicherauszug-Speicher kopiert wird, der dem T5-Speicherauszug zugeordnet ist. Unter Verwendung dieses Verfahrens kann das Speichersubsystem auf den Zustand zurückgestellt werden, in welchem es zum Zeitpunkt T5 vorlag, und zwar dadurch, dass man die Blöcke aus dem T5-Speicherauszug-Speicher über ihre korrespondierenden Blöcke des Speichersubsystems zurückkopiert.
Weiter kann, sogar ohne das Speichersubsystem in seinen früheren Zustand zurückzustellen, ermöglicht werden, dass Prozesse und Transaktionen den Zustand des Subsystems zum Zeitpunkt T5 ersehen können, dadurch, dass das Folgende durchgeführt wird, wenn der Prozess oder die Transaktion einen speziellen Block einsehen möchte: (1) Bereitstellen einer Kopie des speziellen Blockes aus dem T5-Speicherauszug-Speicher, falls sich eine Kopie des speziellen Blockes im T5-Speicherauszug-Speicher befindet, und (2) Bereitstellen der Kopie des speziellen Blockes aus dem Speichersubsystem lediglich dann, wenn sich keine Kopie des Blockes im T5-Speicherauszug-Speicher befindet.
Das Speicherauszug-Verfahren stellt genaue Ergebnisse bereit, jedoch geht dies damit einher, dass allen Schreiboperationen eine potentiell beträchtliche Menge an Overhead auferlegt wird. Speziell muss nach jedem Speicherauszug-Zeitpunkt bei der ersten Aktualisierung eines beliebigen Blockes das zeitlich vor der Aktualisierung liegende Abbild (Image) des Blockes ausgelesen werden und dann in einen geeigneten Speicherauszug-Speicher geschrieben werden. Weiter ist, wenn der Datenbankadministrator das Speichersubsystem auf einen früheren Zustand zurückstellen muss, der Administrator auf lediglich diejenigen Zustände eingeschränkt, bei denen explizit ein Speicherauszug-Zeitpunkt eingerichtet wurde.
Ein bedienpersonbedingter Fehler ist lediglich einer der Fehlertypen, die sich nicht ohne Weiteres durch Anwenden eines physiologischen Undo (physiologisches Rückgängigmachen) entfernen lassen. Beispielsweise können Schwierigkeiten auftreten, wenn versucht wird, bei einer Korruption logischer Daten eine Wiederherstellung vorzunehmen. Beispielsweise können derartige Korruptionen einfach durch "Replay" behoben werden, ähnlich wie bei bedienpersonbedingten Fehlern, wenn ein Redo erneut verwendet wird.
Basierend auf dem zuvor Beschriebenen ist es offensichtlich anzustreben, einen Mechanismus und ein Verfahren bereitzustellen, um bei durch "Replay" behebbaren Fehlern eine Fehlerbehebung in einer Weise vorzunehmen, bei der nicht die Probleme in Bezug auf Effizienz oder Ressourcenverbrauch auftreten, die den in diesem Abschnitt beschriebenen Lösungsansätzen eigen sind.
Die in diesem Abschnitt beschriebenen Lösungsansätze sind Lösungsansätze, die man verfolgen könnte, es sind jedoch nicht notwendigerweise Lösungsansätze, die bereits zuvor erdacht oder verfolgt wurden. Daher sollte man, falls nicht anders angegeben, nicht davon ausgehen, dass einer der in diesem Abschnitt beschriebenen Lösungsansätze lediglich dadurch, dass er in diesem Abschnitt enthalten ist, als Stand der Technik gilt.
US 2002/0116404 A1 offenbart ein Protokollier-Verfahren, das verwendet wird, um bei einer Betriebsstörung in einem Transaktionssystem eine Wiederherstellung vorzunehmen. Vor und nach einer Aktualisierung wird ein zeitlich vor dieser liegendes und ein zeitlich nach dieser liegendes Abbild einer Primärdatenbank erstellt, und es wird ein differentielles Protokoll mittels einer XOR-Operation zwischen dem zeitlich davor liegenden Abbild und dem zeitlich danach liegenden Abbild erzeugt. Eine Redo-Operation oder eine Undo-Operation werden durch Verwenden der XOR-Operation zwischen einem oder mehreren differentiellen Protokollen und dem zeitlich davor liegenden Abbild durchgeführt.
US-Patent Nr. 5,983,361 offenbart eine Wiederherstellungsfunktion, bei der ein Prüfpunkt verwendet wird. Das Auftreten von "schwebenden" (dangling) Transaktionen wird dadurch verhindert, dass ein Transaktionseintrag während des Durchführens eines Redo-Schrittes aus der Transaktionstabelle gelöscht wird, wenn die Transaktion zwischen dem Zeitpunkt, bei dem der Prüfpunktbeginn-Protokolleintrag des letzten vollendeten Prüfpunktes protokolliert wurde, und dem Zeitpunkt beendet wurde, bei dem der Prüfpunktende-Protokolleintrag protokolliert wurde.
US 2003/0061537 A1 offenbart ein paralleles Nur-Redo-Protokollierschema für hochverfügbare Hauptspeicher-Datenbanksysteme. Das Schema kombiniert physisches Protokollieren und wahlweises Zurückspielen von Nur-Redo-Protokolldaten.
Die Erfindung ist durch die anliegenden unabhängigen Ansprüche 1 und 18 definiert.
Die abhängigen Ansprüche betreffen optionale Merkmale einiger Ausführungsformen der Erfindung.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung ist beispielhaft und nicht einschränkend in den Figuren der anliegenden Zeichnungen dargestellt, in denen ähnliche Elemente mit dem gleichen Bezugszeichen bezeichnet sind; in diesen sind:
1A-1C Blockdiagramme, die ein System mit einem Rückblende-Protokoll gemäß einer Ausführungsform der Erfindung darstellen;
2 ein Blockdiagramm, das Gate-Markierungen darstellt, die in ein Rückblende-Protokoll eingebettet sind, gemäß einer Ausführungsform der Erfindung; und
3 ein Blockdiagramm eines Computersystems, bei dem Ausführungsformen der Erfindung implementiert werden können.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Es werden Verfahren beschrieben, um ein Datenlager auf einen früheren Zustand zurückzustellen. In der folgenden Beschreibung sind zur Erläuterungszwecken zahlreiche spezifische Details dargelegt, um für ein gründliches Verständnis der Erfindung zu sorgen. Es versteht sich jedoch, dass die Erfindung ohne diese speziellen Details realisiert werden kann. In anderen Fällen sind bereits bekannte Strukturen und Vorrichtungen in Blockdiagrammform dargestellt, um unnötige Unklarheiten bei der Erfindung zu vermeiden.
FUNKTIONELLER ÜBERBLICK
Hier werden Verfahren beschrieben, um ein Datenlager zu einem früheren Zustand zurückzustellen. Gemäß einer Ausführungsform ist das Datenlager eine Datenbank, und der frühere Zustand ist der konsistente Zustand, den die Datenbank zu einem speziellen Zeitpunkt in der Vergangenheit hatte. Speziell ist der frühere Zustand ein Zustand, bei dem die Datenbank alle Änderungen widerspiegelt, die durch Transaktionen vorgenommen wurden, die vor dem speziellen Zeitpunkt abgeschlossen wurden, und keine der Änderungen widerspiegelt, die durch Transaktionen vorgenommen wurden, welche nicht vor dem speziellen Zeitpunkt abgeschlossen wurden. Bei einer weiteren Ausführungsform handelt es sich bei dem Datenlager um eine oder mehrere Dateien auf einer Platte.
Wenn ein durch eine Bedienperson verursachter Fehler in die Datenbank durch Änderungen eingebracht wurde, die durch eine bereits abgeschlossene Transaktion vorgenommen wurden, können die hier beschriebenen Verfahren verwendet werden, um eine Behebung des Fehlers dadurch durchzuführen, dass die Datenbank auf einem Zeitpunkt zurückgestellt wird, der vor der Durchführungszeit der Transaktion liegt, die den Fehler eingebracht hat. Die Verfahren beinhalten die Erzeugung von physischer Undo-Information (Rückgängigmach-Information), und die Verwendung der physischen Undo-Information in Verbindung mit einem physiologischen Undo und einem physiologischen Redo, um das Datenlager in effizienter Weise auf den früheren Zustand zurückzustellen.
PHYSISCHES UNDO
Ein physisches Undo beinhaltet Information, die benötigt wird, um eine Speichereinheit auf einen früheren Zustand zurückzustellen. Der Begriff "Block" wird hier verwendet, um ein Speichereinheit zu bezeichnen, die bei einem Führen eines physischen Undo als "atomare Einheit" behandelt wird. Die hier beschriebenen Verfahren sind nicht auf Blöcke irgendeiner speziellen Größe oder Granularität beschränkt.
Gemäß einer Ausführungsform ist das physische Undo für einen Block ein 'Vor-Aktualisierungs-Abbild' (= zeitlich vor einer Aktualisierung liegendes Abbild) des Blockes. Das Vor-Aktualisierungs-Abbild eines aktualisierten Blockes kann verwendet werden, um den aktualisierten Block auf einen vor der Aktualisierung liegenden Zustand zurückzustellen, dadurch, dass der aktualisierte Block mit dem Vor-Aktualisierungs-Abbild des Blockes überschrieben wird. Jedoch stellt ein Vor-Aktualisierungs-Abbild lediglich eine von möglichen Formen von Information dar, die verwendet werden können, um eine Speichereinheit auf einen früheren Zustand zurückzustellen, und die hier beschriebenen Verfahren sind nicht auf irgendeine spezielle Form eines physischen Undo eingeschränkt.
Bei Verwendung der hier beschriebenen Verfahren hat jede Operation, die einen aktualisierten Block auf eine Platte schreibt, nicht den zusätzlichen 'Overhead' einer Platten-Leseoperation zur Folge, um ein Vor-Aktualisierungs-Abbild des Blockes zu erzielen. Vielmehr hält, wenn Aktualisierungen von einem Datenbank-Server durchgeführt werden, der Datenbank-Server für gewöhnlich bereits eine Kopie des Blockes im flüchtigen Speicher. Somit kann die Erzeugung eines physischen Undo beinhalten, dass vor dem Aktualisieren der ersten Kopie eine zweite Kopie des Blockes im flüchtigen Speicher erzeugt wird. Wie später noch detaillierter beschrieben wird, wird die zweite Vor-Aktualisierungs-Kopie zu einem späteren Zeitpunkt auf die Platte geschrieben, jedoch nicht später als zu dem Zeitpunkt, bei dem das aktualisierte Abbild des Blockes auf die Platte geschrieben wird.
PHYSIOLOGISCHES UNDO
Ein physiologisches Undo beinhaltet Informationen, die benötigt werden, um einzelne logische Informationen in einem früheren Zustand wiederherzustellen. Beispielsweise kann in einem relationalen Datenbanksystem, wenn eine Zeile einer Tabelle aktualisiert wird, ein physiologischer Undo-Eintrag erzeugt werden. Bei diesem Szenario enthält der physiologische Undo-Eintrag Information, um die Zeile auf ihren vor der Aktualisierung bestehenden Zustand zurückzustellen, er halt jedoch möglicherweise keine Information über den Zustand weiterer Datenelemente, die möglicherweise in demselben Datenblock wie die aktualisierte Zeile liegen.
Im Vergleich zum physiologischen Undo hat ein physisches Undo einen Vorteil. Die Anwendung eines physischen Undo gelingt immer, da für diesen keine Prämisse betreffend das Vor-Anwendungs-Abbild erforderlich ist. Daher kann ein physisches Undo logische Datenkorruptionen immer vermeiden. Andererseits kann die Anwendung eines physiologischen Undo fehlschlagen, falls das Vor-Anwendungs-Abbild nicht in sich konsistent ist. Ein Block kann aufgrund von Speicherkorruption, Softwarefehlern etc. in sich inkonsistent werden.
PHYSIOLOGISCHES REDO
Ähnlich dem physiologischen Undo ist im physiologischen Redo Information betreffend Änderungen an logischen Datenelementen gespeichert. Während im physiologischen Undo Information gespeichert ist, wie Änderungen am logischen Datenelement rückgängig zu machen sind, ist jedoch im physiologischen Redo Information gespeichert, wie Änderungen am logischen Datenelement erneut durchzuführen sind. Ein physiologisches Redo wird u. a. verwendet, um Änderungen erneut durchzuführen, die durch abgeschlossene Transaktionen erfolgt sind, wobei diese Änderungen zu dem Zeitpunkt, bei dem ein computerbedingter Fehler auftrat, noch nicht im dauerhaften Speicher gespeichert waren.
Viele Datenbanksysteme führen (verwalten) ein physisches Undo und physisches Redo zum Beheben computerbedingter Fehler, wie zuvor beschrieben wurde. Ein Beispiel eines physiologischen Redo- und Undo-Mechanismus ist im US-Patent Nr. 5,850,507 mit dem Titel "Method and Apparatus for Improved Transaction Recovery" beschrieben. Jedoch sind die hier beschriebenen Verfahren nicht auf irgendeinen speziellen Mechanismus zum Führen eines physiologischen Redo und Undo eingeschränkt.
ZWEI-PHASEN-WIEDERHERSTELLUNG
Gemäß einer Ausführungsform der Erfindung wird ein Datenlager in zwei Phasen auf einen früheren Zustand zurückgestellt, die hier als "physische Wiederherstellungsphase" und "physiologische Wiederherstellungsphase" bezeichnet werden. Beispielsweise sei angenommen, dass ein Benutzer ein Datenlager auf den Zustand zurückstellen möchte, der zu einem speziellen Zeitpunkt (der "Zielzeit") vorlag. Während der physischen Wiederherstellungsphase wird das physische Undo verwendet, um alle dem Datenlager zugeordneten Blöcke der Platte auf ihren physischen Zustand auf einen Zeitpunkt (den "physischen Wiederherstellungszeitpunkt") zurückzustellen. Während der physiologischen Wiederherstellungsphase wird das physiologische Redo und Undo verwendet, um die im Datenlager befindliche logische Information aus ihrem nach der physischen Wiederherstellung bestehenden Zustand in einen konsistenten Zustand zu bringen, der dem Zielzeitpunkt zugeordnet ist.
Es sei angemerkt, dass, sogar wenn der physische Wiederherstellungszeitpunkt der Zielzeitpunkt ist, die physiologische Wiederherstellungsphase weiter erforderlich sein kann, um die in den Blöcken befindlichen logischen Daten in einen konsistenten Zustand zurückzubringen. Beispielsweise kann, zu einem Zeitpunkt T5, (1) ein gegebener Block Änderungen einschließen, die durch Transaktionen erfolgt sind, die zum Zeitpunkt T5 noch nicht abgeschlossen sind, und (2) in ihm Änderungen fehlen, die durch Transaktionen erfolgt sind, die bereits vor T5 abgeschlossen wurden. Somit erfolgt durch das Zurückstellen des Blockes auf seinen physischen Zustand zum Zeitpunkt T5 nicht notwendigerweise ein Zurückstellen der in dem Block befindlichen logischen Datenelemente in ihren konsistenten Zustand zum Zeitpunkt T5. Somit wird ein physiologisches Redo angewendet, um zum Abbild des Blockes zum Zeitpunkt T5 jegliche fehlende Änderungen hinzuzufügen, die durch Transaktionen erfolgt sind, die vor T5 abgeschlossen wurden. In ähnlicher Weise wird ein physiologisches Undo angewendet, um aus dem physischen Abbild zum Zeitpunkt T5 des Blockes jegliche Änderungen zu entfernen, die durch Transaktionen erfolgt sind, die bis zum Zeitpunkt T5 nicht abgeschlossen wurden.
GATES
Gemäß einer Ausführungsform führt das System, das ein Datenlager verwaltet, ein Einrichten spezieller Zeitpunkte, hier als "Gates" bezeichnet, durch, für welche ein physisches Undo erzeugt werden soll. Zum Zweck der Erläuterung sei angenommen, dass das Datenlager eine Datenbank ist. Bei einer derartigen Ausführungsform handelt es sich bei dem System, welches das Datenlager verwaltet und die Gates einrichtet, um einen Datenbank-Server.
Das physische Undo, das für ein Gate erzeugt wird, wird verwendet, um die Blöcke, die das Datenlager speichert, in den physischen Zustand zurückzustellen, in welchem diese zu dem dem Gate zugeordneten Zeitpunkt vorlagen. Beispielsweise weist, wenn ein Gate G1 für einen Zeitpunkt T5 eingerichtet wird, dann das physische Undo für das Gate G1 Informationen auf, um Blöcke in den physischen Zustand zurückzustellen, in welchem diese zu dem Zeitpunkt oder vor dem Zeitpunkt T5 vorlagen. Bei einer Ausführungsform beinhaltet das physische Undo für G1 die Vor-Aktualisierungs-Abbilder aller Blöcke, die nach T5 aktualisiert wurden. Das Vor-Aktualisierungs-Abbild eines Blockes enthält alle Daten des Blockes, obwohl bei der Aktualisierung möglicherweise lediglich ein einziger von mehreren im Block gespeicherten logischen Datenelementen verändert wird. Somit können die Blöcke des Datenlagers einfach dadurch in ihren physischen Zustand zum Zeitpunkt T5 zurückgestellt werden, dass die aktualisierte Version der Blöcke mit ihren entsprechenden Vor-Aktualisierungs-Abbildern überschrieben wird.
Gemäß einer Ausführungsform wird das physische Redo für ein Gate dadurch eingerichtet, dass die Vor-Aktualisierungs-Abbilder von Blöcken gespeichert werden, wenn diese das erste Mal nach dem dem Gate zugeordneten Zeitpunkt aktualisiert werden. Speziell wird ein Vor-Aktualisierungs-Abbild ansprechend auf jegliche Aktualisierung erzeugt, die (1) nach dem Gate-Zeitpunkt erfolgt, und (2) bei einem beliebigen Block erfolgt, bei dem seit dem Gate keine vorhergehende Aktualisierung erfolgt ist. Derartige Aktualisierungen werden hier als "Erste-nach-Gate-Aktualisierungen" bezeichnet.
Beispielsweise sei das Gate G1 betrachtet, das dem Zeitpunkt T5 zugeordnet ist. Es sei angenommen, dass ein Block nach T5 aktualisiert wird. Falls der Block nach T5 bereits aktualisiert wurde, dann ist die Aktualisierung keine Erste-nach-Gate-Aktualisierung, und es wird ansprechend auf die Aktualisierung kein physisches Undo für G1 erzeugt. Falls andererseits die Aktualisierung des Blockes das erste Mal nach T5 erfolgt, dann ist die Aktualisierung eine Erste-nach-Gate-Aktualisierung, und ein Vor-Aktualisierungs-Abbild des Blockes wird als physisches Undo für das Gate G1 erzeugt.
Eine Vielzahl von Verfahren kann verwendet werden, um zu ermitteln, welche Aktualisierungen Erste-nach-Gate-Aktualisierungen darstellen. Beispielsweise kann ein Zeitstempel im Block-Header eines jeden Blockes platziert werden, um den letzten Zeitpunkt zu bezeichnen, bei der die Aktualisierung des Blockes erfolgt ist. Falls der Zeitstempel im Block-Header eines Blockes, der gerade aktualisiert wird, größer als der Zeitstempel des Gate ist, dann ist durch einige Prozesse bereits mindestens einmal nach dem Gate eine Aktualisierung des Blockes erfolgt, so dass es sich bei der aktuellen Aktualisierung nicht um eine Erste-nach-Gate-Aktualisierung handelt. Wenn andererseits der Zeitstempel im Block-Header des Blockes, dessen Aktualisierung gerade durchgeführt wird, niedriger ist als der Zeitstempel des Gate, dann ist die aktuelle Aktualisierung eine Erste-nach-Gate-Aktualisierung. Alternativ können Daten im flüchtigen Speicher gespeichert werden, um anzugeben, welche Blöcke seit dem am kürzesten zurückliegenden Gate bereits aktualisiert wurden. Die Erfindung ist nicht auf irgendein spezielles Verfahren zur Ermittlung, welche Aktualisierungen Erste-nach-Gate-Aktualisierungen darstellen, eingeschränkt.
DAS RÜCKBLENDE-PROTOKOLL
Gemäß einer Ausführungsform werden die physischen Undo-Datensätze für Gates als Einträge in einem "Rückblende-Protokoll" gespeichert. Wie später noch detaillierter beschrieben wird, kann ein einziges Rückblende-Protokoll verwendet werden, um Vor-Aktualisierungs-Abbilder zu speichern, die vielen Gates zugeordnet sind, wobei Markierungen verwendet werden, um Positionen im Rückblende-Protokoll mit spezifischen Gates zu korrelieren.
1a stellt ein System 100 dar, auf das Bezug genommen wird, um Verfahren zur Verwaltung des physischen Undo zu erläutern, gemäß einer Ausführungsform der Erfindung. Bezug nehmend auf 1a beinhaltet das System 100 einen flüchtigen Speicher 102 und einen nichtflüchtigen Speicher 104. Der nichtflüchtige Speicher 104 beinhaltet ein Datenlager 112 zum Speichern von Daten. Das Datenlager 112 kann dann beispielsweise eine Datenbank sein, die von einem Datenbank-Server verwaltet wird, und die hier beschriebenen Operationen, um das physische Undo zu verwalten, zu pflegen und zu verwenden, können automatisch durch im Datenbank-Server stattfindende Prozesse durchgeführt werden. Jedoch sind die hier beschriebenen Verfahren auf einen beliebigen Typ von Datenlager anwendbar, bei dem ein Zurückversetzen in einen früheren Zustand erforderlich sein kann, und diese sind daher nicht auf den Kontext der herkömmlichen Datenbank-Server eingeschränkt.
Zusätzlich zum Datenlager 112 beinhaltet der nichtflüchtige Speicher 104 ein Rückblende-Protokoll 106. Das Rückblende-Protokoll 106 speichert Einträge (z. B. Einträge 140, 142, 144), die (1) Blöcken im Datenlager 112 entsprechen, und (2) Informationen beinhalten, um die entsprechenden Blöcke auf einen früheren Zustand zurückzustellen. Gemäß einer Ausführungsform enthält jeder Eintrag im Rückblende-Protokoll 106 ein Vor-Aktualisierungs-Abbild eines entsprechenden Blockes im Datenlager 112.
Der flüchtige Speicher 102 beinhaltet einen Block-Cachespeicher 110 und einen Rückblende-Protokoll-Cachespeicher 108. Der Block-Cachespeicher 110 enthält Kopien von Blöcken aus dem Datenlager 112. Beispielsweise wird für einen Prozess, um ein Datenelement aus dem Block 120 des Datenlagers 112 auszulesen, eine Kopie 122 des Blockes 120 in den Block-Cachespeicher 110 des flüchtigen Speichers 102 geladen. Wenn der Prozess dann das Datenelement aktualisiert, wird die Aktualisierung anfänglich in der im Cachespeicher befindlichen Kopie 122 des Blockes 120 widergespiegelt, und nicht im Block 120, der im nichtflüchtigen Speicher 104 liegt.
Der flüchtige Speicher 102 beinhaltet weiter einen Rückblende-Protokoll-Cachespeicher 108. Der Rückblende-Protokoll-Cachespeicher 108 speichert Rückblende-Protokolleinträge (z. B. Einträge 130, 132 und 134), die erzeugt wurden, die jedoch noch nicht in den nichtflüchtigen Speicher 104 geschrieben wurden. Wenn beispielsweise ein Kopie 122 des Blockes 120 gerade modifiziert wird, kann es erforderlich sein, einen Rückblende-Protokolleintrag (z. B. einen Eintrag 136 in 1B) zu erzeugen, der das Vor-Aktualisierungs-Abbild des Blockes 120 enthält. Der Rückblende-Protokolleintrag wird zu Anfang im Rückblende-Protokoll-Cachespeicher 108 gespeichert, und später in das Rückblende-Protokoll 106 im nichtflüchtigen Speicher 104 geschrieben. In 1C wurde ein Eintrag 146 dem Rückblende-Protokoll 106 hinzugefügt, ansprechend auf das Schreiben des Eintrags 136 in den nichtflüchtigen Speicher 104.
VORWEGNEHMENDE ERZEUGUNG EINES PHYSISCHEN UNDO
In der zuvor beschriebenen Ausführungsform wird ein Rückblende-Protokolleintrag ansprechend auf jede Aktualisierung erzeugt, die (1) nach einem Gate und (2) bei einem Block vorgenommen wird, der nach dem Gate bisher nicht aktualisiert wurde. Unglücklicherweise führt dieses Verfahren zu einer "Spitze" bei der Anzahl von Rückblende-Protokolleinträgen, die unmittelbar nach einem beliebigen gegebenen Gate erzeugt werden müssen. Insbesondere sind praktisch alle Aktualisierungen, die unmittelbar nach dem Durchlaufen eines Gate auftreten, Erste-nach-Gate-Aktualisierungen. Somit beträgt unmittelbar nach einem Gate der Prozentsatz von Aktualisierungsoperationen, die eine Erzeugung von Rückblende-Protokolleinträgen erfordern, praktisch 100 %. Nach der anfänglichen Spitze nimmt der Prozentsatz von Aktualisierungen ab, die eine Erzeugung von Rückblende-Protokolleinträgen erfordern, da ein größerer Prozentsatz der Aktualisierungen bei Blöcken erfolgt, bei denen nach dem Gate bereits eine Aktualisierung erfolgt ist.
Gemäß einer Ausführungsform wird die Größe der Spitze durch ein Durchführen einer vorauseilenden Erzeugung eines physischen Undo verringert. Insbesondere werden Rückblende-Protokolleinträge für Aktualisierungen erzeugt, bei denen es sich nicht um Erste-nach-Gate-Aktualisierungen handelt. Vielmehr werden diese für ein Gate sogar vor dem Zeitpunkt erzeugt, der dem Gate zugeordnet ist. Derartige Rückblende-Protokolleinträge, die hier als "vorweggenommene Einträge" bezeichnet werden, verringern die Spitze, die auftritt, wenn das Gate erreicht wird, da keine zusätzlichen Rückblende-Protokolleinträge für die Erste-nach-Gate-Aktualisierungen bei Blöcken erzeugt werden brauchen, die vorwegnehmende Einträge aufweisen.
Gemäß einer Ausführungsform wird ein Vorwegnahme-Gate vor einem eigentlichen Gate eingerichtet. Jedoch bewirkt, anders als bei eigentlichen Gates, die erste Aktualisierung, die bei einem Block nach einem Vorwegnahme-Gate vorgenommen wird, nicht automatisch eine Erzeugung eines Rückblendeeintrags. Vielmehr ist eine Erzeugung eines Rückblendeeintrags nach einem Vorwegnahme-Gate optional. Ob unter diesen Umständen ein Eintrag erzeugt wird, kann von einer Vielzahl von Faktoren abhängigen, wie beispielsweise der Arbeitsbelastung des Systems und der Verfügbarkeit von Ressourcen. Beispielsweise kann die Tatsache, ob ein Rückblendeeintrag ansprechend auf eine Aktualisierung erzeugt wird, die nach einem Vorwegnahme-Gate vorgenommen wird, davon abhängen, wie viel Platz aktuell im Rückblende-Protokoll-Cachespeicher 108 zur Verfügung steht. Als weiteres Beispiel kann das System einfach Rückblendeeinträge für einen gewissen Prozentsatz, beispielsweise von 50 % aller Erste-nach-Vorwegnahme-Gate-Aktualisierungen, erzeugen. Diese Faktoren sind lediglich Beispiele für Faktoren, die verwendet werden können, um zu bestimmen, ob ein Rückblendeeintrag für eine Aktualisierung nach einem Vorwegnahme-Gate erzeugt wird. Die hier beschriebenen Verfahren sind nicht auf irgendeinen speziellen Satz von Faktoren eingeschränkt.
Wenn ein Vorwegnahme-Rückblendeeintrag für ein Gate erzeugt wurde, spiegelt möglicherweise der Vorwegnahme-Rückblendeeintrag nicht den Zustand des entsprechenden Blocks zu dem dem Gate zugeordneten Zeitpunkt wider. Beispielsweise sei angenommen, dass G1 dem Zeitpunkt T5 zugeordnet ist, und dass ein Vorwegnahme-Gate für G1 zum Zeitpunkt T3 publiziert wird. Alle Vorwegnahme-Rückblendeeinträge, die zwischen T3 und T5 erzeugt werden, spiegeln den Zustand von Blöcken zu irgendeinem Zeitpunkt zwischen T3 und T5 wider, und nicht notwendigerweise den Zustand von Blöcken zum Zeitpunkt T5.
Beispielsweise kann ein Bock B1 zum Zeitpunkt T4 aktualisiert werden, was bewirkt, dass ein Vorwegnahme-Rückblendeeintrag erzeugt wird. Wenn die dem Gate G1 zugeordneten Rückblendeeinträge anschließend verwendet werden, um die Datenbank zum Zeitpunkt T5 zurückzustellen, stellt der Vorwegnahme-Rückblendeeintrag für B1 in Wirklichkeit den Block B1 zurück zum Zeitpunkt T4. Somit ist das Datenlager, wenn Vorwegnahme-Gates verwendet werden, nach der physischen Wiederherstellungsphase "fuzzy" (unscharf). Speziell spiegeln einige Blöcke, nach der physischen Wiederherstellungsphase, ihren physischen Zustand zum Zeitpunkt T5 wider, und andere Blöcke spiegeln ihren physischen Zustand zwischen den Zeitpunkten T3 und T5 wider.
Die Verwendung von Vorwegnahme-Gates ist lediglich ein einziges Beispiel für Verfahren, die eine derartige "Unschärfe" bewirken können. Beispielsweise kann das nachfolgend beschriebene Zweiphasen-Rundsendeverfahren für mehrere Server-Systeme auch zu Vor-Aktualisierungs-Abbildern führen, die Zustände vor dem Zeitpunkt widerspiegeln, der dem entsprechenden Gate zugeordnet ist. Auch kann, wenn ein Gate "gleichzeitig" mit der Erzeugung eines physischen Undo auftritt, dem physischen Undo ein Zeitstempel zugewiesen werden, der zeitlich vor dem Gate liegt. Jedoch wird, ungeachtet ihrer Ursache, diese "Unschärfe" während der der physiologischen Wiederherstellungs- Phase beseitigt, in deren Verlauf alle logischen Datenelemente, egal in welchem Zustand sie aktuell sind, in den Zielzustand zurückgestellt werden.
GATE-MARKIERUNGEN
Wie zuvor erwähnt, werden Rückblendeeinträge zu Anfang in einem Rückblende-Cachespeicher 108 gespeichert, und periodisch in ein Rückblende-Protokoll 108 im nichtflüchtigen Speicher 104 geschrieben. Gemäß einer Ausführungsform wird ein einziges Rückblende-Protokoll 106 für mehrere Gates verwendet, wobei Markierungen (nachfolgend als "Gate-Markierungen" bezeichnet) in das Rückblende-Protokoll 106 eingefügt werden, um den Anfang der Einträge zu bezeichnen, die den einzelnen Gates zugeordnet sind.
2 ist ein Blockdiagramm, das ein Rückblende-Protokoll 200 darstellt, welches gemäß einer Ausführungsform der Erfindung bestückt wurde. Bezug nehmend auf 2 wird ein Rückblende-Protokoll 200 sequentiell bestückt (in der dargestellten Ausführungsform von links nach rechts), und zwar beim Schreiben von Rückblendeeinträgen aus dem Cache in den dauerhaften Speicher.
Gemäß einer Ausführungsform werden Gate-Markierungen im Rückblende-Protokoll 200 gespeichert, um die Anwendung von Rückblendeeinträgen, die einem gegebenen Gate zugeordnet sind, zu erleichtern. Beim dargestellten Beispiel beinhaltet ein Rückblende-Protokoll 200 eine Gate-Markierung 202, die einem Gate G5 des Zeitpunktes T500 zugeordnet ist, und eine Gate-Markierung 204, die einem Gate G6 des Zeitpunktes T600 zugeordnet ist.
GATE-MARKIERUNGSKETTE
Gemäß einer Ausführungsform sind die verschiedenen Gate-Markierungen im Rückblende-Protokoll 200 miteinander verbunden, so dass sie im Rückblende-Protokoll schnell lokalisiert werden können. Bei der dargestellten Ausführungsform beinhaltet jede Gate-Markierung eine Verknüpfung zu unmittelbar vorhergehenden Gate-Markierungen, und eine Steuerdatei 206 beinhaltet eine Verknüpfung zu der als letztes gespeicherten Gate-Markierung. Wenn eine Verknüpfung in dieser Weise vorliegt, kann jede gegebene Gate-Markierung schnell lokalisiert werden, und zwar dadurch, dass der Verknüpfung in der Steuerdatendatei 206 zur zeitlich letzten Gate-Markierung gefolgt wird, und dann den Verknüpfungen in den Gate-Markierungen zur gewünschten Gate-Markierung gefolgt wird. Beispielsweise wird, um die Gate-Markierung 202 zu lokalisieren, die Verknüpfung in der Steuerdaten 206 verwendet, um die Gate-Markierung 204 zu lokalisieren, und die Verknüpfung in der Gate-Markierung 204 wird verwendet, um die Gate-Markierung 202 zu lokalisieren.
Wenn zum Rückblende-Protokoll 200 eine neue Gate-Markierung hinzugefügt wird, wird die Gate-Markierungskette dadurch gepflegt, dass veranlasst wird, dass die neue Gate-Markierung auf die Gate-Markierung zeigt, auf die im Moment die Steuerdatei zeigt, und dann veranlasst wird, dass die Steuerdatei auf die neu eingefügte Gate-Markierung zeigt. Beispielsweise hätte, wenn dem Rückblende-Protokoll 200 eine neue Gate-Markierung hinzugefügt wird, die neue Gate-Markierung eine Verknüpfung zum Gate 204, und die Aktualisierung der Verknüpfung in der Steuerdaten 206 würde so erfolgen, dass diese auf die neue Gate-Markierung zeigt.
VERWENDUNG DER GATE-MARKIERUNGEN
Gemäß einer Ausführungsform dient die Gate-Markierung für ein spezielles Gate für eine Vielzahl von Zwecken, einschließlich: (1) Markieren eines Ortes im Rückblende-Protokoll und (2) Identifizieren eines Ortes in einem physiologischen Redo-Protokoll. Bei einer Ausführungsform bezeichnet der Ort einer Gate-Markierung im Rückblende-Protokoll, wo mit der Verarbeitung von Rückblendeeinträgen zu beginnen ist, um das Datenlager auf den Zeitpunkt zurückzustellen, der dem entsprechenden Gate zugeordnet ist. Beispielsweise würde, um ein Datenlager auf den dem Zeitpunkt T500 zugeordneten physischen Zustand zurückzustellen, das Rückblende-Protokoll 200 beginnend mit dem Eintrag 220 bis hin zum Eintrag 228 am Ende des Rückblende-Protokolls verarbeitet werden. Andererseits könnte, um das Datenlager auf den dem Zeitpunkt T600 zugeordneten physischen Zustand zurückzustellen, das Rückblende-Protokoll 204 beginnend mit dem Eintrag 222 und dann bis zum Eintrag 228 am Ende des Rückblende-Protokolls verarbeitet werden.
Bei einer alternativen Ausführungsform wird ein Pointer in der Gate-Markierung, anstelle der Position der Gate-Markierung selbst, verwendet, um den Ort zu bezeichnen, an dem mit der Verarbeitung des Rückblende-Protokolls für das entsprechende Gate zu beginnen ist. Durch Verwenden eines Pointers zum Bezeichnen des Anfangspunktes im Rückblende-Protokoll ist die Abfolge, in der die Gate-Markierung selbst im Rückblende-Protokoll gespeichert wird, weniger kritisch. Beispielsweise kann ein dem Zeitpunkt T500 zugeordnetes Gate G1 publiziert werden, wenn sich das Rückblende-Protokoll bei Position P1 befindet. Wenn die Position der Gate-Markierung verwendet werden soll, um den Ort zu bezeichnen, bei dem mit der Verarbeitung zu beginnen ist, dann muss irgendein Mechanismus vorgesehen sein, um zu gewährleisten, dass keine G1 zugeordneten Rückblendeeinträge im Rückblende-Protokoll vor der Gate-Markierung für G1 gespeichert sind, so dass die Gate-Markierung für G1 bei Position P1 gespeichert ist. Wenn jedoch ein Pointer verwendet wird, dann können weitere für G1 erzeugte Rückblendeeinträge vor die Gate-Markierung für G1 auf die Platte geschrieben werden. Die Gate-Markierung für G1, die irgendwo im Rückblende-Protokoll nach P1 gespeichert ist, beinhaltet einfach einen Pointer, um die Position P1 zu bezeichnen.
Wenn ein Rückblendeeintrag verarbeitet wird, wird der entsprechende Block des Datenlagers auf das Abbild im Rückblendeeintrag zurückgestellt, es sei denn, der Rückblendeeintrag spiegelt eine Aktualisierung wider, die später als der Zeitpunkt liegt, der dem Gate zugeordnet ist, das verwendet wird, um das Datenlager zurückzustellen. Beispielsweise wird, wenn Rückblendeeinträge 220 und 222 beide dem gleichen Block B1 entsprechen, und das Datenlager auf den dem Gate G5 zugeordneten Zeitpunkt T500 zurückgestellt wird, dann der Block B1 basierend auf dem Rückblendeeintrag 220 zurückgestellt, wird jedoch nicht basierend auf dem Rückblendeeintrag 222 zurückgestellt, da der Rückblendeeintrag eine Aktualisierung widerspiegelt, die nach T500 am Block B1 vorgenommen wurde.
Bei den oben angegebenen Beispielen dienen die Gate-Markierungen dazu, den Ort anzugeben, bei dem mit der Anwendung von Rückblendeeinträgen zu beginnen ist. Bei einer alternativen Ausführungsform können die Rückblendeeinträge in umgekehrter Reihenfolge angewendet werden, beginnend mit dem zeitlich letzten Eintrag und fortschreitend bis zur geeigneten Gate-Markierung (oder dem Ort, der durch einen Pointer in der Gate-Markierung bezeichnet ist). Unter diesen Umständen gibt die Gate-Markierung oder der Pointer an, wo die Verarbeitung der Rückblendeeinträge zu beenden ist. Auch wird, wenn das Rückblende-Protokoll ausgehend vom neuesten bis zum ältesten Eintrag bearbeitet wird, ein Rückblendeeintrag ausgelassen, wenn ein dem Eintrag zugeordneter Zeitstempel neuer als der Zeitpunkt des Gate ist, das zur Wiederherstellung verwendet wird. Beispielsweise wird, falls beide Einträge 220 und 222 demselben Block B1 entsprechen, und das Datenlager zu dem dem Gate G5 zugeordneten Zeitpunkt T500 zurückgestellt wird, der Eintrag 222 ausgelassen, da er einem Zeitstempel zugeordnet ist, der größer als der Zeitpunkt T500 ist. Mit anderen Worten wird der Eintrag 222 ausgelassen, da das Abbild vom Block B1, das im Eintrag 222 widergespiegelt wird, eine Änderung beinhaltet, die nach dem Zeitpunkt T500 vorgenommen wurde. Andererseits würde der Eintrag 220 verwendet werden, da der Eintrag 220 einem Zeitstempel zugeordnet wäre, der zeitlich vor dem Zeitpunkt T500 liegt und das physische Abbild des Blockes B1 zu einem Zeitpunkt vor T500 widerspiegeln würde.
Wie zuvor erwähnt, können Rückblendeeinträge in chronologischer Reihenfolge, oder in umgekehrt chronologischer Reihenfolge, angewendet werden. Tatsächlich können Rückblendeeinträge in beliebiger Reihenfolge verarbeitet werden. Falls es mehrere Rückblendeeinträge für einen Block gibt, dessen Zeitstempel früher als der Zeitpunkt ist, der dem Gate zugeordnet ist, das zum Zurückstellen des Datenlagers verwendet wird, dann ist das Abbild von einem beliebigen der Einträge ausreichend gut als wiederhergestelltes Abbild des Blockes nach der "physischen Wiederherstellungsphase" geeignet. Die Fähigkeit, Rückblendeeinträge in beliebiger Reihenfolge zu verwenden, ist insbesondere bei Systemen nützlich, die zum parallelen Anwenden der Rückblendeeinträge befähigt sind, wodurch die Effizienz der Wiederherstellungsoperation weiter vergrößert wird. Beispielsweise können Teilmengen der Rückblendeeinträge, die anzuwenden sind, auf mehrere Prozesse verteilt werden. Jeder dieser Prozesse kann dann die ihm zugewiesenen Rückblendeeinträge mit minimaler Koordination zu den anderen Prozessen anwenden.
Wie zuvor erwähnt, beinhaltet bei einer Ausführungsform jede Gate-Markierung auch einen Pointer, der auf einen Ort in einem physiologischen Redo-Protokoll weist (einen "Redo-Pointer"). Insbesondere gibt der Redo-Pointer, der in einer Gate-Markierung gespeichert ist, einen Ort in einem physiologischen Redo-Protokoll 250 an, um mit der Verarbeitung von Redo-Datensätzen zu beginnen, nachdem das Datenlager auf das Gate zurückgestellt wurde, das der Gate-Markierung zugeordnet ist. Beispielsweise sei angenommen, dass das Datenlager auf den Zeitpunkt T550 zurückzustellen ist. Während der physischen Wiederherstellungsphase wird das erste auf oder vor dem Zielzeitpunkt T550 befindliche Gate identifiziert. Beim vorliegenden Beispiel wird die Gate-Markierung zur Markierung 202 zurückverfolgt, die Zeitpunkt T500 entspricht. Die Rückblendeeinträge, die auf die Gate-Markierung 202 folgen, werden dann verwendet, um das Datenlager auf dessen physischen Zustand zum Zeitpunkt T500 zurückzustellen.
Nach der physischen Wiederherstellungsphase spiegelt das Datenlager den physischen Zustand der Blöcke bei oder vor dem Zeitpunkt T500 wider. Demzufolge werden möglicherweise einige der Änderungen, die durch Transaktionen erfolgt sind, die vor T550 abgeschlossen wurden, nicht im physischen Zustand des Datenlagers zum Zeitpunkt T500 widergespiegelt. Um zu bewirken, dass diese Änderungen widergespiegelt werden, werden physiologische Redo-Datensätze angewendet, beginnend bei dem Ort im Redo-Protokoll 250, der durch den Redo-Pointer der Gate-Markierung 202 bezeichnet wird. Durch Anwenden der Redo-Datensätze werden die logischen Datenelemente im Datenlager in ihren konsistenten Zustand beim Zeitpunkt T550 zeitlich nach vorne verschoben. Auch wird bei der physiologischen Wiederherstellungsphase ein physiologisches Undo angewendet, um aus den logischen Datenelementen jegliche Aktualisierungen zu entfernen, die (1) sich im physischen Abbild befanden, jedoch (2) durch Transaktionen erfolgt sind, die zum Zeitpunkt T550 noch nicht abgeschlossen wurden.
MEHRFACH-SERVER-SYSTEME
Bei einigen Datenbanksystemen können mehrere Datenbankserver Zugriff auf dieselbe Datenbank haben. Gemäß einer Ausführungsform führt jeder der Datenbankserver, der Zugriff auf eine Datenbank hat, seinen eigenen Satz von Protokollen zur Durchführung einer Wiederherstellung der Datenbank, einschließlich eines Rückblende-Protokolls und eines physiologischen Redo-Protokolls. Die verschiedenen Datenbankserver können auch separate physiologische Undo-Protokolle aufweisen, oder es kann ein einziges gemeinsam genutztes physiologisches Undo-Protokoll für alle Datenbankserver vorhanden sein. Um die Datenbank auf einen früheren Zustand zurückzustellen, wird möglicherweise Wiederherstellungsinformation von allen Protokollen aller Server benötigt. Beispielsweise kann, nach einem speziellen Gate G3, der eine Server S1 die Erste-nach-Gate-Aktualisierung auf Block B1 ausführen, ein anderer Server S2 kann die Erste-nach-Gate-Aktualisierung auf Block B2 durchführen, und noch ein weiterer Server S3 kann die Erste-nach-Gate-Aktualisierung auf Block B3 durchführen. Unter diesen Umständen muss, wenn die Datenbank auf Gate G3 zurückzustellen ist, ein Rückblende-Datensatz des Rückblende-Protokolls von S1 auf B1 angewendet werden, ein Rückblende-Datensatz des Rückblende-Protokolls von S2 muss auf B2 angewendet werden, und ein Rückblende, Datensatz des Rückblende-Protokolls von S3 muss auf B3 angewendet werden.
Unglücklicherweise erfolgt die Kommunikation zwischen den verschiedenen Servern nicht unverzüglich. Die zeitliche Verzögerung bei einer Kommunikation zwischen Servern kann zu Synchronisationsproblemen in Bezug auf eine Einrichtung von Gates führen. Beispielsweise sei angenommen, dass der Server ein Gate G3 einrichtet, das 17 Uhr zugeordnet ist. Falls die Kommunikation zwischen den Servern unmittelbar erfolgte, könnte zum Zeitpunkt 17 Uhr der Server S1 das Gate G3 "publizieren", und S2 und S3 würden in genauer Weise mit einer Erzeugung von Rückblendeeinträgen für alle Erste-nach-Gate-Aktualisierungen nach G3 beginnen. Jedoch kommt die Benachrichtigung über G3 möglicherweise erst 1 Sekunde nach 17 Uhr bei S2 an, und bei S3 erst 3 Sekunden nach 17 Uhr. Demzufolge fehlen in G3 Rückblendeeinträge für Aktualisierungen, die von S2 zwischen 17 Uhr und 1 Sekunde nach 17 Uhr vorgenommen wurden.
In ähnlicher Weise fehlen in G3 Rückblendeeinträge für Aktualisierungen, die von S3 zwischen 17 Uhr und 3 Sekunden nach 17 Uhr vorgenommen wurden.
Gemäß einer Ausführungsform wird mit diesem Synchronisationsproblem dadurch angegangen, dass Gates unter Verwendung eines Zweiphasen-Prozesses eingerichtet werden. Während der ersten Phase sendet ein Server, den man als "Koordinator" bestimmt hat, eine "Protokollierbeginn"-Nachricht an alle anderen Server. Ansprechend auf die Protokollierbeginn-Nachricht sendet jeder andere Server (1) an den Koordinator eine Antwort-Nachricht, welche die Position des aktuellen Einsetzpunktes in dessen Rückblende-Protokoll angibt, und (2) beginnt damit, Rückblendeeinträge für jede Aktualisierung zu erzeugen, die er vornimmt.
Beispielsweise sei angenommen, dass S2 eine Protokollierbeginn-Nachricht von S1 erhält und dass der aktuelle Einsetzpunkt in das Rückblende-Protokoll von S2 bei S2-POS1 ist. Ansprechend auf die Protokollierbeginn-Nachricht sendet S2 (1) eine Antwort an S1, die dessen aktuelle Position S2-POS1 angibt, und (2) beginnt, Rückblendeeinträge für jede Aktualisierung zu erzeugen, welche er vornimmt. In ähnlicher Weise sendet, wenn der aktuelle Einfügepunkt im Rückblende-Protokoll von S3 bei S3-POS1 ist, wenn S3 eine Protokollierbeginn-Nachricht von S1 empfängt, dann S3 ansprechend auf die Nachrichtenbeginn-Nachricht (1) eine Antwort an S1, die dessen aktuelle Position S3-POS1 angibt, und (2) beginnt mit einer Erzeugung von Rückblendeeinträgen für jede Aktualisierung, die er vornimmt.
Wenn der Koordinator die Antworten aller anderen Server empfangen hat, richtet er (1) ein Gate ein, das einem Zeitpunkt zugeordnet ist, der nicht vor dem Zeitpunkt liegt, bei dem die letzte Antwort empfangen wurde, und (2) erzeugt er eine Markierung für das Gate. Beispielsweise sei angenommen, dass S1 die letzte Antwort um 17 Uhr empfängt und ein Gate G3 einrichtet, das dem Zeitpunkt 17 Uhr zugeordnet ist. Nach dem Einrichten des Gate sendet der Koordinator eine 'Gate-eingerichtet'-Nachricht an die anderen Server. Die 'Gate-eingerichtet'-Nachricht gibt den Zeitpunkt an, der dem neuen Gate zugeordnet ist. Da der für das neue Gate eingerichtete Zeitpunkt notwendigerweise nach dem Zeitpunkt liegt, bei dem die Server mit der Erzeugung von Rückblendeeinträgen begonnen haben, wird dann ein Rückblendeeintrag für alle von den Servern vorgenommenen Erste-nach-Gate-Änderungen vorliegen, und zwar ungeachtet des Zeitpunktes, zu dem sie die 'Gate-eingerichtet'-Nachricht empfangen.
Ansprechend auf das Empfangen der 'Gate-eingerichtet'-Nachricht hören die anderen Server mit einem Erzeugen von Rückblendeeinträgen für alle Aktualisierungen auf und beginnen mit einem Erzeugen von Rückblendeeinträgen lediglich für Erste-nach-Gate-Aktualisierungen. Erneut Bezug nehmend auf das vorliegende Beispiel, empfangen S2 und S3 eine 'Gate-eingerichtet'-Nachricht von S1, die angibt, dass G3 um 17 Uhr eingerichtet wurde. S2 und S3 hören mit dem Erzeugen von Rückblendeeinträgen für alle Aktualisierungen auf und beginnen damit, Rückblendeeinträge für die erste Aktualisierung zu erzeugen, die an einen beliebigen gegebenen Block nach 17 Uhr vorgenommen wird.
Das zuvor beschriebene Zweiphasen-Gate-Erzeugungsverfahren vermeidet die mit einer Synchronisierung in Zusammenhang stehenden Probleme, da, sogar wenn ein Server die 'Gate-eingerichtet'-Nachricht nach dem dem Gate zugeordneten Zeitpunkt empfängt, dieser Server bereits Rückblendeeinträge für jegliche Änderungen erzeugt hat, die zwischen dem dem Gate zugeordneten Zeitpunkt und dem Zeitpunkt, zu dem der Server die 'Gate-eingerichtet'-Nachricht empfängt, vorgenommen wurden. Beispielsweise hat, sogar wenn S2 die 'Gate-eingerichtet'-Nachricht für G3 um 17:01 Uhr empfängt, S2 bereits Rückblende-Information für alle Aktualisierungen erzeugt, die nach 17:00 Uhr erfolgt sind, welches der dem Gate G3 zugeordnete Zeitpunkt ist.
Wie zuvor erwähnt, erzeugt der Koordinator eine Gate-Markierung für das Gate, das er einrichtet. Gemäß einer Ausführungsform ist eine Gate-Markierung, die für Gates in einer Mehrfach-Server-Umgebung erzeugt wird, ähnlich zu Gate-Markierungen, die in Einzel-Server-Umgebungen erzeugt werden, abgesehen davon, dass in einer Mehrfach-Server-Umgebung die Gate-Markierung Daten beinhaltet, welche, in den Rückblende-Protokollen der anderen Server, die Orte angeben, welche dem Gate zugeordnet sind. Beispielsweise beinhaltet die Rückblende-Markierung für Gate G3, die im Rückblende-Protokoll von S1 gespeichert ist, Daten, welche S2-POS1 im Rückblende-Protokoll von S2, und S3-POS1 im Rückblende-Protokoll von S3 angeben. Somit gibt, wenn eine physische Wiederherstellung basierend auf G3 ausgeführt wird, die Markierung für G3 an, wo mit einer Verarbeitung von Rückblendeeinträgen in den Rückblende-Protokollen von jedem von S1, S2 und S3 zu beginnen ist.
Bei einer alternativen Ausführungsform können Gate-Markierungen für ein spezielles Gate in jedem der separaten Rückblende-Protokolle platziert werden. Beispielsweise würde die Rückblende-Markierung für Gate G3, die im Rückblende-Protokoll von S1 gespeichert ist, den Ort im Rückblende-Protokoll von S1 angeben, der Gate G3 zugeordnet ist. Eine separate Rückblende-Markierung für Gate G3 würde im Rückblende-Protokoll von S2 gespeichert werden und den Ort S2-POS1 angeben. Noch eine weitere Rückblende-Markierung für Gate G3 würde im Rückblende-Protokoll von S3 gespeichert werden und den Ort S3-POS1 angeben.
Gemäß einer Ausführungsform, bei der eine einzige Gate-Markierung verwendet wird, um die Gate-Position für alle Server anzugeben, antworten Server auf Protokollierbeginn-Nachrichten dadurch, dass sie sowohl ihren aktuellen Ort in ihren jeweiligen Rückblende-Protokollen, als auch ihren aktuellen Ort in ihren physiologischen Redo-Protokollen senden. Beide Informationen können in der Markierung für das Gate gespeichert sein. Demzufolge gibt, wenn die Datenbank basierend auf dem Gate auf einen früheren physischen Zustand zurückgestellt wird, die Information in der Gate-Markierung nicht nur an, wo mit einer Verarbeitung von Rückblendeeinträgen in den verschiedenen Rückblende-Protokollen zu beginnen ist, sondern auch, wo mit einer Verarbeitung von Redo-Einträgen in den verschiedenen physiologischen Redo-Protokollen zu beginnen ist.
ZEITSTEUERUNG
Um die Integrität des Datenlagers zu gewährleisten, müssen gewisse Operationen in einer speziellen Abfolge durchgeführt werden. Die zeitlichen Abhängigkeiten, die auf Operationen zur Pflege des Rückblende-Protokolls anzuwenden sind, die bei einer Ausführungsform verwendet werden, beinhalten:
Der Rückblendeeintrag, der das Vor-Aktualisierungs-Abbild eines Blockes enthält, muss in einen nichtflüchtigen Speicher bei oder vor dem Zeitpunkt geschrieben werden, zu dem die aktualisierte Kopie des Blockes in den nichtflüchtigen Speicher geschrieben wird. Beispielsweise muss, Bezug nehmend auf 1C, der Rückblendeeintrag 136 in das Rückblende-Protokoll 106 bei oder vor dem Zeitpunkt geschrieben werden, zu dem die geprüfte Kopie 124 des Blockes 120 in das Datenlager 112 geschrieben wird.
Die Redo-Einträge für alle Änderungen, die in einem früheren Abbild eines Blockes widergespiegelt werden, müssen in den nichtflüchtigen Speicher bei oder vor dem Zeitpunkt geschrieben werden, zu dem der Rückblendeeintrag, der das frühere Abbild enthält, in den nichtflüchtigen Speicher geschrieben wird. Beispielsweise sei angenommen, dass ein Block B1 bei 16:49 Uhr aktualisiert wird, was bewirkt, dass ein Redo-Datensatz R1 erzeugt wird. Weiter sei angenommen, dass ein Rückblendeeintrag F1 für eine Erste-nach-Gate-Aktualisierung bei einem Block B1 erzeugt wird, wobei das Gate G3, das die Erzeugung von F1 verursacht hat, 17 Uhr zugeordnet ist. Unter diesen Umständen spiegelt das frühere Abbild von B1, das in F1 enthalten ist, die Änderung wider, die um 16:49 Uhr vorgenommen wurde. Demzufolge muss R1 bei oder vor dem Zeitpunkt in den nichtflüchtigen Speicher geschrieben werden, zu dem F1 in den nichtflüchtigen Speicher geschrieben wird.
Ein Verfahren, um zu gewährleisten, dass ein Redo für eine Änderung in den nichtflüchtigen Speicher geschrieben wird, bevor ein früheres Abbild, das die Änderung widerspiegelt, in den nichtflüchtigen Speicher geschrieben wird, beinhaltet, dass, zum Zeitpunkt der Einrichtung eines Gate, alle Redo-Datensätze, die Änderungen zugeordnet sind, die vor dem Gate erfolgt sind, in den nichtflüchtigen Speicher geschrieben werden. Somit werden, wenn G3 bei 17 Uhr eingerichtet wird, alle Redo-Datensätze, die Änderungen zugeordnet sind, die vor 17 Uhr erfolgt sind, in den nichtflüchtigen Speicher geschrieben. Demzufolge spiegeln die Rückblendeeinträge für G3 keine Änderungen wider, für die Redo-Informationen nicht bereits im nichtflüchtigen Speicher widergespiegelt werden.
OPTIMIERUNGEN
Verschiedene Verfahren können verwendet werden, um die Leistungsfähigkeit von Wiederherstellungsoperationen zu verbessern, die wie hier beschrieben durchgeführt werden. Beispielsweise sei angenommen, dass noch keine Daten in einem Block B1 gespeichert wurden. Falls die erste Aktualisierung auf B1 eine Erste-nach-Gate-Aktualisierung ist, wird ein Rückblendeeintrag mit dem Vor-Aktualisierungs-Abbild von B1 erzeugt. In diesem Fall enthält jedoch das Vor-Aktualisierungs-Abbild von B1 keine nützliche Information. Daher wird, wenn eine Erste-nach-Gate-Aktualisierung bei einem Block vorgenommen wird, in dem noch keine Information gespeichert ist, die aufbewahrt werden soll, ein spezieller Rückblendeeintrag erzeugt. Der spezielle Rückblendeeintrag enthält kein vollständiges Vor-Aktualisierungs-Abbild des Blockes, sondern identifiziert lediglich den Block und gibt an, dass der Block keine benötigte Information enthielt.
Als weiteres Beispiel kann bei einigen Situationen, wie beispielsweise EINFÜGE-Operationen sich die frühere Version eines Blockes noch nicht im flüchtigen Speicher befinden, wenn eine Erste-nach-Gate-Aktualisierung bei dem Block durchgeführt wird. Unter diesen Umständen muss das frühere Abbild des Blockes für gewöhnlich aus dem nichtflüchtigen Speicher ausgelesen werden, um den Rückblendeeintrag für die Aktualisierung zu erzeugen. Jedoch kann die Notwendigkeit, das frühere Abbild aus dem nichtflüchtigen Speicher auszulesen, vermieden werden, wenn bekannt ist, dass das frühere Abbild des Blockes keine Information enthält, die aufbewahrt werden muss. Gemäß einer Ausführungsform wird, wenn in dem Block zuvor Daten für eine Struktur (wie beispielsweise eine Tabelle) gespeichert wurde, die anschließend fallengelassen wurde, dann bestimmt, ob die Struktur vor dem Zeitpunkt fallengelassen wurde, der dem ältesten Gate zugeordnet ist, zu dem die Datenbank zurückgestellt werden kann. Wenn die Struktur vor dem Zeitpunkt fallengelassen wurde, die dem ältesten Gate zugeordnet ist, auf das die Datenbank zurückgestellt werden kann, dann braucht das frühere Abbild nicht von der Platte gelesen werden. Stattdessen kann ein spezieller Rückblendeeintrag verwendet werden, um den Block zu identifizieren und um anzugeben, dass der Block keine benötigte Information enthielt.
Beispielsweise würde, wenn in dem Block zuvor ein Teil einer Tabelle gespeichert war, die vor einer Woche fallengelassen wurde, und das älteste für die Datenbank benötigte Gate zwei Tage zurückliegt, dann der Block zu einer Struktur gehören, die vor dem Zeitpunkt fallengelassen wurde, der dem ältesten Gate zugeordnet ist, auf das die Datenbank zurückgestellt werden kann. Demzufolge kann ein besonderer Rückblendeeintrag, der kein früheres Abbild des Blockes enthält, für den Block verwendet werden.
Ein weiteres Verfahren, das zum Sparen von Ressourcen verwendet werden kann, beinhaltet ein Kombinieren physischer und physiologischer Undo-Protokolle zu einem einzigen Undo-Protokoll, das ausreichend Information enthält, um das Datenlager in einen konsistenten Zustand zurückzustellen. Eine Verwendung eines kombinierten Undo-Protokolls kann ein beträchtliches Ausmaß an Redundanz zwischen den Informationen, die in separaten physischen und physiologischen Undo-Protokollen geführt werden, vermeiden. Alternativ kann eine derartige Redundanz dadurch vermieden werden, dass Rückblendeeinträge lediglich in Situationen erzeugt werden, bei denen das physiologische Undo keine ausreichende Information aufweist, um einen Block zu einem früheren Zustand zurückzustellen. Die spezifischen Umstände, bei denen in einem physiologischen Undo keine ausreichenden Informationen enthalten sind, variieren von Implementierung zu Implementierung, und dies kann beispielsweise vom speziellen Typ des Blockes abhängen, der gerade aktualisiert wird.
Gemäß einem weiteren Verfahren werden Blöcke, die Header-Information betreffende Dateien enthalten, anders als Blöcke behandelt, in welchen Daten gespeichert sind, die den Inhalt der Dateien bilden. Gemäß einer Ausführungsform enthalten die Rückblendeeinträge, die für Datei-Headerblöcke erzeugt werden, nicht das gesamte frühere Abbild der Header-Blöcke. Vielmehr beschreiben die Rückblendeeinträge für Datei-Headerblöcke Meta-Änderungen an den Dateien und werden auf die Datei in logischer Weise angewendet, und zwar anstelle eines vollständigen Überschreibens der entsprechenden Datei-Headerblöcke. Beispielsweise kann ein derartiger Rückblendeeintrag angeben, dass eine Datei zu einem speziellen Zeitpunkt expandiert wurde. Eine Anwendung eines derartigen Rückblendeeintrages beinhaltet, dass die Datei wieder auf ihre ursprünglichen Grenzen zurück verkleinert wird. In ähnlicher Weise kann ein Rückblendeeintrag das Hinzufügen einer Datei zum Datenlager angeben. Ein Verwenden des Rückblendeeintrages hat ein Löschen der hinzugefügten Datei zur Folge.
HARDWARE-ÜBERSICHT
3 ist ein Blockdiagramm, das ein Computersystem 300 darstellt, auf dem eine Ausführungsform der Erfindung implementiert werden kann. Das Computersystem 300 beinhaltet einen Bus 302 oder einen anderen Kommunikationsmechanismus zum Weiterleiten von Information, und einem mit dem Bus 302 verbundenen Prozessor 304 zum Verarbeiten von Informationen. Das Computersystem 300 beinhaltet auch einen Hauptspeicher 306, wie beispielsweise einen RAM (Direktzugriffsspeicher) oder eine andere dynamische Speichervorrichtung, die mit dem Bus 302 verbunden ist, um Informationen und durch den Prozessor 304 auszuführende Anweisungen zu speichern. Der Hauptspeicher 306 kann auch zum Speichern von temporären Variablen oder anderen Zwischeninformationen während eines Ausführens von durch den Prozessor 304 auszuführenden Anweisungen verwendet werden. Das Computersystem 300 beinhaltet weiter einen ROM (Nur-Lese-Speicher) 308 oder eine andere mit dem Bus 302 verbundene statische Speichervorrichtung zum Speichern statischer Informationen und Anweisungen für den Prozessor 304. Eine Speichervorrichtung 310, wie beispielsweise eine Magnetplatte oder eine optische Platte, ist vorgesehen und mit dem Bus 302 verbunden, um Informationen und Anweisungen zu speichern.
Das Computersystem 300 kann über einen Bus 302 mit einer Anzeigeeinrichtung 312 wie beispielsweise einer Kathodenstrahlröhre (CRT) verbunden sein, um einem Computerbenutzer Informationen anzuzeigen. Eine Eingabevorrichtung 314, die alphanumerische und weitere Tasten beinhaltet, ist mit dem Bus 302 verbunden, um Informationen und ausgewählte Befehle an den Prozessor 304 zu übermitteln. Ein weiterer Typ vom Benutzereingabevorrichtung ist eine Cursorsteuerung 316, wie beispielsweise ein Maus, ein Trackball oder Cursor-Richtungstasten, um Richtungsinformationen und ausgewählte Befehle an den Prozessor 304 zu übermitteln und die Cursorbewegung auf der Anzeigevorrichtung 312 zu steuern. Diese Eingabevorrichtung weist typischerweise zwei Frei heitsgrade in zwei Achsen auf, einer ersten Achse (z. B. x) und einer zweiten Achse (z. B. y), was ermöglicht, dass die Vorrichtung Positionen in einer Ebene bezeichnen kann.
Die Erfindung betrifft die Verwendung eines Computersystems 300 zum Implementieren der hier beschriebenen Verfahren. Gemäß einer Ausführungsform der Erfindung werden diese Verfahren durch ein Computersystem 300 durchgeführt, und zwar reagierend darauf, dass der Prozessor 304 eine oder mehrere Sequenzen von einer oder mehreren im Hauptspeicher 306 enthaltenen Anweisungen ausführt. Derartige Anweisungen können in den Hauptspeicher 306 von einem weiteren computerlesbaren Medium, wie beispielsweise einer Speichervorrichtung 310, eingelesen werden. Ein Ausführen der im Hauptspeicher 306 enthaltenen Anweisungssequenzen bewirkt, dass der Prozessor 304 die hier beschriebenen Prozessschritte durchführt. Bei alternativen Ausführungsformen kann eine fest verdrahtete Schaltungsanordnung verwendet werden, und zwar anstelle von Softwareanweisungen oder in Kombination mit diesen, um die Erfindung zu implementieren. Daher sind die Ausführungsformen der Erfindung nicht auf irgendeine spezielle Kombination aus Hardware-Schaltungsanordnung und Software eingeschränkt.
Der Begriff "computerlesbares Medium", wie hier verwendet, betrifft ein beliebiges Medium, das daran beteiligt ist, Anweisungen an den Prozessor 304 zum Ausführen zu liefern. Ein derartiges Medium kann viele Formen annehmen, einschließlich, jedoch nicht eingeschränkt auf nichtflüchtige Medien, flüchtige Medien und Übertragungsmedien. Nichtflüchtige Medien beinhalten beispielsweise optische oder magnetische Platten, wie beispielsweise die Speichervorrichtung 310. Flüchtige Medien beinhalten einen dynamischen Speicher, wie beispielsweise den Hauptspeicher 306. Übertragungsmedien beinhalten Koaxialkabel, Kupferdraht- und Glasfaserkabel, einschließlich der Drähte, die den Bus 302 beinhalten. Übertragungsmedien können auch die Form von akustischen Wellen oder Lichtwellen annehmen, beispielsweise solche, die während Radiowellen- und Infrarot-Datenkommunikationen erzeugt werden.
Übliche Formen vom computerlesbaren Medien beinhalten beispielsweise eine Floppy-Disk, eine Diskette, eine Festplatte, ein Magnetband oder ein beliebiges anderes magnetisches Medium, eine CD-ROM, ein beliebiges anderes optisches Medium, Lochkarten, Papierband, ein beliebiges anderes physisches Medium mit Lochmustern, ein RAM, ein PROM und ein EPROM, ein FLASH-EPROM, einen beliebigen anderen Speicherchip oder eine -kassette, eine Trägerwelle wie nachfolgend beschrieben, oder ein beliebiges anderes Medium, von dem ein Computer lesen kann.
Verschiedene Formen von computerlesbaren Medien können daran beteiligt sein, eine oder mehrere Sequenzen von einer oder mehreren Anweisungen zum Prozessor 304 zur Ausführung zu transportieren. Beispielsweise können sich die Anweisungen zu Anfang auf einer Magnetscheibe eines entfernt angeordneten Computers befinden. Der entfernt angeordnete Computer kann die Anweisungen in seinen dynamischen Speicher laden und die Anweisungen über eine Telefonleitung unter Verwendung eines Modems senden. Ein Modern, das sich lokal beim Computersystem 300 befindet, kann die auf der Telefonleitung befindlichen Daten empfangen und eine Infrarot-Übertragungseinrichtung verwenden, um die Daten in ein Infrarotsignal umzuwandeln. Eine Infrarot-Erfassungseinrichtung kann die im Infrarotsignal transportierten Daten empfangen, und eine geeignete Schaltungsanordnung kann die Daten auf dem Bus 302 platzieren. Der Bus 302 transportiert die Daten zum Hauptspeicher 306, von dem aus der Prozessor 304 die Anweisungen ausliest und ausführt. Die vom Hauptspeicher 306 empfangenen Anweisungen können optional in der Speichervorrichtung 310 gespeichert werden, und zwar entweder vor oder nach dem Ausführen durch den Prozessor 304.
Das Computersystem 300 beinhaltet auch eine Kommunikationsschnittstelle 318, die mit dem Bus 302 verbunden ist. Die Kommunikationsschnittstelle 318 sorgt für eine Zweiweg-Datenkommunikationsverbindung zu einem Netzwerk-Verbindungsglied 320, das mit einem lokalen Netz 322 verbunden ist. Beispielsweise kann die Kommunikationsschnittstelle 318 eine ISDN-(Integrated Services Digital Network)-Karte oder ein Modem sein, um eine Datenkommunikationsverbindung zu einem entsprechenden Typ von Telefonleitung bereitzustellen. Als weiteres Beispiel kann die Kommunikationsschnittstelle 318 eine LAN-(Local Area Network)-Karte sein, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN bereitzustellen. Drahtlose Verkehrsverbindungen können auch implementiert sein. Bei jeder derartigen Implementierung sendet und empfängt die Kommunikationsschnittstelle 318 elektrische, elektromagnetische oder optische Signale, welche digitale Datenströme transportieren, die verschiedene Typen von Information repräsentieren.
Das Netzwerk-Verbindungsglied 320 sorgt typischerweise für eine Datenkommunikation über eines oder mehrere Netze zu anderen Datenvorrichtungen. Beispielsweise kann das Netzwerk-Verbindungsglied 320 eine Verbindung über ein lokales Netz 322 zu einem Host-Computer 324 oder zu einer Datenanlage bereitstellen, die durch einen Internetdienstanbieter (ISP) 326 betrieben wird. Der ISP 326 stellt seinerseits Datenkommunikationsdienste über das weltweite Paketdaten-Kommunikationsnetz bereit, das heutzutage allgemein als "Internet" 328 bezeichnet wird. Das lokale Netz 322 und das Internet 328 verwenden beide elektrische, elektromagnetische oder optische Signale, welche digitale Datenströme transportieren. Die über die verschiedenen Netzwerke übertragenen Signale, und die beim Netzwerk-Verbindungsglied 320 und über die Kommunikationsschnittstelle 318 übertragenen Signale, welche die digitalen Signale vom Computersystem 300 weg und zu diesem hin transportieren, sind beispielhafte Formen von die Informationen transportierenden Trägerwellen.
Das Computersystem 300 kann Nachrichten senden und Daten, einschließlich Programmcode empfangen, und zwar über das/die Netzwerk(e), das Netzwerk-Verbindungsglied 320 und die Kommunikationsschnittstelle 318. Beim Beispiel des Internet könnte ein Server 330 einen angeforderten Code für ein Anwendungsprogramm über das Internet 328, den ISP 326, das lokale Netz 322 und die Kommunikationsschnittstelle 318 übertragen.
Der empfangene Code kann durch den Prozessor 304 bei seinem Empfang ausgeführt werden, und/oder in der Speichervorrichtung 310 oder einem anderen nichtflüchtigen Speicher zur späteren Ausführung gespeichert werden. Auf diese Weise kann das Computersystem 300 Anwendungscode in Form einer Trägerwelle erhalten.
In der vorhergehenden Beschreibung wurden Ausführungsformen der Erfindung mit Bezug auf zahlreiche spezielle Details beschrieben, die von Implementierung zu Implementierung variieren können. Daher ist der Gegenstand, für den Schutz angestrebt wird, durch die Ansprüche definiert. Die Beschreibung und die Zeichnungen sind daher als erläuternd und nicht einschränkend zu verstehen.

Claims

Ein Verfahren zum Zurückführen eines Datenlagers (112) zu einem früheren logischen Zielzustand, wobei das Verfahren die Schritte aufweist: Empfangen einer Anforderung, das Datenlager (112) zu dem früheren logischen Zielzustand zurückzuführen, wobei der frühere logische Zielzustand einem Zielzeitpunkt entspricht; ansprechend auf die Anforderung, Ausführen der Schritte: Anwenden eines physischen Undo auf einen oder mehrere Blöcke (120), die Daten für das Datenlager (112) persistent speichern, wobei der eine oder die mehreren Blöcke (120) eine Teilmenge aller Blöcke (120) im Datenlager (112) sind, wobei das physische Undo Informationen umfasst, die erforderlich sind, um den einen oder die mehreren Blöcke (120), die Speichereinheiten sind, zu einem vorherigen Zustand zurückzuführen, und wobei die Anwendung des physischen Undo bewirkt, dass jeder des einen oder der mehreren Blöcke (120) einen physischen Zustand wiedergibt, der einem Zeitpunkt vor dem Zielzeitpunkt zugeordnet ist; und Anwenden mindestens eines physiologischen Undo und/oder mindestens eines physiologischen Redo, um logische Datenelemente, die sich in dem einen oder den mehreren Blöcken (120) befinden, zu dem früheren logischen Zielzustand zu führen, wobei das physiologische Undo Informationen beinhaltet, wie Änderungen, die an den logischen Datenelementen vorgenommen worden sind, rückgängig gemacht werden sollen, und wobei das physiologische Redo Informationen beinhaltet, wie Änderungen der logischen Datenelemente erneut ausgeführt werden sollen.
Das Verfahren nach Anspruch 1, bei dem der Schritt des Anwendens des physischen Undo das Zuordnen von Aufzeichnungen über das physische Undo an eine Mehrzahl von Prozessen beinhaltet; und die Mehrzahl von Prozessen die Aufzeichnungen über das physische Undo parallel zueinander anwenden.
Das Verfahren nach Anspruch 1, bei dem: der Schritt des Anwendens des physischen Undo bewirkt, dass Blöcke (120) in dem Datenlager (112) Zeiten vor dem Zielzeitpunkt wiedergeben; und der Schritt des Anwendens mindestens eines physiologischen Undo und/oder mindestens eines physiologischen Redo beinhaltet, dass das physiologische Redo angewendet wird, um logische Datenelemente in dem Datenlager (112) zeitlich nach vorne auf den früheren logischen Zielzustand zu verschieben.
Das Verfahren nach Anspruch 3, bei dem der Schritt des Anwendens mindestens eines physiologischen Undo und/oder mindestens eines physiologischen Redo beinhaltet, nach dem Anwenden des physiologischen Redo das physiologische Undo anzuwenden, um zumindest von einigen der logischen Datenelemente Veränderungen zu entfernen, die von Transaktionen durchgeführt wurden, die zum Zielzeitpunkt oder vor dem Zielzeitpunkt nicht abgeschlossen worden waren.
Das Verfahren nach Anspruch 1, bei dem der Schritt des Anwendens des physischen Undo auf einen oder mehrere Blöcke (120), die Daten für das Datenlager (112) speichern, aufweist: Anwenden, auf einen ersten Satz des einen oder der mehreren Blöcke (120), eines physischen Undo, das einem einem bestimmten Zeitpunkt entsprechenden Gate zugeordnet ist, wobei das Gate ein bestimmter Zeitpunkt ist, für den das physische Undo erzeugt wird; und Anwenden, auf einen zweiten Satz des einen oder der mehreren Blöcke (120), eines physischen Undo, das einem Vorwegnahme-Gate, das dem Gate vorhergeht, zugeordnet ist.
Das Verfahren nach Anspruch 5, ferner mit den Schritten: Erzeugen eines physischen Undo für einige aber nicht alle Erste-nach-Vorwegnahme-Gate-Aktualisierungen, die nach dem Vorwegnahme-Gate durchgeführt wurden; und Erzeugen eines physischen Undo für alle Erste-nach-Gate-Aktualisierungen, die nach dem Gate durchgeführt wurden, außer für Aktualisierungen, die an Blöcken (120) vorgenommen wurden, für die ein physisches Undo nach dem Vorwegnahme-Gate erzeugt worden ist.
Das Verfahren nach Anspruch 6, ferner mit dem Schritt des Bestimmens, ob ein physisches Undo für eine Erste-nach-Vorwegnahme-Gate-Aktualisierung erzeugt werden soll, und zwar beruhend auf der Verfügbarkeit von Ressourcen, wenn die Erste-nach-Vorwegnahme-Gate-Aktualisierung durchgeführt wird.
Das Verfahren nach Anspruch 1, ferner mit den Schritten: Erzeugen des physischen Undo beruhend auf Gates, die bestimmten Zeitpunkten zugeordnet sind; Speichern des physischen Undo als Folge von Rückblenden-Aufzeichnungen in einem Rückblenden-Protokoll (106, 200); und Speichern von Daten, die die Gates mit Orten in dem Rückblenden-Protokoll (106, 200) in Beziehung setzen.
Das Verfahren nach Anspruch 8, bei dem der Schritt des Speicherns von Daten, die die Gates mit Orten in dem Rückblenden-Protokoll (106, 200) in Beziehung setzen, beinhaltet, für jedes Gate der Gates eine Gate-Markierung (202, 204) in dem Rückblenden-Protokoll (106, 200) zu speichern.
Das Verfahren nach Anspruch 9, ferner mit dem Schritt, die einem Gate zugeordnete Gate-Markierung (202, 204) zu verwenden, um zu bestimmen, welche Rückblenden-Aufzeichnungen (140, 142, 144, 220, 222, 228) zu verarbeiten sind, um das Datenlager (112) zu dem dem Gate zugeordneten physischen Zustand zurückzuführen.
Das Verfahren nach Anspruch 9, bei dem: die Gate-Markierung (202, 204) Daten umfasst, die einen Ort in einem physiologischen Redo-Protokoll (250) angeben; und das Verfahren ferner beinhaltet, die Stelle in dem physiologischen Redo-Protokoll (250) zu verwenden, um zu bestimmen, welches physiologische Redo verarbeitet werden soll.
Das Verfahren nach Anspruch 9, bei dem: die Gate-Markierung (202, 204) Daten aufweist, die einen Ort in dem Rückblenden-Protokoll (106, 200) angeben; und das Verfahren ferner beinhaltet, den Ort in dem Rückblenden-Protokoll (106, 200) zu verwenden, um zu bestimmen, welche Rückblenden-Einträge (140, 142, 144, 220, 222, 228) zu verarbeiten sind.
Das Verfahren nach Anspruch 9, ferner beinhaltend das Speichern, in jeder Gate-Markierung (202, 204), einer Verknüpfung zu einer vorherigen Gate-Markierung (202, 204) in dem Rückblenden-Protokoll (106, 200).
Das Verfahren nach Anspruch 1, bei dem: eine Mehrzahl von Einheiten Zugriff auf das Datenlager (112) haben; und jede Einheit der Mehrzahl von Einheiten ein separates Protokoll unterhält, das physische Undo-Informationen für zumindest einige der Blöcke (120) enthält, in denen sich das Datenlager (112) befindet.
Das Verfahren nach Anspruch 14, ferner beinhaltend das Einrichten eines Gate durch Ausführen der Schritte: Bestimmen einer Einheit aus der Mehrzahl von Einheiten als Koordinator; Bewirken, dass der Koordinator an jede andere Einheit der Einheiten eine Protokollierbeginn-Nachricht sendet; Bewirken, dass jede andere Einheit auf die Protokollierbeginn-Nachricht antwortet, indem sie ein physisches Undo für alle Aktualisierungen erzeugt; nach dem Senden der Protokollierbeginn-Nachricht ausgeführtes Bewirken, dass der Koordinator an jede andere Einheit der Einheiten eine Gate-eingerichtet-Nachricht sendet; und Bewirken, das jede andere Einheit auf die Gate-eingerichtet-Nachricht antwortet, indem nur ein physisches Undo für Erste-nach-Gate-Aktualisierungen erzeugt wird.
Das Verfahren nach Anspruch 15, bei dem: jede andere Einheit auch auf die Protokollierbeginn-Nachricht antwortet, indem sie eine Antwort an den Koordinator sendet; und der Koordinator die Gate-eingerichtet-Nachricht sendet, nachdem er Antworten für alle die anderen Einheiten erhalten hat.
Das Verfahren nach Anspruch 16, bei dem: die von jeder anderen Einheit gesendete Antwort einen Ort in dem separaten Protokoll der Einheit angibt; und der Koordinator Daten speichert, die das Gate mit Ortsinformationen in Beziehung setzen, wobei die Ortsinformationen die Orte bezeichnen, die in den von den anderen Einheiten erhaltenen Antworten angegeben sind.
Das Verfahren nach Anspruch 17, bei dem der Schritt des Speicherns von Daten, die dem Gate Ortsinformationen zuordnen, beinhaltet, in dem separaten Protokoll des Koordinators eine Markierung für das Gate zu speichern, wobei die Markierung Verknüpfungen zu den Orten aufweist, die in den von den anderen Einheiten empfangenen Antworten angegeben sind.
Computerlesbares Medium mit einer oder mehreren Befehlssequenzen, die, wenn sie von einem oder mehreren Prozessoren (304) ausgeführt werden, den einen oder den mehreren Prozessoren (304) veranlassen, das in einem der Ansprüche 1-18 angegebene Verfahren auszuführen.