Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Ein Oracle-Redo-Log zeichnet jede Änderung an Ihrer Datenbank auf. Wenn ein Nutzer einen INSERT-, UPDATE– oder DELETE-Befehl ausführt, schreibt Oracle diese Änderung nicht direkt auf die Festplatte. Zuerst wird sie protokolliert und anschließend in die Redo-Log-Dateien geschrieben.
Wenn die Instanz abstürzt, spielt Oracle diese protokollierten Änderungen beim nächsten Start ab und stellt alle abgeschlossenen Transaktionen wieder her. Dies bildet die Grundlage der Dauerhaftigkeit gemäß dem ACID-Prinzip.
Oracle verwaltet zwei Arten von Redo-Logs:
Bevor wir tiefer einsteigen, hier vier Begriffe, die im gesamten Leitfaden vorkommen:
Eine Redo-Log-Datei ist eine vorreservierte Datei fester Größe auf einem Speichermedium. Im Gegensatz zu Datendateien werden Redo-Logs zyklisch verwendet. Wenn die letzte Gruppe voll ist, springt Oracle zurück zur ersten Gruppe und überschreibt diese – allerdings erst, nachdem die Gruppe archiviert und ihre Änderungen per Checkpoint in die Datendateien geschrieben wurden.
Oracle gliedert Redo-Log-Dateien in eine zweistufige Struktur: Gruppen und Mitglieder. Eine Gruppe ist eine logische Einheit aus einem oder mehreren identischen Mitgliedsdateien. Der Log-Writer-Prozess (LGWR) schreibt identische Redo-Einträge gleichzeitig in jedes Mitglied der aktuellen Gruppe.
Multiplexing bedeutet, mehrere Mitglieder derselben Gruppe auf unterschiedlichen physischen Festplatten abzulegen. Fällt eine Festplatte aus und beschädigt ein Mitgliedsfile, läuft die Datenbank weiter, solange mindestens ein Mitglied der Gruppe lesbar bleibt. Ohne Multiplexing kann der Verlust einer einzigen Redo-Log-Datei zum Ausfall der gesamten Datenbank führen.
Bei einer Abfrage von V$LOG wird jeder Gruppe einer von vier Statuswerten zugewiesen:
| Status | Bedeutung |
|---|---|
| CURRENT | Die Gruppe, in die der LGWR gerade schreibt |
| ACTIVE | Ein Log-Switch hat stattgefunden, aber die Änderungen wurden noch nicht vollständig per Checkpoint in die Datendateien geschrieben. Für die Instanzwiederherstellung weiterhin erforderlich |
| INACTIVE | Alle Änderungen wurden per Checkpoint übernommen. Diese Gruppe kann wiederverwendet werden |
| UNUSED | Die Gruppe wurde neu hinzugefügt und wurde noch nie beschrieben |
Mit folgender Abfrage lassen sich Gruppen, Mitglieder, Größen und aktueller Status einsehen:
SELECT
a.GROUP#,
a.STATUS,
b.MEMBER,
a.BYTES/1024/1024 AS SIZE_MB
FROM V$LOG a
JOIN V$LOGFILE b ON a.GROUP# = b.GROUP#
ORDER BY a.GROUP#;
Neue Gruppe hinzufügen (zwei Mitglieder auf separaten Festplatten für Multiplexing):
ALTER DATABASE ADD LOGFILE GROUP 4
('/u01/app/oracle/oradata/REDO/log4a.rdo',
'/u02/app/oracle/oradata/REDO/log4b.rdo') SIZE 512M;
Mitglied zu bestehender Gruppe hinzufügen:
ALTER DATABASE ADD LOGFILE MEMBER
'/u02/app/oracle/oradata/REDO/log1b.rdo' TO GROUP 1;
Gruppe entfernen:
ALTER DATABASE DROP LOGFILE GROUP 4;CURRENT oder ACTIVE. Um die aktuelle Gruppe zu löschen, führen Sie zuerst ALTER SYSTEM SWITCH LOGFILE aus, warten bis der Status auf INACTIVE wechselt und entfernen Sie sie anschließend.Bei der Wahl des Speicherorts für Redo-Log-Dateien stehen zwei Prioritäten im Vordergrund: Leistung und Redundanz.
Bei Verwendung von Oracle Managed Files (OMF) übernimmt Oracle Namensvergabe und Ablage automatisch anhand der Parameter DB_CREATE_ONLINE_LOG_DEST_n. Unabhängig von der Ablagemethode gilt eine feste Regel: Legen Sie niemals Mitglieder derselben Gruppe auf derselben physischen Festplatte ab. Befinden sich beide Mitglieder auf einem ausfallenden Volume, bietet Multiplexing keinen Schutz. Verteilen Sie Mitglieder stets auf unterschiedliche Mount-Punkte, Speichercontroller oder ASM-Diskgruppen.
Fragen Sie V$LOGFILE ab, um den Speicherort jedes Mitglieds zu sehen und festzustellen, ob es sich auf einem regulären Dateisystem oder in ASM befindet:
SELECT
GROUP#,
TYPE,
MEMBER
FROM V$LOGFILE
ORDER BY GROUP#;
Dieses Verfahren wird verwendet, um Logs auf schnelleren Speicher zu migrieren oder Ablagefehler zu korrigieren. Die unten beschriebene Umbenennungsmethode funktioniert mit allen Oracle-Versionen.
1. Fahren Sie die Datenbank ordnungsgemäß herunter, damit alle Redo-Daten auf die Festplatte geschrieben werden:
SHUTDOWN IMMEDIATE;2. Kopieren Sie die Dateien auf Betriebssystemebene mit cp (Linux) oder copy (Windows) an den neuen Pfad. Oracle übernimmt keine Dateiverschiebung – dieser Schritt muss manuell ausgeführt werden.
3. Binden Sie die Datenbank ein:
STARTUP MOUNT;4. Aktualisieren Sie die Pfade in der Kontrolldatei:
ALTER DATABASE RENAME FILE '/alter_disk/log1a.rdo' TO '/neuer_disk/log1a.rdo';
ALTER DATABASE RENAME FILE '/alter_disk/log1b.rdo' TO '/neuer_disk/log1b.rdo';5. Prüfen Sie vor dem Öffnen, ob alle Pfade aktualisiert wurden:
SELECT GROUP#, TYPE, MEMBER FROM V$LOGFILE ORDER BY GROUP#;6. Öffnen Sie die Datenbank:
ALTER DATABASE OPEN;Log-Größe und Switch-Häufigkeit hängen direkt zusammen. Die Größe der Redo-Logs bestimmt, wie viele Änderungsdaten Oracle speichern kann, bevor es zur nächsten Gruppe wechseln muss. Jeder Switch löst einen Checkpoint aus, wodurch der Database-Writer-Prozess (DBWn) geänderte Daten aus dem Arbeitsspeicher auf die Festplatte schreibt.
Sind die Logs zu klein, finden Switches zu häufig statt. Ständige Checkpoints erzeugen einen E/A-Flaschenhals und machen sich typischerweise über das Warteereignis „log file switch (checkpoint incomplete)“ bemerkbar.
Zielwert ist ein Switch alle 15 bis 30 Minuten während der Lastspitzen. Häufigere Switches deuten eindeutig auf zu kleine Log-Dateien hin.
Fragen Sie V$LOG_HISTORY ab, um die Anzahl der stündlichen Switches der letzten sieben Tage einzusehen:
SELECT
TRUNC(FIRST_TIME, 'HH') AS HOUR,
COUNT(*) AS SWITCHES
FROM V$LOG_HISTORY
WHERE FIRST_TIME > SYSDATE - 7
GROUP BY TRUNC(FIRST_TIME, 'HH')
ORDER BY 1;
Achten Sie auf Stunden mit hoher Switch-Anzahl. Diese stellen Ihre Lastspitzen dar und dienen als Referenz für die Größenanpassung.
Nutzen Sie diese Formel als Ausgangswert:
Maximale Redo-Rate (MB/Min) × 30 Min = Ideale Log-Größe
Für übliche OLTP-Auslastungen sind 500 MB bis 1 GB ein sinnvoller Ausgangswert. Bei Datenbanken mit umfangreichen Batch-Jobs oder Tagesabschlussverfahren richten Sie die Größe an der Spitzenlast aus – nicht am täglichen Durchschnitt. Eine Auslegung nach dem Durchschnitt führt genau dann zu Auslastungsstörungen, wenn maximale Leistung erforderlich ist.
Praktisches Beispiel: Eine Datenbank mit 200 MB großen Logs erfuhr während eines nächtlichen Batch-Ladevorgangs 456 Switches pro Stunde. Nach Erhöhung der Log-Größe auf 22 GB verschwand das Warteereignis „log file switch (checkpoint incomplete)“ vollständig aus den häufigsten Wartevorgängen im AWR-Bericht, zudem verkürzte sich das Batch-Fenster um 40 %.
Die Größe bestehender Log-Dateien kann nicht direkt verändert werden. Vorgehensweise: Neue größere Gruppen hinzufügen, durch die Gruppen zyklisch wechseln und anschließend alte Gruppen entfernen.
1. Neue Gruppen mit gewünschter Zielgröße hinzufügen:
ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/redo04.log') SIZE 2G;
ALTER DATABASE ADD LOGFILE GROUP 5 ('/u01/app/oracle/oradata/redo05.log') SIZE 2G;
ALTER DATABASE ADD LOGFILE GROUP 6 ('/u01/app/oracle/oradata/redo06.log') SIZE 2G;2. Erzwingen eines Log-Switch, damit Oracle zu den neuen Gruppen wechselt:
ALTER SYSTEM SWITCH LOGFILE;3. Sobald alte Gruppen den Status INACTIVE erhalten, entfernen Sie diese:
ALTER DATABASE DROP LOGFILE GROUP 1;4. Wiederholen Sie Schritt 3 für alle übrigen alten Gruppen.
ALTER SYSTEM SWITCH LOGFILE mehrmals ausführen, um alle alten Gruppen zu durchlaufen. Überprüfen Sie stets in V$LOG, ob eine Gruppe den Status INACTIVE hat, bevor Sie sie entfernen.Jede Oracle-Datenbank läuft in einem von zwei Modi: NOARCHIVELOG oder ARCHIVELOG.
Im NOARCHIVELOG-Modus werden gefüllte Redo-Logs einfach überschrieben. Eine Wiederherstellung ist nur bis zum letzten vollständigen Backup möglich – alle nachfolgenden Änderungen gehen verloren.
Im ARCHIVELOG-Modus speichert Oracle eine dauerhafte Kopie jedes Redo-Logs, bevor dieser wiederverwendet wird. Dadurch lassen sich alte Backups wiederherstellen und die archivierten Logs abspielen, um bis zum Zeitpunkt des Ausfalls wiederherzustellen. Für jede Produktionsdatenbank ist der ARCHIVELOG-Modus zwingend erforderlich.
Wenn eine Instanz abstürzt und neu gestartet wird, führt Oracle automatisch einen zweistufigen Wiederherstellungsvorgang aus:
Ein manueller Eingriff ist nicht erforderlich. Dieser Vorgang wird abgeschlossen, bevor die Datenbank geöffnet wird.
Prüfen Sie den aktuellen Archivierungsstatus:
ARCHIVE LOG LIST;
Wird „No Archive Mode“ angezeigt, gehen Sie wie folgt vor, um den Modus zu aktivieren:
1. Datenbank herunterfahren:
SHUTDOWN IMMEDIATE;2. Datenbank einbinden:
STARTUP MOUNT;3. ARCHIVELOG-Modus aktivieren:
ALTER DATABASE ARCHIVELOG;4. Datenbank öffnen:
ALTER DATABASE OPEN;| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Switches alle 1–2 Minuten | Log-Dateien zu klein | Log-Größe per Hinzufügen und Entfernen von Gruppen erhöhen |
| Warteereignis log file sync | E/A-Flaschenhals auf dem Log-Speicher | Logs auf schnelleren Speicher (SSD oder NVMe) verschieben |
| log file switch (checkpoint incomplete) | Nicht genügend Log-Gruppen vorhanden | Weitere Gruppen hinzufügen, damit der DBWn genug Zeit für Checkpoints hat |
| Archivziel voll; Datenbank blockiert | Archivspeicher nicht überwacht | Speicher erweitern, Archive umlagern oder per RMAN bereinigen |
Redo-Logs bilden die erste Schutzebene von Oracle. Sie übernehmen automatisch die Instanzwiederherstellung und stellen sicher, dass keine abgeschlossene Transaktion bei einem unerwarteten Instanzausfall verloren geht.
Doch Redo-Logs haben Grenzen. Sie können keine Wiederherstellung nach versehentlichem Datenlöschen, dauerhaftem Festplattenausfall oder Beschädigungen durchführen, die bereits per Checkpoint in die Datendateien geschrieben wurden. Zudem bieten sie keine zentrale Verwaltung von Backup-Richtlinien für mehrere Datenbanken.
Für diese Szenarien benötigen Sie eine dedizierte Backup-Lösung. i2Backup ist eine Unternehmens-Backup-Plattform, die die Lücken der Redo-Logs schließt.
Ein vollständiger Datenschutz-Stack
Für Oracle-Umgebungen, die zusätzlich Hochverfügbarkeit oder Echtzeit-Replikation erfordern, bietet Info2soft zwei ergänzende Produkte an:
Gemeinsam mit i2Backup decken diese Tools alle Anforderungen an den Datenschutz ab – von der instanzbezogenen Absturzwiederherstellung bis zur plattformübergreifenden Katastrophenwiederherstellung.
Klicken Sie auf den Button, um eine kostenlose Testversion der Katastrophenwiederherstellungslösungen von Info2soft zu erhalten.
Oracle-Redo-Logs sind die Grundlage der dauerhaften Datenspeicherung in Datenbanken. Sie protokollieren jede abgeschlossene Änderung, ermöglichen automatische Absturzwiederherstellungen und sorgen bei korrekter Größenanpassung und Konfiguration für einen störungsfreien Datenbankbetrieb ohne Leistungsengpässe.
Die zentralen Erkenntnisse dieses Leitfadens:
Trotzdem sind Redo-Logs keine vollständige Backup-Strategie. Sie schützen vor Instanzabstürzen, nicht vor versehentlichem Datenverlust, Hardwareausfällen oder der zentralen Verwaltung von Wiederherstellungen für mehrere Datenbanken. Hier schließt eine dedizierte Lösung wie i2Backup von Info2soft die Lücke – mit kontinuierlichen Oracle-Sicherungen, Point-in-Time-Wiederherstellung und zentraler Verwaltung Ihrer gesamten Umgebung.
