Databases Reference
In-Depth Information
Cache mit
update
geändert haben, auch auf der Festplatte geändert, andere aber
nicht.
Noch schlimmer wird es, wenn
Seiten mit Metadaten aus dem Systemkatalog (siehe Abschnitt 2.7) verändert,
aber nicht auf die Platte zurückgeschrieben wurden und
Seiten mit Datensätzen auf die Platte zurückgeschrieben wurden, zu denen
diese Metadaten gehören.
In diesem Fall passen die Datensätze nicht mehr zu ihren Metadaten. Wir bezeich-
nen Konsistenzverletzungen, die sich aus Betriebsstörungen des RDBMS ergeben,
auch als physikalische Inkonsistenzen. Wir unterscheiden sie damit von logischen In-
konsistenzen, die durch ein mangelhaftes Design der Datenbank entstehen.
Das Problem physikalischer Inkonsistenzen können wir lösen, indem wir - wie
in Abschnitt 17.4 beschrieben - die letzte Sicherung der Datenbank einspielen
und dann die Transaktionsprotokolle nachziehen. Doch kann dieser Vorgang - je
nach Sicherungsmedium und Größe der Transaktionsprotokolle - mehrere Stun-
den oder Tage dauern.
Um diese inakzeptablen Wartezeiten zu vermeiden, führt das RDBMS gelegent-
lich einen so genannten
Checkpoint
durch: Alle veränderten Seiten aus dem Ca-
che werden zurück auf die Platte geschrieben und verändern dadurch ihren Status
von dirty zu clean. Bei großen Caches kann dieser Hausputz einige Zeit dauern,
doch steht als Belohnung immerhin ein physikalisch konsistenter Datenbestand
in Aussicht. In Abbildung 20.3 sind die Seiten markiert, die den Status „dirty“
haben. Genau diese Seiten werden beim Checkpoint auf die Platte geschrieben.
Checkpoint
x
X
x
x
Protokollierung
Abbildung 20.3:
Verfahren, um physikalische Konsistenz sicherzustellen
