11.1. Hot Backup Technik

Betrachten wir z.B. MS SQL 2003, so , unterstützt diese hot backups. Der Datenbankandministrator hat den Eindruck, daß die Datenbank ohne Einschränkungen weiter arbeitet. Dem ist nicht so. Intern wird die die Datenbank entweder ganz oder teilweise für Schreibzugriffe gesperrt. Damit die Datenbank trotzdem noch weiter funktionieren kann, werden sämtliche Transaktionen, also inserts und updates solange in sog. transaktions logs und redo logs (Oracle) , bzw. physical logs, logical logs (Informix) genannt, gespeichert, wo sie, zumeist in einem in Klartext lesbarem Format, abgelegt sind. Sobald eine Datenbank - Query durchgeführt wird, so wird die reguläre, gesperrte Datenbank durchsucht, aber auch anschließend die Logs, bevor das Ergebnis ausgegeben wird. Je länger ein Backup dauert, umso langsamer wird dann der Datenbankserver, insbesondere, wenn in die Datenbank sehr viel geschrieben wird. Damit der Effekt nicht so extrem ist, wird die Datenbank in sog. pages logisch aufgeteilt. Das Backup - Programm erlaubt dann dem Datenbankserver teilweise wieder das Schreiben in die Datenbank, und zwar überall, nur nicht in die page (MS SQL), oder den split block (Oracle), die gerade gesichert wird (page lock). Es versteht sich von selber, das die Datenbank in sich selber inkonsistent wird. Daher ist es extrem wichtig, bei Beendigung des Backups, alle Änderungen, die in transaktions logs und redo logs aufgelaufen sind, in die Datenbank einzuarbeiten, was bei sehr vielen Schreibzugriffen dazu führen kann, daß dies auch nach Abschluß des Backups sehr lange dauert.

Lang laufende Transaktionen, z.B. für die Erstellung von Statistiken, Optimierungen, Analysen sind das Ende jedes hot backup, weil dieses gewöhnlich nur nach dem checkpointing (Oracle, PostgresSQL, Informix, z.B.) erfolgen kann, also dann, wenn die Datenbank für einen Moment in sich konsistent ist, keine Transaktion mehr läuft. Wenn mehrere lang laufende Transaktionen sich verschachteln, gibt es einen solchen konsistenten Zustand nicht. Das bedeutet, daß man zwar ein hot backup durchführen kann, jedoch nach einem Crash, wenn die transaktions logs in die Datenbank eingearbeitet werden, alle Datensätze verloren sind, bis zu dem Punkt, wo die Datenbank in sich einmal (zufällig) konsistent gewesen ist. Microsoft empfielt daher, Transaktionen möglichst kurz zu halten, sodaß bei vielen ausgeführten Transaktionen es immer "Lücken" dazwischen gibt, in denen ein konsistenter Zustand erreicht wird, ab welchem dann die Daten so gesichert werden können, sodaß es beim Wiederherstellen keine Probleme gibt.

Informix, z.B. vermerkt in den physical logs den Zustand des Datensatzes vor der Änderung, und in den logical logs werden die Datensätze nach der Änderung gespeichert, mit Ausnahme bei update, z.B., wo der Datensatz vor und nach seiner Änderung gespeichert abgelegt wird. Somit ist sowohl rollback, als auch rollforward von Transkationen oder Teilen davon möglich. Eine wenig beachtete Eigenschaft von SQL - Datenbanken ist, daß nicht alle versprochenen Features mit allen möglichen Typen von Indizes verfügbar sind.

PostgreSQL z.B. unterstützt write ahead logging (WAL), was den redo logs, transaction logs entspricht, jedoch nur in Verbindung mit b-tree Indizes, nicht jedoch mit HASH, R-Tree, GiST, FULLTEXT, ... PostgreSQL benötigt WAL nur im Falle eines Crashes. Stattdessen unterstützt PostgreSQL multi versioning concurrency control (MVCC), auch bekannt als snapshot isolation. Jede Query wird, ohne daß Datensätze gelockt werden müssen auf einem Schnappschuß der kompletten Datenbank ausgeführt. Auch Inserts, Updates werden zunächst isoliert ausgeführt. Hinterher wird geschaut, ob eine Query evtl. mit einem insert oder update kollidiert ist. In diesem Falle wird die Transaktion rückgängig gemacht. Ein hot backup unter PostgreSQL läuft immer auf einem in sich konsistenten Schnappschuß der kompletten Datenbank ab. Der Administrator kann also mit einer Transaktion, wo die komplette Datenbank gesichert wird, im laufenden Betrieb gefahrlos sein hot backup durchführen. Auch lang andauernde Transaktionen und ein hot backup sind kein Problem, weil MVCC dafür sorgt, daß sich der Datenbankserver immer in einem konsistenten Zustand befindet, und man kann mit Hilfe der WALs genau festlegen, welche Zustand der Datenbank zu welchem Zeitpunkt wieder hergestellt werden soll. Dies ist kein Problem für PostgreSQL, da ja ein Snapshot immer die Daten zeigt, die Der Grund dafür liegt auch in dem OO - Kern von PostgreSQL. Mehr hierzu siehe Abschnitt 11.18.

MySQL beherrscht ebenfalls MVCC, man kann also hot backups einfach während des Betriebes machen. Die von InnoDB zusätzlich kostenpflichtig zu erwerbenden Werkzeuge, mit denen man über ein externes Programm hot backups durchführen kann, wird nicht wirklich benötigt. Jedoch kann MVCC nicht genutzt werden, wenn MySQL im Cluster, also im Master - Slave Modus arbeitet, ebenso entfallen dann Transaktionen und Foreign Keys

Datenbanken, wie Firebird, Informix, LogicSQL beherrschen ebenfalls MVCC und man kann Datenbanken stets im laufenden Betrieb sichern. Oracle beherrscht MVRC (Multi Versioning Read Concurrency) beherrscht. Unter Oracle kann nur eine Transaktion schreiben, und viele lesend zugreifen, ohne sich zu behindern, bei MVCC können mehrere Transaktionen gleichzeitig schreibend und lesend zugreifen. Mehr zu hot backups unter Oracle, siehe Oracle hot backup

Objektorientierte Datenbanken arbeiten völlig anders. Hier existieren von jedem einzelnen Datensatz immer mehrere Versionen, daher ist jede OO - Datenbank immer hot backup - fähig. Im Gegensatz zu MVCC, wo das versioning sich stets auf Gruppen von Datensätzen bezieht, nämlich diejenigen, die innerhalb einer Transaktion betroffen sind, so können OO - Datenbanken zu jedem Datensatz attribute anfügen, der genau Auskunft darüber gibt, wann wo und von wem welcher Datensatz geändert wurde - eine völlig andere Technik, siehe Abschnitt 11.30. Diese Technik wird inzwischen auch in Filesysteme eingeführt, siehe Abschnitt 7.23.