Oracle Redo Logs – Informationen soweit der Logminer reicht
Redo Logs sind eine der elementaren Komponenten einer Oracle Datenbank und wahrscheinlich eine der wichtigsten. Alle Datenänderungen, die im Falle eines Absturzes wiederherstellbar (recoverable) sein sollen, werden hier protokolliert. Gehen die Redo Logs verloren, dann gehen auch Daten verloren und kommen die Redo Logs beim Schreiben nicht hinterher, muss die Datenbank warten, bis es weitergeht. Hier geht es zum einen darum, was bei der Konfiguration von Redo Logs zu beachten ist, aber auch darum, welche interessanten Informationen sich ihnen entlocken lassen.
Oracle Datenbanken werden oftmals dann genutzt, wenn geschäftskritische Anwendungen betrieben werden sollen, die im Fall von OLTP Anwendungen kurze Antwortzeiten liefern und bei OLAP Anwendungen große Analysen ermöglichen. Das ist nur dann möglich, wenn die Daten, auf denen gearbeitet wird, im Speicher gehalten werden können. Auf ihn kann in Nanosekunden zugegrifen werden statt in Millisekunden wie bei klassischen Festplatten oder im Mikrosekundenbereich bei Solid State Disks (je nach Typ).
Dass möglichst viele Daten im Speicher gehalten werden sollen, dürfte klar sein. Man geht bei einer OLTP Anwendung davon aus, dass die Buffer Cache Hit Ratio nicht unter 95% liegen sollte. Das bedeutet, nur 5% der Blöcke sollen von der Platte gelesen werden müssen und sogar das kann zu viel sein. Doch Speicherinhalte haben einen Nachteil: Sie sind flüchtig – im Falle eines Crashes der Instanz oder einem Serverabsturz sind diese Daten verloren. Und wenn eine Eigenschaft für Oracle Datenbanken noch wichtiger sein dürfte als kurze Antwortzeiten, dann die, dass abgeschlossene Transaktionen nicht verloren gehen.
Was also tun? Man protokolliert die Änderungen auf einer Festplatte und schreibt sequentiell. Dadurch vermeidet man das ständige, langsame Neupositionieren der Schreib-/Leseköpfe, speichert diese Änderungen aber trotzdem persistent auf der Platte. Bei Oracle-Datenbanken nennt man Transaktionsprotokolle auch Redo Logs.
Hat man lückenlos alle Redo Log-Dateien zur Verfügung, kann man die Datenbank von der Erstellung auf jeden beliebigen Stand bringen. Ein Verlust der Redo Logs bedeutet so gut wie immer Datenverlust, sobald die Oracle-Instanz crasht. Sollten also im laufenden Betrieb aus irgendeinem Grund Redo Logs verloren gehen, sollte immer sofort eine Vollsicherung erfolgen, notfalls auch offline.
Performance in einer Oracle Datenbank
Trotz des sequentiellen Schreibens sind Festplattenzugriffe relativ langsam und so können die Redo Logs leicht zum Flaschenhals in der Datenbank werden. Ist die Datenbank nicht in der Lage, die Änderungen schnell genug in den Redo Logs zu protokollieren, passiert erst einmal nichts weiter. Sie wartet, bis die Änderungen protokolliert sind. Erst dann ist eine Transaktion abgeschlossen.
© Alkmene Verlags- und Mediengesellschaft mbH
Das bedeutet, man muss sich beim Anlegen der Redo Logs Gedanken machen. Es gibt mindestens zwei Redo Log-Gruppen mit meist mehreren Membern, die zyklisch der Reihe nach beschrieben werden. Ist eine Redo Log-Gruppe voll, wird die nächste beschrieben, dort werden wie in einem Ringpuffer die Daten überschrieben. Um die Daten lückenlos wiederherstellen zu können, müssen alte Redo Logs archiviert werden.
Bei Oracle Datenbanken gibt es dafür den ARCHIVELOG-Modus. Damit wird sichergestellt, dass alte Redo Logs archiviert werden, bevor man beginnt, neue zu schreiben. Diese archivierten Redo Logs sind wichtig, weil man damit bei Datenverlust von der letzten Vollsicherung die Daten bis zum aktuellen Stand vorrollen kann. Aber natürlich kann es auch hier einen Flaschenhals geben: Kommt die Archivierung nicht hinterher, dann muss die Datenbank warten!
© Alkmene Verlags- und Mediengesellschaft mbH
Bei der Planung der Redo Logs spielt auch die Größe eine große Rolle. Oracle führt in mehr oder weniger regelmäßigen Abständen sogenannte Checkpoints durch, bei denen die Änderungen, die erfolgt sind, aus dem Cache in die Datendateien geschrieben werden. Diese Checkpoints finden zum Beispiel statt, nachdem es einen Redo Log-Switch gegeben hat. Finden sie zu häufig statt, dann kann das nächste Redo Log unter Umständen noch nicht überschrieben werden, weil noch Daten auf die Platte geschrieben werden müssen, die in diesem Log stehen.
Finden Checkpoints zu selten statt, dauert das herunterschreiben dieser Daten länger und im Falle eines Instance Crashes dauert es natürlich länger, bis die Daten recovert wurden und die Datenbank wieder zur Verfügung steht. Diese Abwägung ist so wichtig, dass es in der Datenbank eine Sicht gibt, über die man sich eine Empfehlung für die Mindestgröße für die Redo Logs anzeigen lassen kann: Ihr name ist V$INSTANCE_RECOVERY.
Allerdings sollte man dann auch bedenken, eine vernünftige Zielvorgabe für eine Recovery Zeit zu setzen. Hierzu kann der Parameter FAST_START_MTTR_TARGET verwendet werden.
Es gibt also einige Dinge, die beim Konfigurieren der Redo Logs beachtet werden müssen, damit die Datenbank durch diesen absolut notwendigen Persistenz-Mechanismus nicht ausgebremst wird.
Informationen aus den Redo Logs
Bis jetzt hat es sich so angehört, als seien die Redo Logs ein lästiges, aber notwendiges Übel in der Datenbank. Doch sie sind wesentlich mehr als das. Wie schon erwähnt, kann man, wenn man die Redo Logs lückenlos zur Verfügung hat, die Datenbank auf jeden beliebigen Stand bringen. Man nennt das auch vorwärts rollen (roll forward). Genau diese Möglichkeit wird bei einem Recovery ja benötigt. Jede Änderung, die irgendwann durchgeführt wurde, ist also in den Redo Logs verzeichnet. Dazu ist aber auch notiert, zu welcher Transaktion sie gehört, inklusive der System Change Number, einer eindeutigen fortlaufenden Nummer, von der jeder Transaktion genau eine zugeordnet ist. Darüber hinaus ist verzeichnet, wer diese Änderung durchgeführt hat, wann sie passiert ist und sogar wie man sie rückgängig machen kann. Wurde ein Datensatz gelöscht, sieht man hier die entsprechenden Daten, die vorher vorhanden waren. Wurde ein Datensatz aktualisiert, dann tauchen hier die Werte auf, die er vorher hatte. Das macht die Redo Logs für viele Anwendungen zu Goldgruben an Informationen.
Nachvollziehbarkeit und Auditing
Oft gibt es rechtliche Gründe oder betriebliche Vorgaben, die es nötig machen, Änderungen zu protokollieren. Dafür gibt es Auditing-Mechanismen, die Oracle anbietet. Doch auch die Redo Logs sind in der Lage, die nötigen Informationen zu liefern. Sie enthalten die Informationen, wer wann was geändert hat und sogar, wie die Werte vor der Änderung waren (before image).
Das hört sich sehr gut an. Allerdings hat die Sache einen kleinen Haken: Man kann nur Änderungen sehen, die in den Redo Logs protokolliert sind. Theoretisch sollten das natürlich alle Änderungen sein, die an Nutzdaten anfallen sollen. Oracle bietet aber die Möglichkeit, Direct Loads durchzuführen. Das sind INSERT Statements mit einem Append Hint, der dafür sorgt, dass diese INSERTs nicht in den Redo Logs auftauchen. Gedacht ist das, um schnell Staging Tabellen befüllen zu können, aber diese Änderungen sind nicht recoverbar. Will man diese Möglichkeit unterbinden, dann gibt es die Möglichkeit, für die Datenbank oder einzelne Tablespaces die FORCE_LOGGING Option zu aktivieren und damit werden dann auch diese Operationen protokolliert und nachvollziehbar.
Über den Logminer (Datenbank Package DBMS_Logminer) können die Informationen aus den Redo Logs für Menschen lesbar gemacht und ausgegeben werden. Allerdings ist die Ausgabe immer noch recht kryptisch, deshalb empfiehlt es sich hier, mit Tools zu arbeiten, die die Daten zum Beispiel nach Excel ausgeben können. Toad for Oracle hat zum Beispiel einen Logminer-Assistenten, der die Einträge anzeigt und exportieren kann.
Replikation
Da die Redo Logs alle nötigen Daten enthalten, sind sie auch für die Replikation interessant. So ist es damit möglich, alle Änderungen auf andere Systeme zu transportieren und dort Replikate zu pflegen, ohne viel Last in der Datenbank zu machen. Dabei gibt es physische Replikationslösungen wie den Oracle Dataguard, der binär gleiche Replikate verwaltet, die im Falle eines Ausfalles übernehmen können. Der Nachteil hier ist, dass an der Zieldatenbank nichts geändert werden darf, sie muss ja binär identisch bleiben.
Etwas komplizierter sind logische Replikationslösungen wie Shareplex, Oracle GoldenGate, Oracles Logical Standby Datenbank oder DBVisit Replicate, die aus den Redo Logs tatsächlich SQL Statements erzeugen und so auf der Zielseite auch in binär unterschiedliche Datenbanken schreiben können. Dort kann auf beide Datenbanken lesend und schreibend zugegriffen werden, sie können andere Versionen und Architekturen haben und zum Beispiel zusätzliche Indizes für große Abfragen enthalten. Zusätzlich sind hier interessante Szenarien wie Migrationen fast ohne Auszeit oder entfernte Multi Master-Datenbanken möglich.
