DE112014002275T5

DE112014002275T5 - Datenbankverwaltungssystem und -verfahren

Info

Publication number: DE112014002275T5
Application number: DE112014002275.6T
Authority: DE
Inventors: Atsushi TOMODA; Yuuya Isoda; Kazutomo Ushijima
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2014-01-22
Filing date: 2014-01-22
Publication date: 2016-01-28
Also published as: WO2015111152A1; JPWO2015111152A1; GB201521129D0; JP6152431B2; US10366075B2; GB2537446A; US20160125018A1

Abstract

Ein Datenbankverwaltungssystem erzeugt ein Protokoll für jede Transaktion während der Ausführung einer Vielzahl von Transaktionen und speichert die erzeugten Protokolle in Protokollspeicherbereichen. Das Datenbankverwaltungssystem zeichnet Folgenummern von Protokollen mindestens in den erzeugten Protokollen zu einer Gruppe von Transaktionen, deren Ergebnisse je nach einer Transaktionsausführungsreihenfolge unterschiedlich ausfallen, gehörender Transaktionen auf.

Description

[Technisches Gebiet]
Diese Erfindung betrifft allgemein Datenbankverwaltung und zum Beispiel die Ausgabe der Protokolle von Transaktionsprozessen.
[Stand der Technik]
Als ein Datenbankverwaltungssystem (im folgenden als DBMS bezeichnet) sind eine On-Disk-Datenbank, in welcher Datenbanken (insbesondere Hauptdaten wie Tabellen und Indexe) in einer nichtflüchtigen Speichervorrichtung (typischerweise einer Plattenspeichervorrichtung wie einem Festplattenlaufwerk (HDD)) angeordnet sind, und eine speicherinterne Datenbank, in welcher Datenbanken in einem Hauptspeicher (meistens einem flüchtigen Speicher) angeordnet sind, bekannt (ein Hybrid-DBMS, in welchem eine On-Disk-Datenbank und eine speicherinterne Datenbank kombiniert sind, ist ebenfalls bekannt).
In der speicherinternen Datenbank ist es, um den Zustand von Datenbanken im Hauptspeicher wiederherzustellen, notwendig, die die Aktualisierungsvorgeschichte enthaltenden Protokolle in eine nichtflüchtige Speichervorrichtung auszugeben.
Gewöhnlich werden Protokolle während der Ausführung von Transaktionen in eine einzige Protokolldatei ausgegeben. Auch bei paralleler Verarbeitung von Transaktionen in einer Vielzahl von Kernen (oder einer Vielzahl von zentralen Verarbeitungseinheiten (CPUs)) ist das Ausgabeziel von Protokollen eine einzige Protokolldatei. Somit verursacht die Protokollausgabe einen Engpass.
Jedoch ist es nicht immer notwendig, die Reihenfolge aller Transaktionen zu bestimmen. Zum Beispiel ändert sich, wenn eine durch zwei Transaktionen referenzierte oder aktualisierte Gruppe von Daten keinen gemeinsamen Teil aufweist, ein Operationsergebnis an einer Datenbank auch dann nicht, wenn eine Ausführungsreihenfolge der beiden Transaktionen geändert wird. Somit ist es nicht notwendig, die Reihenfolge von zwei Transaktionen zu bestimmen. In PTL 1 wird eine Protokolldatei für jede von verteilten Datenbanken erstellt und wird ein die Aktualisierungsvorgeschichte einer Datenbank enthaltendes Protokoll in eine der Datenbank entsprechende Protokolldatei aus einer Vielzahl von Protokolldateien ausgegeben.
[Druckschriftenverzeichnis]
[Patentliteratur]

[PTL 1] US5878414

