Transaktionen und Restaurierung
13 Transaktionen und Restaurierung
13.3.2 Die SET LOCKMODE-Anweisung
In diesem Kapitel
werden die drei
verwandten Begriffe
konkurrierender Datenzugriff, Transaktionen und die
Restaurierung von
Datenbanken behandelt. Zuerst werden
INGRES-SQL-Anweisungen, die
in Bezug zu
Transaktionen
stehen, erläutert. Danach werden die Möglichkeiten erörtert,
welche das INGRES-System
bietet, um eine
Datenbank nach
verschiedenen Fehlern zu restaurieren. Am Ende des Kapitels
wird das Sperren der
INGRES-Objekte behandelt, womit
der
konkurrierende Datenzugriff mehrerer Benutzer auf die Daten
einer INGRES-Datenbank gewährleistet
ist.
Eine Datenbank wird in
der Regel von
mehreren Anwendern
gleichzeitig benutzt. Dieser Umstand wirft eine
Reihe von
Problemen auf, die alle mit völliger Korrektheit abgehandelt
werden müssen. Der konkurrierende Datenzugriff mehrerer
Benutzer muß bei jedem
Datenbanksystem gewährleistet sein.
Ein weiteres Problem, mit dem Datenbanksysteme konfrontiert
sind, sind Fehler, die
sowohl in der Software als
auch
in
der Hardware auftreten
können. Ein Datenbanksystem
sollte in der Lage
sein, nach denkbaren
Ausfällen die
betroffenen Datenbanken in den
letzten konsistenten Zustand
zu
überführen. Sowohl der
konkurrierende Datenzugriff
mehrerer Benutzer als auch
die Erhaltung der Konsistenz der
Datenbanken nach Hardware- oder Softwareausfall wird mit
Hilfe der Transaktionen gewährleistet.
Eine Transaktion
kennzeichnet mehrere, nacheinander
folgende, logisch zusammenhängende Anweisungen. An folgendem
Beispiel wird dieser Begriff
praktisch erläutert. In
der
Beispieldatenbank soll der
Mitarbeiter namens Huber eine neue
Personalnummer bekommen. (Der Grund
dafür könnte die Änderung
des
Arbeitsstandortes o.ä.
sein.) Die neue Personalnummer
soll 39831 sein.
Die
Änderung der Personalnummer
muß gleichzeitig in
zwei
Tabellen durchgeführt
werden: Eine Reihe
der Tabelle
mitarbeiter muß
geändert werden sowie
alle Reihen der
Tabelle arbeiten, die Daten des Herrn Huber enthalten. Falls
nur eine der beiden Tabellen geändert
würde (z.B. die Tabelle
mitarbeiter), würde die Beispieldatenbank inkonsistent,
weil
der
Primär- und Fremdschlüssel
des Herrn Huber nicht mehr
zueinander passen würden. Es
wären also alle Abfragen, die
die
Tabellen mitarbeiter und arbeiten
mit dem Join-Operator
verknüpfen und die Datenwerte
des Herrn Huber auswählen,
falsch.
Die
Konsistenz der Beispieldatenbank kann nur erhalten
bleiben, wenn die
UPDATE-Anweisungen entweder vollständig
durchgeführt oder -
im Falle eines
Fehlers während der
Transaktion - rückgängig gemacht
werden.
Beispiel 13.1
Ändern Sie die Personalnummer
des Mitarbeiters namens Huber
in
allen Reihen der
Beispieldatenbank. Die neue Nummer soll
39831 sein.
UPDATE mitarbeiter
SET m_nr = 39831
WHERE m_nr = 10102;
UPDATE
arbeiten
SET m_nr = 39831
WHERE m_nr = 10102;
Das Beispiel stellt damit eine Transaktion
dar, d.h. eine
logische Einheit, deren Eigenschaft es ist, die Konsistenz
einer Datenbank dadurch zu
erhalten, daß entweder alle oder
keine der Anweisungen einer Sequenz
durchgeführt werden.
INGRES kennt drei
SQL-Anweisungen, die im
Zusammenhang mit
den Transaktionen stehen:
- COMMIT,
- ROLLBACK und
- SAVEPOINT.
Mit der
Anweisung
COMMIT [WORK];
wird eine Transaktion beendet, und
alle Änderungen, die
innerhalb der Transaktion
angegeben sind, werden
in der
Log-Datei geschrieben. Gleichzeitig wird mit Beendigung der
einen Transaktion die nächste
gestartet.
Mit der Anweisung
ROLLBACK
[WORK] [TO name];
werden alle schon ausgeführten SQL-Anweisungen innerhalb
einer Transaktion
rückgängig gemacht. Diese
Anweisung
wird
entweder vom System
implizit durchgeführt oder
muß
explizit vom Programmierer im Programm
angegeben werden.
Der Programmierer verwendet
die Anweisung ROLLBACK,
wenn
er
nicht sicher ist, ob alle Änderungen an der Datenbank
korrekt ausgeführt wurden. (Die
optionale Angabe WORK
bei
den Anweisungen COMMIT
und ROLLBACK existiert
aus
Kompatibilitätsgründen zu anderen
Datenbanksystemen.)
Die Anweisung
SAVEPOINT name;
erstellt eine Marke für eine SQL-Anweisung innerhalb einer
Transaktion. Diese Anweisung stellt ein nützliches
Konstrukt
dar, um die Ausführung verschiedener
Teile einer Transaktion,
mit
Hilfe von Bedingungen
zu ermöglichen. Andererseits
widerspricht ihre
Verwendung dem Prinzip,
daß eine
Transaktion so kurz wie möglich sein
soll.
Nachdem die Marken innerhalb
einer Transaktion gesetzt
wurden, ist es mit
ROLLBACK TO name;
möglich,
alle Anweisungen innerhalb der Transaktion und bis
zur Marke name zurückzusetzen. Die
Transaktion bleibt offen
und alle Anweisungen, die sich
in der Transaktion vor der
Marke name befinden, bleiben
unverändert.
INGRES bietet dem Benutzer die Möglichkeit, zwischen
den
impliziten und expliziten Transaktionen zu wählen. Die
Anweisung SET AUTOCOMMIT hat zwei
Schalter - ON und OFF - die
die Transaktionsart festlegen. Falls
SET AUTOCOMMIT ON;
in
einem Programm angegeben ist, werden
alle nachfolgenden
SQL-Anweisungen als
einzelne Transaktionen betrachtet.
Demgegenüber verlangt
der OFF-Schalter die
explizite
Anwendung der Anweisung COMMIT bzw.
ROLLBACK.
INGRES besitzt ein gut abgestimmtes
Konzept zur Restaurierung
von
Datenbanken, mit dem
Fehler verschiedenen Ursprungs
unterschiedlich behoben werden können. Damit dieses Konzept
verständlich wird, müssen zuerst die möglichen Fehlerquellen
sowie die zur Verfügung
stehenden Möglichkeiten zur
Wiederherstellung der Konsistenz
erläutert werden.
Die Inkonsistenz einer Datenbank
kann durch vier
unterschiedliche Fehlergruppen
verursacht werden. Das sind:
- Programmfehler,
- Systemfehler,
- Plattenfehler und
- Kombination
unterschiedlicher Fehler.
Ein Programmfehler betrifft die Anwendung eines einzelnen
Benutzers und hat gewöhnlich
keinen Einfluß auf
das
ganze System.
Programmfehler können im
Regelfall nicht
vom System abgefangen
werden; es ist
vielmehr Aufgabe
des
Programmierers, solche Fehler
selbst abzufangen
und entsprechende
Maßnahmen zu treffen.
Innerhalb
einer Transaktion
auftretende Programmfehler müssen
dementsprechend berücksichtigt
werden.
Für einen Systemfehler ist
typisch, daß die
im
Arbeitsspeicher gespeicherten Daten verlorengehen. Dies
tritt z.B. bei Stromausfall auf. Damit betrifft
ein Systemfehler alle im
Arbeitsspeicher befindlichen
Anwendungen. Die
Konsistenz aller zum
Zeitpunkt des
Systemfehlers im Arbeitsspeicher
befindlichen DB-Anwendungen
wird bei INGRES durch
die Verwendung der
sogenannten
Log-Datei wiederhergestellt. Die
Log-Datei wird später in
diesem Abschnitt behandelt.
Ein Plattenfehler
äußert sich dadurch,
daß die
Information auf
einer Platte oder
auf einem Teil
der
Platte verlorengeht. Die Ursache
eines Plattenfehlers
kann mechanischer (z.B. Schreib/Lesekopf-Fehler) oder
verwaltungstechnischer Art sein.
Bei
einer Kombination unterschiedlicher Fehler kann es
vorkommen, daß sich die
Datenbanken im System
in einem
nicht konsistenten Zustand befinden. In dem Fall muß die
Restaurierung der nicht konsistenten
Datenbanken vorgenommen
werden.
Abhängig davon, welche Art
von Fehler aufgetreten
ist, existieren bei INGRES zwei unterschiedliche
Restaurierungs-Prozesse:
- die automatische
Restaurierung und
- die Restaurierung mit Hilfe der
rollforwarddb-Anweisung
Wenn eine Transaktion
gestartet wird, wird die Information
aus
dieser Transaktion in einer speziellen
Datei namens
Log-Datei gespeichert. Damit enthält
die Log-Datei die
Information über abgeschlossene und nicht abgeschlossene
Transaktionen eines
Systems. Die
Log-Datei wird vom
sogenannten "Recovery Manager"
benutzt, um leichte
Systemfehler automatisch zu beheben. Wenn
z.B. Daten
im
Arbeitsspeicher des Rechners
verlorengehen, wird
die automatische Restaurierung durchgeführt, indem der
"Recovery Manager" alle nichtabgeschlossenen Transaktionen
zurücksetzt.
Der
Speicherungsort einer
Log-Datei wird mit
Hilfe der
Umgebungsvariablen II_LOG_FILE
gesetzt. (II_LOG_FILE ist
in Kapitel 15 beschrieben.) Es
ist empfehlenswert, die
Log-Datei nicht auf einer
Platte mit sehr
intensiven
E/A-Operationen zu speichern, weil
dadurch die Effizienz des
ganzen INGRES-Systems beeinträchtigt
werden kann. Der zweite
wichtige Punkt, der die
Beeinträchtigung der Effizienz des
Systems verursachen kann, ist die Belegung einer Log-Datei.
Standardmäßig gilt: Falls
eine Log-Datei zu 80%
gefüllt
ist, wird die älteste, noch nicht
abgeschlossene Transaktion
zurückgesetzt und der
Benutzer darüber informiert.
Falls eine Log-Datei zu 95% gefüllt ist, werden Aktivitäten
aller Benutzer gestoppt bis
wieder genügend Platz in der
Log-Datei verfügbar ist.
Damit die Log-Datei nicht
zu voll wird
und dadurch
die nicht
abgeschlossenen
Transaktionen verlorengehen,
besitzt INGRES ein
Subsystem namens "Archiver", das
in
bestimmten Zeitabständen, die vom
Prozentsatz der Belegung
der
Log-Datei abhängig sind,
erfolgreich abgeschlossene
Transaktionen in eine Journal-Datei kopiert. Alle
kopierten
Transaktionen werden
anschließend aus der
Log-Datei
entfernt.
Die
Voraussetzung für die
Übertragung der erfolgreich
abgeschlossenen Transaktionen einer Tabelle aus der Log- in
die
Journal-Datei ist entweder die Existenz der Angabe WITH
JOURNALING in der CREATE
TABLE-Anweisung dieser Tabelle oder
die Verwendung der SET JOURNALING-Anweisung innerhalb einer
INGRES-Sitzung.
Die Journal-Datei
stellt eine permanentere Form
der
Datensicherung als die
Log-Datei dar. Sie
wird
dementsprechend für die Behebung schwerer Fehler (wie z.B.
Plattenausfall) verwendet.
Damit die Journal-Datei nach
einem Plattenausfall benutzt werden
kann, ist es dringend zu
empfehlen, sie auf einem anderen
Speichermedium (eine andere
Platte oder ein Magnetbandgerät)
als dem, auf dem sich die
ihr zugehörige Datenbank befindet,
zu speichern.
Ein weiterer Begriff, der
im Zusammenhang mit
der
Journal-Datei steht,
ist die Sicherungskopie einer
Datenbank. INGRES ermöglicht dem
Datenbank-Administrator
(DBA) mit Hilfe eines Dienstprogramms, eine Sicherungskopie
der Datenbank zu erstellen. Die Erstellung der
Sicherungskopie bei INGRES wird
"Checkpoint" genannt.
INGRES unterstützt zwei
Dienstprogramme
- ckpdb
und
- rollforwarddb,
die im Zusammenhang mit
der Restaurierung der
Datenbanken stehen.
Das Dienstprogramm ckpdb erstellt
die
Sicherungskopie einer oder
mehrerer Datenbanken, und
kann nur vom DBA als
Betriebssystem-Kommando
aufgerufen
werden. Nach der Erstellung der Sicherungskopie werden alle
existierenden Einträge in
der Journal-Datei als ungültig
markiert, weil sie nicht
mehr vom System benötigt werden.
Das
zweite Dienstprogramm rollforwarddb wird
für die
Wiederherstellung einer oder
mehrerer Datenbanken verwendet.
Dieses Dienstprogramm
benötigt die Sicherungskopie
der
Datenbank(en) und die
aktuelle Journal-Datei. Um
die Wiederherstellung
der Datenbanken mit
Hilfe der
Sicherungskopie und
der Journal-Datei durchführen zu
können, müssen beide
aktiv ("online") sein.
Die Syntax
der Betriebssystemkommandos rollforwarddb und ckpdb wird
in
Kapitel 15 ausführlich dargestellt.
Ein
Datenbanksystem muß bei
einem Mehrbenutzerbetrieb
Mechanismen enthalten, die allen Benutzern zur selben Zeit
den Zugriff auf Daten einer
Datenbank ermöglichen. Dies wird
mit Hilfe von Sperren erreicht.
Das INGRES-System kennt zwei Arten von Sperren:
SHARED und
EXCLUSIVE.
Wenn ein
Benutzer ein Objekt
im SHARED-Modus sperrt,
dürfen alle anderen Benutzer nur lesend auf dieses
Objekt
zugreifen. Alle Abfragen, die dieses Objekt betreffen, sind
dann erlaubt. Demgegenüber
wird jeder Versuch, das Objekt
zu ändern, abgewiesen bzw. in den
Wartezustand versetzt. Ein
Objekt kann mehrere SHARED-Sperren
haben.
Der EXCLUSIVE-Modus
kennzeichnet eine wesentlich
restriktivere Art
der Sperre. Wenn
ein Benutzer ein
Objekt im EXCLUSIVE-Modus sperrt,
werden alle Versuche
anderer Benutzer, auf dieses Objekt schreibend oder lesend
zuzugreifen, abgewiesen bzw. in den
Wartezustand versetzt.
INGRES kann drei verschiedene
Objekttypen sperren:
- eine physikalische
Seite,
- eine Tabelle und
- eine ganze
Datenbank.
Die physikalische Seite ist
das Objekt, das bei INGRES in
den meisten Fällen gesperrt wird. Die Seitensperre
sperrt
die physikalische Seite, in
der sich die Reihe befindet,
die
gesperrt werden soll. Sie ist gleichzeitig die kleinste
Sperreinheit. (Die Reihensperre
existiert bei INGRES nicht.)
Eine Seitensperre kann vom
System unter Umständen
in
eine Tabellensperre befördert
werden. Dies geschieht, wenn
die Anzahl der Seitensperren einen
im voraus definierten
maximalen Wert überschreitet oder
wenn in der
SET
LOCKMODE-Anweisung die Tabellensperre als Einheit explizit
angegeben ist. (Die SET
LOCKMODE-Anweisung wird später
in
diesem Kapitel beschrieben.)
Eine Tabelle kann auch
implizit vom INGRES-System gesperrt
werden. Dies geschieht z.B. bei der
SQL-Anweisung CREATE
INDEX. Dabei wird die
ganze Tabelle, für die
der Index
erstellt werden soll, im
EXCLUSIVE-Modus gesperrt.
Die
Datenbanksperre sperrt die
ganze Datenbank im
EXCLUSIVE-Modus. Nach
einer solchen Sperre
kann kein
weiterer Benutzer, weder lesend noch schreiben, auf
die
Datenbank zugreifen. Das Dienstprogramm rollforwarddb z.B.
benutzt die Datenbanksperre für jede
Datenbank, die mit
diesem Kommando restauriert wird.
Die Anweisung SET
LOCKMODE ermöglicht es
dem Benutzer,
Einfluß auf das Sperrverhalten des
INGRES-Systems zu nehmen.
Mit dieser Anweisung ist es möglich,
sowohl die Art als auch
die
Obergrenze für die Anzahl der
Sperren festzulegen. Die
Anweisung hat folgende Syntax:
SET LOCKMODE SESSION|ON
tabellen_name|index_name
WHERE
[LEVEL=PAGE|TABLE|SESSION|SYSTEM]
[,READLOCK=NOLOCK|SHARED|EXCLUSIVE|SESSION|SYSTEM]
[,MAXLOCKS =
n|SESSION|SYSTEM]
[,TIMEOUT =
n|SESSION|SYSTEM];
Mit der
SET LOCKMODE-Anweisung kann
zwischen
der standardmäßigen
Sperrart des Systems
und der
voreingestellten Sperrart der
INGRES-Sitzung gewählt werden.
Diese Anweisung bietet zwei
Angaben - SESSION
und ON
tabellen_name -, die
die Auswahl der Sperrobjekte
regeln,
und vier weitere Optionen
- LEVEL,
- READLOCK,
- MAXLOCKS und
- TIMEOUT,
die die Sperreigenschaften insgesamt
festlegen.
Die
Angabe ON tabellen_name
gibt den Namen der Tabelle
an, deren
Eigenschaften durch Optionen
festgelegt
werden. Die alternative Angabe SESSION dagegen definiert
die Sperreigenschaften
aller Objekte während
einer
INGRES-Sitzung (siehe Beispiel 13.2).
index_name ist der Name
des Index, dessen
Eigenschaften
durch Optionen festgelegt werden.
Ein Index kann
vom
INGRES-System nur
bei den Speicherstrukturen BTREE und
CBTREE gesperrt
werden. (Bei der Speicherstrukturen ISAM
und CISAM bleibt der Index
statisch; deshalb sind
keine
Sperren notwendig.) Beim Sperren
eines Index werden immer
zwei seiner Knotenebenen
gesperrt. Um die Teilung
eines
Indexknotens zu
bewerkstelligen, wird vom
System eine
exklusive Sperre gesetzt.
|
Name |
Beschreibung |
|
LEVEL |
Mit der Option LEVEL wird das Objekt
festgelegt, das als
Sperreinheit benutzt wird. |
|
PAGE |
definiert die physikalische Seite und TABLE
die Tabelle als Sperreinheit, während SESSION die augenblicklich geltende
Sperreinheit für die ganze NGRES-Sitzung wählt. |
|
SYSTEM |
definiert den aktuellen Standardwert des
Systems als geltende Sperreinheit. |
|
READLOCK |
Die Option READLOCK spezifiziert den
Sperrmodus, wenn die Daten von einem Benutzer gelesen werden. |
|
NOLOCK |
sperrt keine Daten während des
Lesevorgangs. |
|
SHARED und EXCLUSIVE |
definieren die beiden am Anfang dieses
Abschnitts schon beschriebenen Sperrmodi, während SESSION und SYSTEM den
augenblicklichen Sperrmodus für die INGRES-Sitzung bzw. den generellen Modus
für das ganze System festlegen. |
|
MAXLOCKS |
Mit der Option MAXLOCKS wird die maximale
Anzahl der Seitensperren definiert, deren Überschreitung die Beförderung der
Sperreinheit in die Tabellensperre verursacht. n ist eine Ganzzahl, die die
maximale Anzahl der Seitensperren definiert (standardmäßig ist n=10). |
|
legt die augenblicklich geltende Anzahl der
Seitensperren für die INGRES-Sitzung fest, während SYSTEM die Voreinstellung
für das ganze System definiert. |
|
|
TIMEOUT spezifiziert das Verhalten eines
Programms, von dem aus versucht wird, eine gesperrte Sperreinheit abzufragen
bzw. zu ändern. n ist eine Ganzzahl, die das Zeitlimit in
Sekunden definiert. n=0 ist die Voreinstellung und bedeutet, daß das Programm
ohne zeitliche Begrenzung im Wartezustand bleibt. SESSION legt den
augenblicklich geltenden Wert für die INGRES-Sitzung fest, während SYSTEM die
Voreinstellung für das ganze System definiert. |
Beispiel 13.2
SET LOCKMODE ON arbeiten
WHERE LEVEL= PAGE,
READLOCK=EXCLUSIVE,
MAXLOCKS=20,
TIMEOUT=45;
In
Beispiel 13.2 werden die Sperreigenschaften der Tabelle
arbeiten explizit festgelegt. Die
Seitensperre geht in eine
Tabellensperre über, wenn
die Anzahl der gesperrten Seiten
20
überschreitet. Der Wartezustand
eines Programms, das auf
eine gesperrte Einheit der Tabelle
arbeiten zugreift, beträgt
45
Sekunden und jede zum Lesen gesperrte Seite wird exklusiv
gesperrt.
Beispiel 13.3
SET LOCKMODE SESSION
WHERE LEVEL=SYSTEM, READLOCK=SYSTEM,
MAXLOCKS=SYSTEM,
TIMEOUT=SYSTEM;
Nach
der SET LOCKMODE-Anweisung
in Beispiel 13.3
werden
alle Sperreigenschaften der augenblicklichen INGRES-Sitzung
auf
System-Standardwerte (d.h. LEVEL=PAGE, READLOCK=SHARED,
MAXLOCKS=10
und TIMEOUT=0) gesetzt.