[Kurzbeschreibung der Erfindung]
[Technisches Problem]
Eine speicherinterne Datenbank kann eine Datenbank in eine Vielzahl von Partitionen teilen und kann die jeweiligen Partitionen verwalten. Wenn das in PTL 1 offenbarte Verfahren auf eine speicherinterne Datenbank angewendet wird, kann für jede durch die speicherinterne Datenbank verwaltete Partition eine Protokolldatei erstellt werden und kann ein die Aktualisierungsvorgeschichte einer Partition enthaltendes Protokoll in eine der Partition entsprechende Protokolldatei ausgegeben werden.
Jedoch kommt es, wenn das Verfahren aus PTL 1 einfach auf die speicherinterne Datenbank angewendet wird, in einer Speichervorrichtung zu einer Anzahl von E/A-Anforderungen, welche mehrfach höher als die Anzahl von Transaktionen ist. Dies liegt daran, dass Partitionen bereits festgelegt sind, und es ist unvermeidlich, dass während der Verarbeitung von Transaktionen eine Vielzahl von Partitionen von Daten referenziert und aktualisiert wird. In diesem Fall müssen, auch wenn nur eine Transaktion verarbeitet wird, Protokolle in eine Vielzahl von Protokolldateien, welche jeweils der Vielzahl von Partitionen entsprechen, ausgegeben werden.
Ein solches Problem ist nicht auf die speicherinterne Datenbank beschränkt, sondern kann auch in anderen DBMSs, welche verteilte Datenbanken verwalten, oder in anderen DBMSs, welche eine einzelne Datenbank verwalten, auftreten.
[Problemlösung]
Ein DBMS erzeugt ein Protokoll für jede Transaktion während der Ausführung einer Vielzahl von Transaktionen und speichert die erzeugten Protokolle in Protokollspeicherbereichen. Das DBMS zeichnet Folgenummern von Protokollen mindestens in den erzeugten Protokollen zu einer Gruppe von Transaktionen, deren Ergebnisse je nach einer Transaktionsausführungsreihenfolge unterschiedlich ausfallen, gehörender Transaktionen auf.
[Vorteilhafte Auswirkungen der Erfindung]
Die Folgenummern von Protokollen werden in für zu einer Gruppe von Transaktionen, deren Ergebnisse je nach einer Transaktionsausführungsreihenfolge unterschiedlich ausfallen, gehörende Transaktionen erzeugten Protokollen aufgezeichnet. Somit ist es möglich, die Transaktionsausführungsreihenfolge für die Gruppe von Transaktionen, deren Ergebnisse je nach der Transaktionsausführungsreihenfolge unterschiedlich ausfallen, anzugeben. Somit ist es, selbst wenn die Anzahl für eine Transaktion, welche zwei oder mehr Datenbank-Teile aus einer durch Verteilen der Datenbank erhaltenen Vielzahl von Datenbank-Teilen aktualisiert hat, erzeugter Protokolle kleiner als die Anzahl aktualisierter Datenbank-Teile ist, möglich, die Transaktionsausführungsreihenfolge (zum Beispiel die Teilreihenfolge) auf der Grundlage der gespeicherten Protokolle anzugeben.
[Kurzbeschreibung der Zeichnungen]
1 veranschaulicht eine Konfiguration eines Computersystems gemäß einer Ausführungsform.
2 veranschaulicht ein Beispiel einer Transaktionsgruppe.
3 ist ein Blockschaubild eines Computersystems gemäß einer Ausführungsform.
4 veranschaulicht eine Konfiguration eines LLSN-Managers.
5 veranschaulicht eine Datenstruktur eines Protokolls.
6 veranschaulicht eine Datenstruktur eines Prüfpunkt-Protokolls.
7 veranschaulicht ein Beispiel einer Transaktionsgruppe.
8 veranschaulicht Tabellen vor und nach Ausführung einer Transaktionsgruppe.
9 veranschaulicht ein Beispiel der Protokollausgabe gemäß einer Ausführungsform.
10 veranschaulicht ein Beispiel der Protokollausgabe gemäß Vergleichsbeispiel 1.
11 veranschaulicht ein Beispiel der Protokollausgabe gemäß Vergleichsbeispiel 2.
12 ist ein Ablaufplan eines Transaktionsprozesses.
13 ist ein Ablaufplan eines Protokollausgabeprozesses.
14 ist ein Ablaufplan eines Prüfpunkterzeugungsprozesses.
15 ist ein Ablaufplan eines (übergeordneten) Datenbank-Wiederherstellungsprozesses.
16 ist ein Ablaufplan eines (untergeordneten) Datenbank-Wiederherstellungsprozesses.
[Beschreibung von Ausführungsformen]
Im folgenden wird eine Ausführungsform anhand der Zeichnungen beschrieben.
In der folgenden Beschreibung enthalten Bezugszeichen gleichartiger Elemente das gleiche übergeordnete Bezugszeichen. Wenn gleichartige Elemente unterschieden werden, können die Bezugszeichen von Elementen verwendet werden (zum Beispiel Partitionen 111A, 111B, ...). Wenn gleichartige Elemente nicht unterschieden werden, ist es möglich, nur übergeordnete Bezugszeichen aus den Bezugszeichen von Elementen zu verwenden (zum Beispiel eine Partition 111).
In der folgenden Beschreibung kann es Fälle geben, in welchen ein Prozess unter Verwendung eines „Programms” als Subjekt beschrieben wird. Da ein gegebener Prozess durchgeführt wird, während nach Bedarf eine Speicherressource (zum Beispiel ein Speicher) und/oder einer Kommunikationsschnittstelleneinrichtung oder dergleichen verwendet wird, wenn ein Programm durch einen Prozessor ausgeführt wird, kann jedoch auch der Prozessor als Subjekt des Prozesses verwendet werden. Ein unter Verwendung des Programms als Subjekt beschriebener Prozess kann ein durch den Prozessor oder eine den Prozessor enthaltende Einrichtung (zum Beispiel einen Datenbankserver) durchgeführter Prozess sein. Überdies kann ein Prozessor eine Hardware-Schaltung enthalten, welche einen Teil der Prozesse oder alle Prozesse durchführt. Ein Programm kann aus einer Programmquelle in jeweiligen Steuereinheiten installiert werden. Die Programmquelle kann zum Beispiel ein Programmverteilungscomputer oder ein Speichermedium sein.
1 veranschaulicht eine Konfiguration eines Computersystems gemäß der Ausführungsform.
Eine externe Speichervorrichtung 402 ist zum Beispiel über ein Kommunikationsnetz 403 mit einem Datenbankserver 401 verbunden.
Der Datenbankserver 401 ist ein Computer und kann ein Personal Computer, eine Workstation oder ein Großrechner sein oder kann ein durch ein Virtualisierungsprogramm in diesen Computern konfigurierter virtueller Computer sein. Der Datenbankserver 401 enthält einen E/A-Adapter 413, einen Hauptspeicher 416, eine Speichereinheit 415 und einen mit diesen Komponenten verbundenen Prozessor 414. Der Prozessor 414 kann ein Modul sein, welches zum Beispiel einen Mikroprozessor enthält oder einen Mikroprozessor und eine zweckgebundene Hardware-Schaltung enthält. Der Prozessor 414 führt ein Computerprogramm aus. Das durch den Prozessor 414 ausgeführte Computerprogramm ist zum Beispiel ein Betriebssystem (OS) 117 und ein Datenbankverwaltungssystem (DBMS) 412. Der Hauptspeicher 416 ist zum Beispiel ein flüchtiger dynamischer Arbeitsspeicher (DRAM) und speichert vorübergehend ein durch den Prozessor 414 ausgeführtes Programm und von dem Programm verwendete Daten. Die Speichereinheit 415 ist nichtflüchtig und ist zum Beispiel ein Festplattenlaufwerk (HDD) oder ein Solid-State-Laufwerk (SSD). Die Speichereinheit 415 kann ein Programm und von dem Programm verwendete Daten speichern. Der E/A-Adapter 413 verbindet das Kommunikationsnetz 403 und den Datenbankserver 401.
Die externe Speichervorrichtung 402 ist eine Vorrichtung mit einer eine Vielzahl von Speichereinheiten enthaltenden Speichereinheitengruppe 451 und kann zum Beispiel eine Platteneinheiten-Vorrichtung sein und kann stattdessen eine einzelne Speichereinheit sein. Die externe Speichervorrichtung 402 speichert eine Protokolldatei 301. Die externe Speichervorrichtung 402 empfängt eine E/A-Anforderung für Protokolle vom Datenbankserver 401, liest/schreibt Daten (zum Beispiel Protokolle) gemäß der E/A-Anforderung und meldet das Lese-/Schreibergebnis an den Datenbankserver 401 zurück. Die in der Speichereinheitengruppe 451 enthaltene Speichereinheit ist eine Einrichtung mit einem nichtflüchtigen Speichermedium und ist zum Beispiel ein HDD oder ein SSD. Die Speichereinheitengruppe 451 kann eine „Redundant-Array-of-Independent-Disks”-(RAID-)Gruppe sein und kann Daten auf einer vorbestimmten RAID-Stufe speichern. Eine auf einem Speicherbereich der Speichereinheitengruppe 451 beruhende logische Speichereinheit (zum Beispiel eine logische Einheit, ein logischer Datenträger, ein Dateisystemdatenträger) kann für den Datenbankserver 401 vorgesehen sein, und die Protokolldatei 301 kann in der logischen Speichereinheit gespeichert werden. In der vorliegenden Ausführungsform ist die Protokolldatei 301 ein Beispiel eines Protokollspeicherbereichs.
Die externe Speichervorrichtung 402 enthält zusätzlich zur Speichereinheitengruppe 451 einen E/A-Adapter 441 und eine mit diesen Komponenten verbundene Speichersteuereinheit 442. Der E/A-Adapter 441 verbindet die externe Speichervorrichtung 402 mit dem Kommunikationsnetz 403, über welches der E/A-Adapter 441 mit dem Datenbankserver 401 verbunden ist. Zu Beispielen des im Kommunikationsnetz 403 verwendeten Kommunikationsprotokolls zählen Fibre Channel (FC), Small Computer System Interface (SCSI) und Transmission Control Protocol/Internet Protocol (TCP/IP). Zum Beispiel bei Verwendung von Fibre Channel oder SCSI wird der E/A-Adapter 441 (und 413) häufig als Host-Bus-Adapter bezeichnet. Die Speichersteuereinheit 442 enthält zum Beispiel einen Speicher und einen Prozessor und liest oder schreibt Daten aus der beziehungsweise in die Speichereinheitengruppe 451, welche die Protokolldatei 301 gemäß einer E/A-Anforderung vom Datenbankserver 401 speichert.
2 veranschaulicht ein Beispiel einer Transaktionsgruppe.
Diese Zeichnung veranschaulicht ein Beispiel zwischen zwei Prüfpunkten 1 und 2 ausgeführter Transaktionen. Die in der vorliegenden Ausführungsform ausgeführten Transaktionen sind in eine einer Erste-Klasse-Transaktionsgruppe und einer Zweite-Klasse-Transaktionsgruppe eingeteilt.
Die Erste-Klasse-Transaktionsgruppe ist eine Gruppe von Transaktionen, deren Ergebnisse sich je nach einer Transaktionsausführungsreihenfolge ändern. In dem veranschaulichten Beispiel ist eine Teilreihenfolge festgelegt. Gemäß der Teilreihenfolge kann eine Vielzahl verschiedene Datensätze aktualisierender Transaktionen in einer willkürlichen Reihenfolge ausgeführt werden, obwohl eine Vielzahl denselben Datensatz aktualisierender Transaktionen in einer festgelegten Reihenfolge ausgeführt werden muss.
Die Zweite-Klasse-Transaktionsgruppe ist eine Gruppe von Transaktionen, deren Ergebnisse von einer Transaktionsausführungsreihenfolge nicht beeinflusst werden.
Ob eine Ausführungsziel-Transaktion zur Erste-Klasse-Transaktionsgruppe oder zur Zweite-Klasse-Transaktionsgruppe gehört, lässt sich zum Beispiel gemäß einem Abfrageausführungsplan oder einer Vielzahl von Abfrageausführungsplänen bestimmen.
3 ist ein Blockschaubild eines Computersystems gemäß der Ausführungsform.
Das DBMS 412 ist eine speicherinterne Datenbank. Das DBMS 412 teilt eine Datenbank in eine Vielzahl von Partitionen 111 (zum Beispiel drei Partitionen 111A bis 111C) ein und ordnet die Partitionen im Hauptspeicher 416 an. Jede Partition 111 enthält einen Teil der Datenbank (zum Beispiel eine Tabelle 112, welche ein Teil von Tabellen in der Datenbank ist, und einen Index 113, welcher ein Teil von Indexen in der Datenbank ist). In einer Partition 111 (zum Beispiel 111A) lassen sich Daten aus der Tabelle 112 (zum Beispiel 112A) in der Partition 111 unter Verwendung des Index 113 (zum Beispiel 113A) in der Partition 111 angeben. Die in einer Tabelle 112 enthaltenen Daten lassen sich nur in der Partition 111, welche die Tabelle 112 enthält, aus dem Index 113 angeben. Überdies kann jede Partition 111 einen Sperrmechanismus 116 enthalten. Dies soll verhindern, dass zwei oder mehr Threads 110 bezüglich ein und derselben Partition 111 miteinander konkurrieren. Der Sperrmechanismus 116 kann aus einer Information bestehen, die angibt, ob eine Sperre der Partition 111 übernommen wurde. Zum Beispiel kann der Sperrmechanismus 116 auf einen Wert „1” gesetzt werden, wenn eine Sperre übernommen wurde, und auf einen Wert „0” gesetzt werden, wenn keine Sperre übernommen wurde. Der Sperrmechanismus 116 kann mit der Partition 111 in Wechselbeziehung stehen und kann sich außerhalb der Partition 111 befinden.
Das DBMS 412 enthält einen Protokollpuffer 114 und einen LLSN-Manager 115 für jede Partition 111. Der Protokollpuffer 114 speichert vorübergehend die Aktualisierungsvorgeschichte der Partition 111 enthaltende Protokolle. Der LLSN-Manager 115 verwaltet LLSNs. „LLSN” ist eine Abkürzung von „Local Log Sequence Number” (lokale Protokollfolgenummer). Die LLSNs sind Nummern, welche sich in einer Partition 111 nicht überschneiden. Die LLSN wird erzeugt, wenn Protokolle einer zur Erste-Klasse-Transaktionsgruppe (einer Gruppe von Transaktionen, deren Ergebnisse sich je nach einer Transaktionsausführungsreihenfolge ändern) gehörenden Transaktion ausgegeben werden. Die LLSN kann erzeugt werden, wenn die Protokolle einer zur Zweite-Klasse-Transaktionsgruppe gehörenden Transaktion ausgegeben werden, ohne auf die Erste-Klasse-Transaktionsgruppe beschränkt zu sein.
Das DBMS 412 empfängt eine Abfrage von einem Abfrageaussteller und führt während der Ausführung der empfangenen Abfrage eine Transaktion oder eine Vielzahl von Transaktionen aus. Speziell enthält das DBMS 412 einen Abfrageempfänger 421, einen Abfrageausführungsplan-Erzeuger 422 und einen Abfrageausführer 424.
Der Abfrageempfänger 421 empfängt eine von einem Abfrageaussteller ausgestellte Abfrage. Die Abfrage wird zum Beispiel durch eine strukturierte Abfragesprache (SQL) beschrieben. Eine Vielzahl von Transaktionen kann durch eine einzige Abfrage beschrieben werden, und eine Vielzahl von Transaktionen kann durch eine Vielzahl von Abfragen beschrieben werden. Überdies kann der Abfrageaussteller ein Computerprogramm innerhalb des DBMS 412 sein und kann er ein Computerprogramm außerhalb des DBMS 412 sein. Zum Beispiel kann das externe Computerprogramm ein im Datenbankserver 401 ausgeführtes Computerprogramm (zum Beispiel ein Anwendungsprogramm) sein und kann es ein durch eine Vorrichtung wie einen mit dem Datenbankserver 401 verbundenen Client-Computer ausgeführtes Computerprogramm (zum Beispiel ein Anwendungsprogramm) sein.
Der Abfrageausführungsplan-Erzeuger 422 erzeugt aus einer durch den Abfrageempfänger 421 empfangenen Abfrage einen eine oder mehr zum Ausführen der Abfrage erforderliche Datenbankoperationen enthaltenden Abfrageausführungsplan. Der Abfrageausführungsplan besteht aus Informationen, welche zum Beispiel eine oder mehr Datenbankoperationen und den Zusammenhang der Ausführungsreihenfolge der Datenbankoperationen enthalten, und ist als Abfrageausführungsplan-Informationen 423 gespeichert. Der Abfrageausführungsplan kann durch eine Baumstruktur ausgedrückt sein, in welcher eine Datenbankoperation ein Knoten ist und der Zusammenhang der Ausführungsreihenfolge der Datenbankoperationen ein Rand ist. Eine Transaktionsgruppe oder eine Vielzahl von Transaktionsgruppen und ob jede Transaktionsgruppe zur Erste-Klasse-Transaktionsgruppe oder zur Zweite-Klasse-Transaktionsgruppe gehört, lässt sich aus einem Abfrageausführungsplan oder einer Kombination aus einer Vielzahl von Abfrageausführungsplänen angeben.
Der Abfrageausführer 424 führt die durch den Abfrageempfänger 421 empfangene Abfrage gemäß dem durch den Abfrageausführungsplan-Erzeuger 422 erzeugten Abfrageausführungsplan aus und meldet ein Ausführungsergebnis derselben an den Abfrageaussteller zurück. In diesem Fall stellt der Abfrageausführer 424 eine Leseanforderung (eine Referenzanforderung) zum Lesen zur Ausführung einer Datenbankoperation erforderlicher Daten aus und führt er die Datenbankoperation unter Verwendung der gemäß der Leseanforderung aus der Partition 111 gelesenen Daten durch (zum Beispiel berechnet der Abfrageausführer 424 neue Daten unter Verwendung der gelesenen Daten (des Werts) und stellt er eine Schreibanforderung zum Aktualisieren von Daten in einem Lesequellen-Datensatz mit den berechneten Daten aus). Der Abfrageausführer 424 führt die Datenbankoperation durch Ausführen des Threads 110 durch. Im DBMS 412 wird eine Vielzahl von Threads 110 parallel ausgeführt. Somit enthält der Prozessor 414 eine Vielzahl von Kernen. Die Vielzahl von Kernen ist in einer oder in einer Vielzahl von CPUs vorhanden. Der Thread 110 kann als ein Task bezeichnet werden. Der Thread 110 kann zum Beispiel unter Verwendung eines Benutzerthreads, in welchem eine Bibliothek oder dergleichen realisiert ist, sowie eines Prozessors, eines Kernel-Threads oder dergleichen, in welchem das OS 117 realisiert ist, implementiert werden. Eine einer oder mehr Datenbankoperationen entsprechende Transaktion kann durch einen Thread 110 ausgeführt werden. Im folgenden kann der Thread 110 als Subjekt eines Prozesses, der durchgeführt wird, wenn der Abfrageausführer 424 den Thread 110 ausführt, verwendet werden.
Der Abfrageausführer 424 (der Thread 110) stellt eine E/A-Anforderung für die externe Speichervorrichtung 402 an das OS 117 aus, um während der Ausführung einer Transaktion Protokolle in die Protokolldatei 301 in der externen Speichervorrichtung 402 zu schreiben. Das OS 117 empfängt die E/A-Anforderung und stellt eine E/A-Anforderung an die externe Speichervorrichtung 402 aus.
Eine Vielzahl von E/A-Warteschlangen 201 (201A bis 201C) wird im E/A-Adapter 413 erstellt. Während der Verarbeitung einer Transaktion stellt der Thread 110 eine E/A-Anforderung zum Schreiben von Protokollen aus und wird die E/A-Anforderung in der E/A-Warteschlange 201 gespeichert. Speziell wird die E/A-Anforderung durch das OS 117 in der E/A-Warteschlange 201 gespeichert.
Die externe Speichervorrichtung 402 speichert eine Vielzahl von Protokolldateien 301 (301A bis 301C). Die Schreibzielprotokolle der E/A-Anforderung werden in der Protokolldatei 301 aufgezeichnet.
In der vorliegenden Ausführungsform stehen die Partition 111, die E/A-Warteschlange 201 und die Protokolldatei 301 in einer Eins-zu-eins-Entsprechung in Wechselbeziehung. Das heißt, für jede Partition 111 sind eine E/A-Warteschlange 201 und eine Protokolldatei 301 vorhanden. Speziell stehen eine E/A-Warteschlange 201A und eine Protokolldatei 301A mit einer Partition 111A in Wechselbeziehung, stehen eine E/A-Warteschlange 201B und eine Protokolldatei 301B mit einer Partition 111B in Wechselbeziehung und stehen eine E/A-Warteschlange 201C und eine Protokolldatei 301C mit einer Partition 111C in Wechselbeziehung. Ein Thread oder eine Vielzahl von Threads 110 kann in einer Protokolldatei 301 vorhanden sein. Jedoch kann die Verarbeitung der E/A-Anforderung verringert werden, wenn für jede E/A-Warteschlange 201 ein Interrupt zum Melden der Fertigstellung einer E/A-Anforderung an einen bestimmten Thread 110 gesendet wird. In diesem Fall können der Thread 110, die Partition 111 und die E/A-Warteschlange 201 zum Beispiel in einer Eins-zu-eins-Entsprechung in Wechselbeziehung stehen. In der vorliegenden Ausführungsform kann der Thread 110 bequemlichkeitshalber in einer Eins-zu-eins-Entsprechung mit der Protokolldatei 301 in Wechselbeziehung stehen. Zum Beispiel stellt der Thread 110A eine E/A-Anforderung eines Protokolls aus, welche besagt, dass ein Datensatz in der Tabelle 112A der Partition 111A auf die der Partition 111A entsprechende Protokolldatei 301A aktualisiert wird. Die ausgestellte E/A-Anforderung wird über den Protokollpuffer 114A an das OS 117 gesendet. Das OS 117 empfängt die E/A-Anforderung für die Protokolldatei 301A und speichert die E/A-Anforderung in der der Protokolldatei 301A entsprechenden E/A-Warteschlange 201A. Das OS 117 sendet die in der E/A-Warteschlange 201A gespeicherte E/A-Anforderung aus der E/A-Warteschlange 201 an die externe Speichervorrichtung 402. Infolgedessen wird das Protokoll, welches Zieldaten der E/A-Anforderung aufzeichnet, in die Protokolldatei 301A geschrieben.
Die in 3 veranschaulichte Konfiguration des DBMS 412 ist nur ein Beispiel. Zum Beispiel kann ein bestimmtes Bestandteilselement in eine Vielzahl von Bestandteilselementen geteilt sein und kann eine Vielzahl von Bestandteilselementen zu einem Bestandteilselement vereinigt sein.
4 veranschaulicht eine Konfiguration des LLSN-Managers 115.
Der LLSN-Manager 115 enthält einen Sperrmechanismus 121, eine LLSN 122 und eine Protokolldateiadresse 123.
Der Sperrmechanismus 121 kann aus Daten bestehen, welche angeben, ob eine Sperre des LLSN-Managers 115 übernommen wurde, ähnlich dem in 3 veranschaulichten Sperrmechanismus 116. Zum Beispiel kann der Sperrmechanismus 121 auf einen Wert „1” gesetzt werden, wenn eine Verriegelung übernommen wurde, und kann er auf einen Wert „0” gesetzt werden, wenn keine Verriegelung übernommen wurde.
Die LLSN 122 ist eine Folgenummer (LLSN) eines Protokolls für die Partition 111, welche den LLSN-Manager 115 enthält. Zum Beispiel ist die LLSN eine Kombination aus einer ID des LLSN-Managers 115 und einer Seriennummer. Zum Beispiel wenn der Thread 110A die LLSN aus dem LLSN-Manager 115A erzeugt, wird der durch die LLSN 122 angegebene Wert auf 1-001, 1-002, 1-003 oder dergleichen aktualisiert. Die LLSN ist eine Kombination aus der ID „1” des LLSN-Managers 115A und einer aktualisierten Seriennummer.
Die Protokolldateiadresse 123 ist eine Schreibzieladresse eines Protokolls in der der Partition 111, welche den LLSN-Manager 115 enthält, entsprechenden Protokolldatei 301. Zur durch die Protokolldateiadresse 123 angegebenen Adresse (dem Wert) wird die Größe eines Protokolls addiert, welches ausgegeben wird, wenn ein Protokoll in die Protokolldatei 301 geschrieben wird.
5 veranschaulicht eine Datenstruktur eines Protokolls.
Ein Protokoll kann für eine Transaktion erzeugt werden, und jedes Protokoll enthält die ID einer Transaktion, eine oder mehrere während der Ausführung der Transaktion erzeugte LLSNs und die Aktualisierungsvorgeschichte der Transaktion angebende Informationen. Die Anzahl von in einem Protokoll enthaltenen LLSNs ist die gleiche wie die Anzahl von während der Ausführung einer Transaktion aktualisierten Partitionen 111.
6 veranschaulicht eine Datenstruktur eines Prüfpunkt-Protokolls.
Ein Prüfpunkt-Protokoll ist ein Protokoll, in welchem ein Prüfpunkt erzeugt wird. Ein Prüfpunkt-Protokoll enthält die ID einer Transaktion, in welcher ein Prüfpunkt erzeugt wird, alle während der Erzeugung des Prüfpunkts erzeugten LLSNs und die ID des erzeugten Prüfpunkts. Während der Wiederherstellung einer Datenbank kann der Zeitpunkt, zu welchem die Wiederherstellung durchgeführt wird, unter Verwendung einer Prüfpunkt-ID angegeben werden. Die Prüfpunkt-ID kann ein Wert sein, welcher die Zeit angibt, zu welcher ein Prüfpunkt erzeugt wird.
7 veranschaulicht ein Beispiel einer Transaktionsgruppe. 8 veranschaulicht Tabellen 112A und 112B vor und nach Ausführung einer Transaktionsgruppe. In 7 (und in den später beschriebenen 9 bis 11) ist eine Transaktion als „Tr.” abgekürzt. Überdies hat in der folgenden Beschreibung ein Datensatz eine Zeilen-ID und einen Wert, wird ein Datensatz der Zeilen-ID:X als ein Datensatz X bezeichnet und wird ein Datensatz der Zeilen-ID:Y als ein Datensatz Y bezeichnet.
Die in 7 veranschaulichte Transaktionsgruppe ist die Erste-Klasse-Transaktionsgruppe, das heißt, eine Gruppe von Transaktionen, deren Ergebnisse sich je nach einer Transaktionsausführungsreihenfolge ändern. Die Datensätze X und Y werden je nach einer Transaktionsgruppe aktualisiert.
Wie in 8 veranschaulicht, ist der Datensatz X ein in der Tabelle 112A innerhalb der Partition 111A vorhandener Datensatz und ist der Datensatz Y ein in der Tabelle 112B innerhalb der Partition 111B vorhandener Datensatz. Bevor die in 7 veranschaulichte Transaktionsgruppe ausgeführt wird, ist der Wert des Datensatzes X „100” und ist der Wert des Datensatzes Y „100”. Bei Ausführung der in 7 veranschaulichten Transaktionsgruppe wird der Wert des Datensatzes X auf „110” aktualisiert und wird der Wert des Datensatzes Y auf „122” aktualisiert.
Gemäß der in 7 veranschaulichten Transaktionsgruppe ändern sich die Ergebnisse der Transaktionen A, B, und E je nach einer Ausführungsreihenfolge. Dies liegt daran, dass diese Transaktionen denselben Datensatz X aktualisieren. Entsprechend ändern sich die Ergebnisse der Transaktionen A, C und D je nach einer Ausführungsreihenfolge. Dies liegt daran, dass diese Transaktionen denselben Datensatz Y aktualisieren.
Jedoch ändern sich die Ergebnisse der Transaktion B und der Transaktion C oder D nicht ungeachtet einer Ausführungsreihenfolge derselben. Dies liegt daran, dass diese Transaktionen verschiedene Datensätze X und Y aktualisieren (anders ausgedrückt, die aktualisierten Datensätze nicht gemeinsam sind).
Somit ist es, wenn eine Datenbank auf der Grundlage von Protokollen wiederhergestellt wird, notwendig, eine minimale notwendige Transaktionsausführungsreihenfolge aufzuzeichnen. Das Implementierungsverfahren zum Festlegen der Teilreihenfolge für die ausgeführte Transaktionsgruppe ist nicht auf ein Verfahren beschränkt, und zum Beispiel kann das folgende Verfahren als ein Verfahren zum Aufzeichnen einer minimalen notwendigen Reihenfolgebeziehung verwendet werden.
Zum Beispiel wird, wie in 2 veranschaulicht, eine Folgenummer (eine Protokollerzeugungs-Folgenummer) gemäß einer festgeschriebenen Reihenfolge im Protokoll einer Transaktion (welche eine der Transaktionen ist, deren Ergebnisse je nach einer Transaktionsausführungsreihenfolge unterschiedlich ausfallen), welche zwischen einem willkürlichen Prüfpunkt 1 und einem später als der Prüfpunkt 1 erzeugten Prüfpunkt 2 ausgeführt wird und welche zur Erste-Klasse-Transaktionsgruppe gehört, aufgezeichnet. Andererseits wird die Folgenummer im Protokoll einer Transaktion (welche eine der Transaktionen ist, deren Ergebnisse sich nicht in Abhängigkeit von einer Transaktionsausführungsreihenfolge ändern und welche zwischen dem Prüfpunkt 1 und dem Prüfpunkt 2 ausgeführt werden), welche zur Zweite-Klasse-Transaktionsgruppe gehört, nicht aufgezeichnet. Auf diese Weise ist es möglich, die Teilreihenfolge der Protokolle der Erste-Klasse-Transaktionsgruppe zu definieren.
In der vorliegenden Ausführungsform werden während der Ausführung einer Transaktion LLSNs für jede aktualisierte Partition 111 erzeugt. Die für eine Partition 111 erzeugten LLSNs sind die Folgenummern der Partition 111 und stehen nicht in Beziehung zu den LLSNs der anderen Partition 111. Das heißt, in der vorliegenden Ausführungsform wird für jede Partition 111 eine Serie von LLSNs (Folgenummern) erzeugt und werden die erzeugten LLSNs in einem Protokoll aufgezeichnet, wodurch die Teilreihenfolge für die erste Transaktionsgruppe festgelegt wird.
Speziell werden Protokolle auf die folgende Weise ausgegeben. Das heißt, wie oben beschrieben, werden die Partition 111 und die Protokolldatei 301 in einer Eins-zu-eins-Entsprechung erstellt und werden die die Aktualisierungsvorgeschichte der Partition 111 enthaltenden Protokolle in die der Partition 111 entsprechende Protokolldatei 301 geschrieben. Überdies können N Partitionen 111 (N ist eine Ganzzahl größer als oder gleich 2) während der Ausführung einer Transaktion aktualisiert werden. Jedoch werden in diesem Fall N Protokolle nicht in N Protokolldateien, welche jeweils den N Partitionen 111 entsprechen, geschrieben, sondern werden M Protokolle (M ist kleiner als N) jeweils in Protokolldateien (M Protokolldateien) 301, deren Anzahl kleiner als die Anzahl (N) aktualisierter Partitionen 111 ist, geschrieben. In der vorliegenden Ausführungsform gilt M = 1. Das heißt, in der vorliegenden Ausführungsform wird ungeachtet des Werts von N (der Anzahl während der Ausführung einer Transaktion aktualisierter Partitionen 111) ein Protokoll in eine einer der aktualisierten Partitionen 111 entsprechende Protokolldatei 301 geschrieben. Jedoch werden N LLSNs, welche jeweils den N aktualisierten Partitionen entsprechen, in das Protokoll geschrieben.
9 veranschaulicht ein Beispiel der Protokollausgabe gemäß der Ausführungsform.
Es wird vorausgesetzt, dass die LLSN der Partition 111A einen Wert von 1-201 hat und die LLSN der Partition 111B einen Wert von 2-100 hat, bevor die in 7 veranschaulichte Transaktionsgruppe ausgeführt wird. Diese Werte sind nur Beispiele, und die LLSNs können auch andere Werte haben.
Zuerst wird bei der Ausführung der Transaktion A sowohl der Datensatz X der Partition 111A als auch der Datensatz Y der Partition 111B aktualisiert. Somit wird LLSN=1-201 aus dem LLSN-Manager 115A erzeugt und wird LLSN=2-100 aus dem LLSN-Manager 115B erzeugt. In diesem Schritt können die LLSNs der LLSN-Manager 115A und 115B jeweils um 1 erhöht werden, und infolgedessen kann die LLSN des LLSN-Managers 115A 1-202 werden und kann die LLSN des LLSN-Managers 115B 2-101 werden. Überdies ist, wenn die Partitionen 111A und 111B aktualisiert werden, ein Protokollausgabeziel eine der Protokolldateien 301A und 301B, welche den Partitionen 111A beziehungsweise 111B entsprechen (zum Beispiel kann das Ausgabeziel reihum aufeinanderfolgend umgeschaltet werden und kann es im voraus als eine der Protokolldateien bestimmt werden). In diesem Beispiel wird das Protokoll in die Protokolldatei A ausgegeben. Somit wird eine Protokolldateiadresse vom LLSN-Manager 115A übernommen und wird ein der Größe des ausgegebenen Protokolls entsprechender Wert zu der Protokolldateiadresse im LLSN-Manager 115A addiert. Der Thread 110A zeichnet, nachdem er die Transaktion A ausgeführt hat, die erzeugten LLSNs 1-201 und 2-100, die Transaktions-ID=A und die Aktualisierungsvorgeschichte der Datensätze X und Y in einem Protokoll auf und schreibt ein Protokoll 901A, in welchem diese Informationselemente von einer der übernommenen Protokolldateiadresse entsprechenden Position in der Protokolldatei 301A aufgezeichnet werden. Speziell speichert der Thread 110A das Protokoll 901A im Protokollpuffer 114A und stellt er eine Schreibanforderung aus, welche die übernommene Protokolldateiadresse unter Verwendung des Protokolls 901A als Schreibziel benennt. Das OS 117 empfängt die Schreibanforderung, schreibt die Schreibanforderung in die der Protokolldatei 301A entsprechende E/A-Warteschlange 201A und sendet die Schreibanforderung aus der E/A-Warteschlange 201A an die externe Speichervorrichtung 402. Die externe Speichervorrichtung 402 empfängt die Schreibanforderung, schreibt das der Schreibanforderung entsprechende Schreibzielprotokoll 901A in die Protokolldatei 301A und erwidert eine Fertigstellungsnachricht zu der Schreibanforderung. Die Fertigstellungsnachricht wird über das OS 117 an das DBMS 412 erwidert.
Anschließend wird bei der Ausführung der Transaktion B nur der Datensatz X der Partition 111A aktualisiert. Somit erzeugt der Thread 110A, nachdem er die Transaktion B ausgeführt hat, LLSN=1-202 aus dem LLSN-Manager 115A (die LLSN des LLSN-Managers 115A wird auf 1-203 erhöht), übernimmt er eine Protokolldateiadresse (die Größe eines ausgegebenen Zielprotokolls wird zur Protokolldateiadresse des LLSN-Managers 115A addiert) und gibt er ein die LLSN=1-202, die Transaktions-ID=B und die Aktualisierungsvorgeschichte des Datensatzes X enthaltendes Protokoll 901B in die der durch die Ausführung der Transaktion B aktualisierten Partition 111A entsprechende Protokolldatei 301A (die übernommene Protokolldateiadresse) aus.
Überdies wird bei der Ausführung der Transaktion C nur der Datensatz Y der Partition 111B aktualisiert. Somit erzeugt der Thread 110B, nachdem er die Transaktion C ausgeführt hat, LLSN=2-101 aus dem LLSN-Manager 115B (die LLSN des LLSN-Managers 115B wird auf 2-102 erhöht), übernimmt er eine Protokolldateiadresse (die Größe eines ausgegebenen Zielprotokolls wird zur Protokolldateiadresse des LLSN-Managers 115B addiert) und gibt er ein die LLSN=2-101, die Transaktions-ID=C und die Aktualisierungsvorgeschichte des Datensatzes Y enthaltendes Protokoll 901C in die der durch die Ausführung der Transaktion C aktualisierten Partition 111B entsprechende Protokolldatei 301B (die übernommene Protokolldateiadresse) aus.
Entsprechend wird, wenn die Transaktion D ausgeführt wird, LLSN=2-102 aus dem LLSN-Manager 115B erzeugt und wird ein die LLSN=2-102 enthaltendes Protokoll 901D in die Protokolldatei 301B geschrieben.
Schließlich werden, wenn die Transaktion E ausgeführt wird, LLSNs=1-103 und 2-103 aus den LLSN-Managern 115A beziehungsweise 115B erzeugt und wird ein die erzeugten LLSNs enthaltendes Protokoll 901E in die Protokolldatei 301B geschrieben.
Wenn die Protokolle auf diese Weise ausgegeben werden, kann die Reihenfolge von Transaktionen A→B→E und Transaktionen A→C→D→E durch Verweisen auf die LLSNs der jeweiligen Protokolle wiederhergestellt werden. Dass eine erste LLSN größer als eine zweite LLSN für dieselbe Partition ist, bedeutet in der vorliegenden Ausführungsform, dass die erste LLSN später als die zweite LLSN (in der Zukunft) erzeugt wurde. Dass die erste LLSN größer als die zweite LLSN ist, kann einem abgeänderten Beispiel bedeuten, dass die erste LLSN früher als die zweite LLSN (in der Vergangenheit) erzeugt wurde. Das heißt, es ist lediglich erforderlich, die Reihenfolgebeziehung aus der Größenbeziehung von LLSNs anzugeben.
Gewöhnlich wird, wenn eine Reihenfolgebeziehung (diese wird bequemlichkeitshalber durch „≥” dargestellt) zwischen Transaktionen durch eine Größenbeziehung von LLSNs eines der LLSN-Manager 115 festgelegt ist, die Teilreihenfolge einer gesamten Gruppe von Transaktionen bestimmt, abgesehen von mehreren Ausnahmen. Zum Beispiel können in den LLSNs des LLSN-Managers 115A Transaktionen in der Reihenfolge von Transaktionen A→B als (A ≥ B) angeordnet sein und können in den LLSNs des LLSN-Managers 115B Transaktionen in der Reihenfolge von Transaktionen B→A als (B ≥ A) angeordnet sein. In diesem Fall werden die Transaktionen A und B so behandelt, dass die Reihenfolge der Transaktionen nicht festgelegt wird. Tatsächlich heben die Transaktionen A und B die Sperren der durch die Transaktionen A und B aktualisierten Datensätze nicht auf, bis die Transaktionen enden. Somit kommt es zu einem solchen Ereignis, da die durch die Transaktionen A und B aktualisierten Datensätze verschieden sind, und können die Transaktionen A und B in einer willkürlichen Reihenfolge ausgeführt werden.
Im folgenden werden Vergleichsbeispiele 1 und 2 der Protokollausgabe der in 7 veranschaulichten Transaktionsgruppe beschrieben.
10 veranschaulicht ein Beispiel der Protokollausgabe gemäß Vergleichsbeispiel 1.
In Vergleichsbeispiel 1 werden fünf Transaktionen A bis E entsprechende fünf Protokolle in eine einzige Protokolldatei ausgegeben. In Vergleichsbeispiel 1 werden die Protokolle in der Transaktionsausführungsreihenfolge in die Protokolldatei ausgegeben. In diesem Fall werden die Protokolle, auch wenn zwei oder mehr Transaktionen parallel ausgeführt werden, aufeinanderfolgend ausgegeben und können Transaktionen um eine E/A-Ressource (zum Beispiel eine einer einzelnen Protokolldatei entsprechende einzelne E/A-Warteschlange) konkurrieren.
In der vorliegenden Ausführungsform wird eine Vielzahl von Protokolldateien erstellt und wird eine Vielzahl von E/A-Ressourcen (zum Beispiel E/A-Warteschlangen) welche jeweils der Vielzahl von Protokolldateien entsprechen, erstellt. Auf diese Weise ist es möglich, eine Konkurrenz um I/O-Ressourcen zu verringern.
11 veranschaulicht ein Beispiel der Protokollausgabe gemäß Vergleichsbeispiel 2.
Vergleichsbeispiel 2 veranschaulicht ein Beispiel der in einer verteilten Datenbank durchgeführten Protokollausgabe. Für eine Transaktion, welche eine der Partitionen 111A und 111B aktualisiert, wie die Transaktionen B, C und D, werden die Protokolle genauso wie in der Ausführungsform ausgegeben. Jedoch wird für eine Transaktion, welche beide Partitionen 111A und 111B aktualisiert, wie die Transaktion A (und E) die gleiche Anzahl von Protokollen wie die Anzahl von aktualisierten Partitionen jeweils in die gleiche Anzahl von Protokolldateien ausgegeben. Somit ist die Anzahl von Protokoll-E/As größer als diejenige der Ausführungsform.
Das heißt, in der vorliegenden Ausführungsform ist die Anzahl geschriebener Protokolle, auch wenn eine Transaktion eine Vielzahl von Partitionen aktualisiert, kleiner als die Anzahl aktualisierter Partitionen. Somit ist es möglich, die Anzahl von Protokoll-E/As zu unterdrücken.
In der vorliegenden Ausführungsform, wie oben beschrieben, gibt es einen Fall, in welchem die Ausführungsreihenfolge nicht in Abhängigkeit von einer Transaktion festgelegt wird. Zum Beispiel ist es im Protokoll unbestimmt, welche der Transaktionen B und C die Ausführung früher als die andere abgeschlossen hat. Somit ist es gewöhnlich nicht möglich, die Datenbank in einem anderen Zustand eines beliebigen Zeitpunkts als dem letzten Zustand wiederherzustellen. Deshalb ist es in der vorliegenden Ausführungsform, wie oben beschrieben, durch Erzeugen des Prüfpunkts möglich, den Zustand der Datenbank zu einem beliebigen Zeitpunkt aufzuzeichnen und wiederherzustellen.
Im folgenden werden die in der Ausführungsform durchgeführten Prozesse beschrieben.
12 ist ein Ablaufplan eines Transaktionsprozesses. In der folgenden Beschreibung wird eine Transaktion A als ein Beispiel beschrieben. Somit ist ein Thread, welcher die Transaktion A ausführt, der Thread 110A und sind die durch die Transaktion A aktualisierten Partitionen die Partitionen 111A und 111B und sind die den Partitionen 111A und 111B entsprechenden Protokolldateien die Protokolldateien 301A beziehungsweise 301B.
Wenn die Transaktion A beginnt, erzeugt der Thread 110A auf der Grundlage einer der Transaktion A entsprechenden Anweisung (einer Anweisung in einer Abfrage) eine Verweis/Aktualisierungs-Gruppe für jede der Partitionen 111A und 111B (S301). Die Verweis/Aktualisierungs-Gruppe ist eine Gruppe aus einem Verweis auf einen Datensatz (einer Leseanforderung für eine Partition) und einer Aktualisierung eines Datensatzes (einer Schreibanforderung für eine Partition). Obwohl die Verweis/Aktualisierungs-Gruppe eine Anforderungsgruppe zum Aktualisieren von Partitionen ist, werden die Partitionen 111A und 111B zum Zeitpunkt von S301 nicht aktualisiert, sondern wird die Verweis/Aktualisierungs-Gruppe in einem der Transaktion A entsprechenden lokalen Speicherbereich (einem im Hauptspeicher 461 gesicherten Bereich (nicht gezeigt)) aufrechterhalten.
Anschließend nimmt der Thread 110A eine Festschreibungsbestimmung vor (S302). Die Festschreibungsbestimmung erfolgt durch Bestimmen, ob die Vereinbarkeit mit anderen Transaktionen aufrechterhalten werden kann, auch wenn die Transaktion A die Partitionen 111A und 111B auf der Grundlage der Verweis/Aktualisierungs-Gruppe gemäß einer Isolationsstufe einer Datenbank aktualisiert.
Wenn die Festschreibungsbestimmung „Nicht OK” ergibt (S303: Nein), führt der Thread 110A einen Abbruchprozess durch (S307).
Wenn die Festschreibungsbestimmung „OK” ergibt (S303: Ja), führt der Thread 110A einen Protokollausgabeprozess aus (S304). Anschließend aktualisiert der Thread 110A die Partitionen 111A und 111B auf der Grundlage der Verweis/Aktualisierungs-Gruppe (S305), sendet er eine Festschreibungsfertigstellungsnachricht (S306) und beendet er die Transaktion.
13 ist ein Ablaufplan des Protokollausgabeprozesses (S304 in 12).
Der LLSN-Manager 115 der mit dem Thread 110A, welcher die Transaktion A ausführt, in Wechselbeziehung stehenden Protokolldatei 301A ist der LLSN-Manager 115A. Der Thread 110A übernimmt eine Protokolldateiadresse vom LLSN-Manager 115A und addiert die Größe des Protokolls der Transaktion A zur Protokolldateiadresse des LLSN-Managers 115A (S401). Der Thread 110A übernimmt eine Sperre des LLSN-Managers 115A, bevor diese Serie von Operationen durchgeführt wird, und hebt die Sperre auf, nachdem die Operationen durchgeführt wurden. Wenn der LLSN-Manager 115 und die Protokolldatei 301 nicht mit dem Thread 110A in Wechselbeziehung stehen, wählt der Thread 110A einen willkürlichen LLSN-Manager 115 aus und führt er den gleichen Prozess an dem ausgewählten LLSN-Manager 115 durch. Jedoch muss das Protokoll, um ein Steckenbleiben in einem später beschriebenen Wiederherstellungsprozess zu vermeiden, in die dem in S401 arbeitenden LLSN-Manager 115 entsprechende Protokolldatei 301 geschrieben werden.
Anschließend erzeugt der Thread 110A die LLSN der durch die Ausführung der Transaktion A aktualisierten Partition 111A oder 111B (S402). Je nach einer Isolationsstufe oder einer Datenstruktur einer Datenbank kann es auch notwendig sein, die LLSN der durch die Ausführung der Transaktion A referenzierten Partition zu erzeugen.
Wenn es unter den aktualisierten Partitionen 111A und 111B eine Partition gibt, deren LLSN nicht erzeugt wird (S403: Nein), führt der Thread 110A an der Partition, deren LLSN nicht erzeugt wird, S402 durch. Andererseits, wenn die LLSNs aller aktualisierten Partitionen 111A und 111B erzeugt wurden (S403: Nein), erzeugt der Thread 110A das Protokoll 901A (siehe 9), schreibt er das Protokoll 901A in den Protokollpuffer 114A und stellt er eine Schreibanforderung für das Protokoll 901A aus (eine Schreibanforderung, welche die vom LLSN-Manager 115A übernommene Protokolldateiadresse benennt) (S404). Der Thread 110A schließt den Schreibvorgang ab, wenn eine Schreibvorgangsfertigstellungsnachricht von der externen Speichervorrichtung 402 über den E/A-Adapter 413 empfangen wird, (S405) und beendet den Protokollausgabe-Ablauf.
14 ist ein Ablaufplan eines Prüfpunkterzeugungsprozesses. In der Beschreibung von 14 wird vorausgesetzt, dass ein Thread, der einen Prüfpunkt erzeugt, der Thread 110A ist.
Zuerst hemmt der Thread 110A den Start einer neuen Festschreibung (S501). Speziell erstellt der Thread 110A ein Markierungsbit, welches eine Hemmung einer neuen Festschreibung in einem gemeinsam genutzten Threadbereich anzeigt, und setzt einen Anfangswert desselben auf 0. Wenn der Start einer neuen Festschreibung gehemmt wird, setzt der Thread 110A das Markierungsbit auf 1. Ein Thread, welcher eine Transaktion ausführt, prüft das Markierungsbit zu Beginn der Ausführung eines Festschreibungsprozesses und führt den Festschreibungsprozess nur aus, wenn das Markierungsbit 0 ist, wohingegen er, wenn das Markierungsbit 1 ist, in einem Wartezustand bleibt, bis das Markierungsbit auf 0 wechselt. Nachdem der Thread 110A den Prozess des Hemmens des Starts einer neuen Festschreibung durchgeführt hat, kann kein Thread 110 eine Festschreibung starten und geht die Festschreibung nur für eine festgeschriebene Transaktion weiter.
Der Thread 110A wartet, bis die Anzahl von Festschreibungstransaktionen 0 erreicht (S502: Nein). Wenn die Anzahl von Festschreibungstransaktionen 0 erreicht (S502: Ja), erzeugt der Thread 110A LLSNs und übernimmt er eine Protokolldateiadresse von dem einer willkürlich ausgewählten Protokolldatei 301 (zum Beispiel 301A) entsprechenden LLSN-Manager 115 (zum Beispiel 115A) und addiert er einen der Größe des Prüfpunkt-Protokolls entsprechenden Wert zu der Protokolldateiadresse im LLSN-Manager 115 (zum Beispiel 115A) (S503).
Ferner erzeugt der Thread 110A alle den übrigen Protokolldateien entsprechenden LLSNs (S504). Der Thread 110A erstellt ein die in S503 erzeugten LLSNs, die in S504 erzeugten LLSNs und eine Prüfpunkt-ID enthaltendes Prüfpunkt-Protokoll. Der Thread 110A schreibt eine Protokoll-Schreibanforderung (deren Schreibziel das erstellte Prüfpunkt-Protokoll ist), welche die in S503 übernommene Protokolldateiadresse dem der willkürlich ausgewählten Protokolldatei 301 (zum Beispiel 301A) entsprechenden Protokollpuffer 114 (zum Beispiel 114A) benennt, und stellt die Protokoll-Schreibanforderung aus dem Protokollpuffer 114 (zum Beispiel 114A) aus (S505).
Anschließend bestimmt der Thread 110A, ob eine Datenbanksicherungsbedingung erfüllt ist (S506). Die Bedingung kann erfüllt sein, wenn die Anzahl, wie oft der Prüfpunkt erzeugt wurde, N erreicht (N ist eine natürliche Zahl), und kann erfüllt sein, wenn eine vorbestimmte Zeitdauer ab dem Zeitpunkt, zu welchem eine vorherige Sicherungsoperation durchgeführt wurde, verstrichen ist.
Wenn das Bestimmungsergebnis in S506 „wahr” ist (S506: Ja), bringt der Thread 110A die Sicherung (das heißt, die Datenbank (die Tabelle 112 und den Index 113 jeder Partition 111) im Hauptspeicher 416) der Datenbank mit der im Prüfpunkt-Protokoll enthaltenen Prüfpunkt-ID in Wechselbeziehung und speichert er die mit der Prüfpunkt-ID in Wechselbeziehung stehende Datenbank (das Image) in der externen Speichervorrichtung 402 (S507). Diese Operation ist nicht immer für alle Prüfpunkte notwendig. Jedoch ist es durch Sichern der Datenbank während des Schreibens des Prüfpunkt-Protokolls möglich, die Datenbank (oder die Datenbank zum dem Zeitpunkt von Prüfpunkten nahen Zeitpunkt) zum Zeitpunkt der Erzeugung von Prüfpunkten mit einer hohen Geschwindigkeit wiederherzustellen. Der Thread kann die Entsprechung zwischen der gesicherten Datenbank (dem Image), der Prüfpunkt-ID und einer Schreibzieladresse des die Prüfpunkt-ID enthaltenden Prüfpunkt-Protokolls enthaltende Informationen (im folgenden als Prüfpunktverwaltungsinformationen bezeichnet) in einem Speicherbereich (zum Beispiel im Hauptspeicher 416) innerhalb oder außerhalb des Datenbankservers 401 speichern.
Nach Fertigstellung der Sicherung oder wenn das Bestimmungsergebnis in S506 „falsch” ist (S506: Nein), hebt der Thread 110A die Hemmung des Starts einer neuen Festschreibung auf (S508) und endet der Prüfpunkterzeugungsprozess. Speziell setzt der Thread 110A das Markierungsbit, welches die Hemmung einer neuen Festschreibung anzeigt, von 1 auf 0.
15 ist ein Ablaufplan eines (übergeordneten) Datenbankwiederherstellungsprozesses. In der Beschreibung von 15 (und 16) wird vorausgesetzt, dass ein Thread, welcher die Datenbank wiederherstellt, der Thread 110A ist.
Der Thread 110A lädt, auf der Grundlage der Prüfpunktverwaltungsinformationen, eine mit der Prüfpunkt-ID eines benannten Prüfpunkts in Wechselbeziehung stehende Datenbank (ein Sicherungs-Image) oder eine mit einer früher als die Prüfpunkt-ID des benannten Prüfpunkts erzeugten Prüfpunkt-ID in Wechselbeziehung stehende Datenbank (ein Sicherungs-Image) aus der externen Speichervorrichtung 402 in den Hauptspeicher 416 (S601). Die Prüfpunkt-ID kann in der von einem Abfrageaussteller empfangenen Abfrage benannt sein und kann durch einen mit dem Datenbankserver 401 verbundenen Computer (zum Beispiel einen Verwaltungscomputer) (nicht gezeigt) benannt sein.
Der Thread 110A übernimmt, auf der Grundlage der Prüfpunktverwaltungsinformationen, ein die mit der Datenbank in Wechselbeziehung stehende Prüfpunkt-ID enthaltendes Prüfpunkt-Protokoll aus der Adresse (Protokolldatei) des Prüfpunkt-Protokolls und setzt die LLSNs im Protokoll auf die LLSNs der LLSN-Manager 115 in den den LLSNs entsprechenden Partitionen 111 (S602). Zum Beispiel wird eine LLSN, welche mit der Ziffer 1 beginnt, auf die LLSN des LLSN-Managers 115A gesetzt und wird eine LLSN, welche mit der Ziffer 2 beginnt, auf die LLSN des LLSN-Managers 115B gesetzt.
Wenn die mit der geladenen Datenbank in Wechselbeziehung stehende Prüfpunkt-ID von der benannten Prüfpunkt-ID verschieden ist (S603: Nein), veranlasst der Thread 110A die den jeweiligen Partitionen 111 entsprechenden Threads 110, einen (untergeordneten) Wiederherstellungsprozess auszuführen (S604). Was die Partition 111A anbelangt, führt der Thread 110A den (untergeordneten) Wiederherstellungsprozess aus. Der Thread 110A wartet auf das Ende des (untergeordneten) Wiederherstellungsprozesses (S605: Ja) und beendet den (übergeordneten) Wiederherstellungsprozess.
Andererseits, wenn die mit der geladenen Datenbank in Wechselbeziehung stehende Prüfpunkt-ID mit der benannten Prüfpunkt-ID identisch ist (S603: Ja), beendet der Thread 110A den (übergeordneten) Wiederherstellungsprozess, ohne S604 und S605 auszuführen. Dies liegt daran, dass die in S601 geladene Datenbank die wiederherzustellende Datenbank ist.
16 ist ein Ablaufplan eines (untergeordneten) Datenbank-Wiederherstellungsprozesses.
Der (untergeordnete) Wiederherstellungsprozess wird für jede Partition 111 ausgeführt. Im folgenden wird der (untergeordnete) Wiederherstellungsprozess für eine Partition 111B als ein Beispiel beschrieben.
Der Thread 110B übernimmt die im (übergeordneten) Wiederherstellungsprozess gesetzte LLSN (die LLSN im LLSN-Manager 115B) als die LLSN zum Zeitpunkt der Sicherung (S700). Im folgenden wird, in der der Partition 111B entsprechenden Protokolldatei 301B, ein eine LLSN, die größer als die in S705 übernommene LLSN (die früher als zum Zeitpunkt der Erzeugung der benannten Prüfpunkt-ID erzeugte LLSN) und älter als die benannte Prüfpunkt-ID ist, enthaltendes Protokoll als ein „gesichertes Protokoll” bezeichnet. Ein die größte LLSN der gesicherten Protokolle enthaltendes gesichertes Protokoll kann ein Abschlussprotokoll der Protokolldatei 301B sein. Überdies können die gesicherten Protokolle ein gesichertes Protokoll enthalten, welches zusätzlich zur LLSN der Partition 111B eine andere LLSN als die LLSN der Partition 111B enthält. Im folgenden wird die LLSN der Partition 111B als eine „entsprechende LLSN” bezeichnet und wird die andere LLSN als die LLSN der Partition 111B als eine „nicht-entsprechende LLSN” bezeichnet.
Der Thread 110B gibt ein die kleinste entsprechende LLSN enthaltendes gesichertes Protokoll aus den nicht-verarbeiteten gesicherten Protokollen in der der Partition 111B entsprechenden Protokolldatei 301B an (S701). Im folgenden wird das in S701 angegebene gesicherte Protokoll als ein „Zielprotokoll” bezeichnet.
Der Thread 110B bestimmt, ob die entsprechende LLSN im Zielprotokoll eine der vorherigen entsprechenden LLSN im in S705 oder S706 verarbeiteten gesicherten Protokoll nächstfolgende entsprechende LLSN (eine durch Addieren von 1 zur vorherigen entsprechenden LLSN im in S705 oder S706 verarbeiteten gesicherten Protokoll erhaltene entsprechende LLSN) ist (S702).
Wenn das Bestimmungsergebnis in S702 „wahr” ist (S702: Ja), bestimmt der Thread 110B, ob eine nicht-entsprechende LLSN im Zielprotokoll enthalten ist.
Wenn das Bestimmungsergebnis in S704 „wahr” ist (S704: Ja), aktualisiert der Thread 110B die Partition 111B innerhalb der Aktualisierungsvorgeschichte im Zielprotokoll und sendet er eine Kopie des Zielprotokolls an einen der der nicht-entsprechenden LLSN entsprechenden Partition entsprechenden Thread (einen Thread, welcher den (untergeordneten) Wiederherstellungsprozess der der nicht-entsprechenden LLSN entsprechenden Partition ausgeführt hat) (S705). Zum Beispiel wenn die Anfangsziffer der nicht-entsprechenden LLSN 1 ist, wird die Kopie des Zielprotokolls an den Thread 110A gesendet. Wenn zwei oder mehr nicht-entsprechende LLSNs vorhanden sind, wird die Kopie des Zielprotokolls an zwei oder mehr den zwei oder mehr nicht-entsprechenden LLSNs entsprechende Partitionen entsprechende Threads gesendet.
Wenn das Bestimmungsergebnis in S704 „falsch” ist (S704: Nein), aktualisiert der Thread 110B die Partition 111B gemäß der Aktualisierungsvorgeschichte im Zielprotokoll (S706).
Wenn das Bestimmungsergebnis in S702 „falsch” ist (S702: Nein), bedeutet dies, dass ein die auszuführende Aktualisierungsvorgeschichte enthaltendes Protokoll in einer anderen Protokolldatei als der Protokolldatei 301B gespeichert wird. Somit wartet der Thread 110B, entgegen S705, auf eine Kopie eines die auszuführende Aktualisierungsvorgeschichte aus dem anderen Thread enthaltenden Protokolls (eines eine einer vorherigen entsprechenden LLSN im in S705 oder S706 verarbeiteten gesicherten Protokoll nächstfolgende entsprechende LLSN enthaltenden Protokolls). Wenn die Kopie des Protokolls empfangen wird (S703), aktualisiert der Thread 110B die Partition 111B gemäß der Aktualisierungsvorgeschichte in der Kopie des Protokolls (S706).
Nachdem S705 oder S706 durchgeführt wurde, bestimmt der Thread 110B, ob es ein nicht-verarbeitetes gesichertes Protokoll gibt (S707). Wenn ein nicht-verarbeitetes gesichertes Protokoll vorhanden ist (S707: Ja), wird S701 erneut durchgeführt. Wenn kein nicht-verarbeitetes gesichertes Protokoll vorhanden ist (S707: Ja), endet der (untergeordnete) Wiederherstellungsprozess an der Partition 111B.
Obwohl eine Ausführungsform beschrieben wurde, ist die vorliegende Erfindung nicht auf die Ausführungsform beschränkt.
Zum Beispiel kann auch ein anderes DBMS als die speicherinterne Datenbank als das DBMS verwendet werden. Eine Vielzahl von Datenbank-Teilen, welche eine Datenbank bilden, kann auf eine Vielzahl verschiedener Datenbankserver verteilt sein, und mindestens einer aus der Vielzahl von Datenbank-Teilen kann in einer externen Speichervorrichtung gespeichert sein.
Überdies kann die Protokolldatei 301 (und ein Datenbank-Teil) in der Speichereinheit 415 im Datenbankserver 401 statt in der externen Speichervorrichtung 402 gespeichert werden.
Überdies können Folgenummern (Protokollerzeugungsreihenfolge wie LLSN) der Protokolle zur Zweite-Klasse-Transaktionsgruppe gehörender Transaktionen aufgezeichnet werden. Jedoch ist es ähnlich der Ausführungsform, wenn in den Protokollen der zur Zweite-Klasse-Transaktionsgruppe gehörenden Transaktionen keine LLSNs aufgezeichnet werden, da es nicht notwendig ist, LLSNs zu erzeugen, obwohl Protokolle erzeugt werden, möglich, die Auslastung des Prozessors 414 zu verringern.
Überdies kann statt der Protokolldatei 301 ein anderer Protokollspeicherbereich verwendet werden. Zum Beispiel kann der Protokollspeicherbereich ein Bereich in der externen Speichervorrichtung 402, im Hauptspeicher 416 oder in der Speichereinheit 415 sein und kann eine für jedes Protokoll erzeugte Protokolldatei in den Bereich geschrieben werden. Das heißt, obwohl in der oben beschriebenen Ausführungsform eine Vielzahl von Protokollen in eine Protokolldatei geschrieben wird, kann in einem abgeänderten Beispiel eine Protokolldatei für ein Protokoll in den Protokollspeicherbereich geschrieben werden.
Überdies kann die LLSN eine Kombination aus der ID des entsprechenden LLSN-Managers 115 und einem Zeitstempel sein.
Überdies können zwei oder mehr Prüfpunkt-Protokolle für ein und denselben Prüfpunkt erzeugt werden und können alle allen LLSN-Managern 115 entsprechenden LLSNs in den zwei oder mehr Prüfpunkt-Protokollen aufgezeichnet werden. Jedoch ist die Anzahl für ein und denselben Prüfpunkt erzeugter Prüfpunkt-Protokolle vorzugsweise kleiner als die Anzahl von Partitionen 111. Dies soll die Anzahl von Protokoll-E/As verringern. Das Prüfpunkt-Protokoll kann in einem anderen Bereich als der Protokolldatei (zum Beispiel im Hauptspeicher 416) gespeichert sein.
Überdies kann der Wiederherstellungsprozess durch einen getrennt vom Abfrageausführer bereitgestellten Wiederherstellungsausführer (nicht gezeigt) statt durch den der Thread (den Abfrageausführer) durchgeführt werden. Das heißt, in der Ausführungsform kann ein Wiederherstellungsausführer getrennt vom Abfrageausführer bereitgestellt sein, obwohl der Abfrageausführer als Wiederherstellungsausführer dient.
Bezugszeichenliste

401: Datenbankserver
402: Externe Speichervorrichtung

Claims

Datenbankverwaltungssystem zum Verwalten einer Datenbank, enthaltend: einen Abfrageempfänger, der so konfiguriert ist, dass er eine Abfrage über die Datenbanken von einem Abfrageaussteller empfängt; und einen Abfrageausführer, der so konfiguriert ist, dass er auf der Grundlage von Informationen bezüglich der empfangenen Abfrage eine Vielzahl von Transaktionen ausführt, ein Protokoll für jede Transaktion erzeugt und Protokoll-Schreibanforderungen zum Schreiben der erzeugten Protokolle in Protokollspeicherbereiche ausstellt, wobei der Abfrageausführer so konfiguriert ist, dass er in den Protokollen zu einer Erste-Klasse-Transaktionsgruppe, welche eine Gruppe von Transaktionen ist, deren Ergebnisse je nach einer Transaktionsausführungsreihenfolge unterschiedlich ausfallen, gehörender Transaktionen Folgenummern von Protokollen aufzeichnet.
Datenbankverwaltungssystem nach Anspruch 1, außerdem enthaltend: Folgenummer-Manager, die so konfiguriert sind, dass sie die Folgenummer des Protokolls bezüglich jedes aus einer Vielzahl von Datenbank-Teilen, welche getrennte Teile der Datenbanken sind, verwalten, wobei die durch jeden Folgenummer-Manager verwaltete Folgenummer jedesmal aktualisiert wird, wenn das Protokoll einer Transaktion, welche den dem Folgenummer-Manager entsprechenden Datenbank-Teil aktualisiert hat, erzeugt wird, M Protokolle (M ist eine Ganzzahl größer als oder gleich 1 und kleiner als oder gleich N) als die Protokolle einer Transaktion, welche N Datenbank-Teile (N ist eine Ganzzahl größer als oder gleich 2) aus der Vielzahl von Datenbank-Teilen aktualisiert hat, erzeugt werden, und mindestens eines der M Protokolle zwei oder mehr Folgenummern aus N Folgenummern, welche jeweils den N Datenbank-Teilen entsprechen, enthält.
Datenbankverwaltungssystem nach Anspruch 2, wobei N Protokollspeicherbereiche, welche jeweils den N Datenbank-Teilen entsprechen, vorgesehen sind, ein Protokoll, welches eine Folgenummer enthält, in einen der Folgenummer entsprechenden Protokollspeicherbereich geschrieben wird, und ein Protokoll, welches die zwei oder mehr Folgenummern enthält, in einen der zwei oder mehr Protokollspeicherbereiche, welche jeweils den zwei oder mehr Folgenummern entsprechen, geschrieben wird.
Datenbankverwaltungssystem nach Anspruch 2, wobei M = 1.
Datenbankverwaltungssystem nach Anspruch 2, wobei eine Vielzahl von E/A-(Eingabe/Ausgabe-)Ressourcen, welche jeweils der Vielzahl von Datenbank-Teilen entsprechen, vorgesehen ist, ein Protokoll, welches eine Folgenummer enthält, über eine der Folgenummer entsprechende E/A-Ressource in einen der E/A-Ressource entsprechenden Protokollspeicherbereich geschrieben wird, und ein Protokoll, welches die zwei oder mehr Folgenummern enthält, über eine von zwei oder mehr E/A-Ressourcen, welche jeweils den zwei oder mehr Folgenummern entsprechen, in einen der E/A-Ressource entsprechenden Protokollspeicherbereich geschrieben wird.
Datenbankverwaltungssystem nach Anspruch 1, wobei der Abfrageausführer so konfiguriert ist, dass er in Protokollen zu einer Zweite-Klasse-Transaktionsgruppe, welche eine Gruppe von Transaktionen ist, auf deren Ergebnisse sich eine Transaktionsausführungsreihenfolge nicht auswirkt, gehörender Transaktionen Folgenummern nicht aufzeichnet.
Datenbankverwaltungssystem nach Anspruch 6, wobei der Abfrageausführer so konfiguriert ist, dass er auf der Grundlage der Informationen über die Abfrage bestimmt, ob eine Ausführungsziel-Transaktion zur Erste-Klasse-Transaktionsgruppe oder zur Zweite-Klasse-Transaktionsgruppe gehört.
Datenbankverwaltungssystem nach Anspruch 7, außerdem enthaltend: einen Abfrageausführungsplan-Erzeuger, der so konfiguriert ist, dass er auf der Grundlage der empfangenen Abfrage einen eine oder mehr zum Ausführen der empfangenen Abfrage notwendige Datenbankoperationen angebende Informationen und eine Ausführungsreihenfolge der einen oder mehr Datenbankoperationen enthaltenden Abfrageausführungsplan erzeugt, wobei die Informationen bezüglich der Abfrage den Abfrageausführungsplan angebende Informationen sind.
Datenbankverwaltungssystem nach Anspruch 1, wobei der Abfrageausführer so konfiguriert ist, dass er ein oder mehrere Prüfpunkt-Protokolle, die alle Folgenummern enthalten, welche jeweils allen Folgenummer-Managern entsprechen, für jeden Prüfpunkt erzeugt.
Datenbankverwaltungssystem nach Anspruch 9, wobei die Anzahl von Prüfpunkt-Protokollen in jedem Prüfpunkt kleiner als die Anzahl von Datenbank-Teilen ist.
Datenbankverwaltungssystem nach Anspruch 9, ferner enthaltend: einen Wiederherstellungsausführer, der so konfiguriert ist, dass er eine Datenbank zu einem Zeitpunkt eines benannten ersten Prüfpunkts wiederherstellt, wobei der Abfrageausführer so konfiguriert ist, dass er eine Datenbank mindestens an einem Prüfpunkt aus einer Vielzahl von Prüfpunkten sichert, und der Wiederherstellungsausführer so konfiguriert ist, dass er eine einem zweiten Prüfpunkt, welcher der gleiche wie der erste Prüfpunkt oder früher als der erste Prüfpunkt ist, entsprechende Datenbank aus gesicherten Datenbanken lädt; und Folgenummern in einem dem zweiten Prüfpunkt entsprechenden Prüfpunkt-Protokoll auf die den Folgenummern jeweils entsprechenden Folgenummer-Manager setzt.
Datenbankverwaltungssystem nach Anspruch 11, wobei, wenn der zweite Prüfpunkt vom ersten Prüfpunkt verschieden ist, der Wiederherstellungsausführer so konfiguriert ist, dass er für jeden Datenbank-Teil der geladenen Datenbank den Datenbank-Teil unter Verwendung eines oder mehrerer Protokolle zwischen dem zweiten Prüfpunkt und dem ersten Prüfpunkt, welche in dem dem Datenbank-Teil entsprechenden Protokollspeicherbereich gespeichert sind, wiederherstellt, wobei das eine oder die mehreren Protokolle in aufsteigender Reihenfolge der Folgenummern in den Protokollen verwendet werden, bei der Wiederherstellung jedes Datenbank-Teils für ein Protokoll, das eine entsprechende Folgenummer, welche eine dem Datenbank-Teil entsprechende Folgenummer ist, und eine oder mehrere nicht-entsprechende Folgenummern, welche eine oder mehrere andere Folgenummern als die entsprechende Folgenummer sind, enthält, der Wiederherstellungsausführer so konfiguriert ist, dass er eine Aktualisierung gemäß dem Protokoll für den Datenbank-Teil und einen oder mehrere Datenbank-Teile, welche jeweils der einen oder den mehreren nicht-entsprechenden Folgenummern entsprechen, durchführt, und bei der Wiederherstellung jedes Datenbank-Teils, wenn die Folgenummer in dem dem Datenbank-Teil entsprechenden Protokoll nicht eine einer vorher verwendeten Folgenummer im Protokoll nächstfolgende Nummer ist, der Wiederherstellungsausführer so konfiguriert ist, dass er auf ein Protokoll wartet, welches die nächstfolgende Nummer enthält.
Datenbankverwaltungssystem nach Anspruch 2, wobei die Datenbank in einem Hauptspeicher vorhanden ist.
Computersystem zum Verwalten von Datenbanken, enthaltend: eine mit Protokollspeicherbereichen verbundene Schnittstelleneinrichtung; und einen mit der Schnittstelleneinrichtung verbundenen Prozessor, wobei der Prozessor so konfiguriert ist, dass er eine Vielzahl von Transaktionen ausführt, ein Protokoll für jede Transaktion während der Ausführung der Vielzahl von Transaktionen erzeugt und die erzeugten Protokolle in den Protokollspeicherbereichen speichert, und wobei der Prozessor so konfiguriert ist, dass er Folgenummern von Protokollen mindestens in den Protokollen zu einer Gruppe von Transaktionen, deren Ergebnisse je nach einer Transaktionsausführungsreihenfolge unterschiedlich ausfallen, gehörender Transaktionen aufzeichnet.
Datenbankverwaltungsverfahren zum Verwalten von Datenbanken, enthaltend: das Erzeugen eines Protokolls für jede Transaktion während der Ausführung einer Vielzahl von Transaktionen; das Speichern der erzeugten Protokolle in Protokollspeicherbereichen; und das Aufzeichnen von Folgenummern von Protokollen mindestens in den erzeugten Protokollen zu einer Gruppe von Transaktionen, deren Ergebnisse je nach einer Transaktionsausführungsreihenfolge unterschiedlich ausfallen, gehörender Transaktionen.