Logo Oracle Deutschland   DBA Community  -  Februar 2014
Block Korruption: Erkennen, Vorbeugen und (automatisch) Reparieren
von Sebastian Solbach ORACLE Deutschland B.V. & Co.KG

Eine Datenbank hat eigentlich nur eine wichtige Aufgabe: Die ihr anvertrauten Daten zu speichern und bei Bedarf auch richtig wiederzugeben. Dabei ist es egal, ob es sich nur um eine kleine Datenbank auf Platte handelt, oder auf Technologien beruht diese Daten InMemory zur Verfügung zu stellen. Leider gibt es aber - egal welche Speichertechnologie verwendet wird - immer wieder Ereignisse, die Daten bei der Speicherung korrumpieren. Daher ist es eine zentrale Anforderung diese sogenannte Block Korruption zu erkennen, zu vermeiden und ggf. sogar direkt automatisch zu beheben. Oft zeigen sich die Probleme allerdings erst dann, wenn man versucht wieder auf die Daten zuzugreifen. Dann kann es häufig schon zu spät sein, insbesondere, wenn die fehlerhaften Blöcke auch im Backup enthalten sind.

Genau hier zeichnet sich die Oracle Datenbank mit Ihren Technologien aus, die nicht nur gleich beim Backup mit RMAN eine Überprüfung der Blöcke vornehmen, sondern auch erweiterte Funktionen zur Prävention bieten. Hierzu gehört auch eine Active Standby Umgebung mit der es sogar möglich diese Fehler direkt und automatisch zu korrigieren.

Ein weiterer wichtiger Punkt ist das Verhalten der Datenbank, wenn eine Block Korruption erkannt wurde, insbesondere in Zeiten von Konsolidierung und Multitenant.

Erkennen, Vorbeugen und automatisch Reparieren

Zur besseren Übersicht ist der Tipp in folgende Abschnitte unterteilt:

Arten von Block Korruptionen

Block Korruptionen können von unterschiedlichen Hardware- und Software-Ebenen herrühren: Von einer defekten Festplatte und defekten Controllern über fehlerhaftes Memory bis hin zu Fehlern im Betriebssystem, Treibern und der Datenbank Software. Ebenfalls häufig treten aber auch Probleme aufgrund menschlichen Versagens auf: wie z.B. das vorschnelle Löschen von allen *.log Dateien (redo01.log!), einer verwechselten Pfadangabe beim Kopieren von Dateien oder ein fälschlich ausgeführter Befehl ('dd'). Manchmal passiert es auch, dass Datenblöcke beim Schreiben verloren gehen (Lost Write) bzw. nicht an den vorgesehenen Platz geschrieben werden (z.B. in den Temp Tablespace anstelle der Datendatei) - in diesem Falle spricht man von einem Stray Write.

Oracle unterscheidet dabei zwischen sogenannten physischer und logischer Block Korruption:

  • Physische Block Korruption ist für die Datenbank leichter zu erkennen, da der gelesene Block den Spezifikationen eines Oracle Blocks überhaupt nicht mehr entspricht oder die Checksumme des Blocks invalide ist.
  • Logische Block Korruption hingegen ist für den einfachen Block Check der Datenbank in Ordnung, allerdings enthalten diese nur teilweise sinnvolle Inhalte. Logische Korruption kann auf den Block beschränkt sein (Intra-Block) oder Blockübergreifend (Inter-Object).

Erkennung

Unterschiedliche Oracle Utilities und eingebaute Technologien führen eine Überprüfung der Datenblöcke durch.

Funktion Aufruf Erkennung Anmerkung
Physisch Logisch Intra- Inter-
dbverify dbv Ja Ja Ja Ja dbv funktioniert auch mit ASM Dateien
analyze ANALYZE ... VALIDATE STRUCTURE Ja Ja Ja Ja Nur bei laufender Datenbank
RMAN RMAN BACKUP, RESTORE, RECOVER Option: "CHECK LOGICAL" Ja - -
(Active) Data Guard Laufzeit Automatisch DB_BLOCK_CHECKING Ja - Erkennt mit DB_LOST_WRITE_PROTECT auch Lost und Strayed Writes. Automatische Fehlerbehebung
Datenbank Laufzeit DB_BLOCK_CHECKSUM DB_BLOCK_CHECKING Ja - -
ASM Laufzeit Automatisch - - - Automatische Reparatur erfordert mindestens Normal Redundancy
Exadata Laufzeit HARD HARD Ja Ja HARD (Hardware Assisted Resilient Data) verhindert Block Korruption
Siehe hierzu auch MOS Note: 1302539.1 "Best Practices for Corruption Detection, Prevention, and Automatic Repair - in a Data Guard Configuration".

Jeder Prozess der Datenbank, egal ob ANALYZE, RMAN oder auch nur eine simples Select, das auf einen korrupten Block stößt, trägt diesen in die View V$DATABASE_BLOCK_CORRUPTION ein.

SQL> select * from v$database_block_corruption;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
         4        100          1              16340 CHECKSUM

Vorbeugung

Wenn es die Performance zulässt, sollten generell innerhalb der Datenbank folgende Datenbank Parameter gesetzt sein:

DB_BLOCK_CHECKSUM=FULL
DB_BLOCK_CHECKING=FULL oder MEDIUM

Bei Data Guard Umgebungen
DB_LOST_WRITE_PROTECT=TYPICAL
Diese Parameter gewährleisten, dass die Datenbank während der Laufzeit schnell Korruptionen feststellen kann und verhindert somit auch, dass diese (insbesondere logische Korruptionen) später auch im Backup enthalten sind. Es sollte nicht verschwiegen werden, dass es dadurch zu Performanceeinbußen kommt. Allerdings wurde mit Oracle 11g gerade in diesem Bereich einiges verbessert, weshalb auch bei vorhergehender schlechter Erfahrung mit dem aktuellen 11gR2 Release nochmals ein Test gemacht werden sollte.

DB_BLOCK_CHECKSUM
Hierbei wird im Header jedes Blockes beim Schreiben eine Checksumme erzeugt, mit der der Block physisch validiert werden kann. Entgegen häufiger Annahmen, kann die Checksumme nicht verwendet werden um logische Korruptionen festzustellen. Werte sind OFF / TYPICAL und FULL. Während bei FULL sowohl für Datendateien als auch für Redolog Dateien Checksummen gebildet werden, findet bei TYPICAL diese nur für Datendateien statt und bei OFF trotzdem immer noch für den SYSTEM Tablespace.

DB_BLOCK_CHECKING
DB_BLOCK_CHECKING führt einen semantischen Check der Block Inhalte durch und kann somit logische Fehler feststellen und verhindern. Die möglichen sinnvollen Werte (OFF/MEDIUM/FULL) beschränken sich dabei auf Objekte im System Tablespace (OFF) oder alle Objekte außer Indizes (MEDIUM).

DB_LOST_WRITE_PROTECT
Mit Hilfe dieses Parameters kann in Data Guard Umgebungen Lost- bzw. Stray-Writes sowohl auf der Primär- als auch auf der Standby-Seite erkannt und bei Data Guard Umgebungen, in denen die kostenpflichtige Active Data Guard Option zum Einsatz kommt, mit Hilfe eines automatischen RMAN BLOCK Recoveries im Hintergrund gleich behoben werden. Alle diese Parameter zusammen können auch mit Hilfe des DB_ULTRA_SAFE Parameters gesetzt werden.

Verhalten der Datenbank

Normalerweise hat eine Block Korruption keine direkten Auswirkung auf den Rest der Datenbank. Allerdings muss man unterscheiden, ob die Datenbank beim Schreiben des Blocks einen I/O Fehlermeldung bekommen hat oder ob die Korruption beim Lesen festgestellt wurde.

Ist der Fehler beim Lesen aufgetreten, so wird wie oben beschrieben der Block in V$DATABASE_BLOCK_CORRUPTION protokolliert. Das weitere Verhalten hängt nun davon ab, ob es sich um eine Active Data Guard Umgebung handelt und an welcher Stelle in der Datendatei die Block Korruption aufgetreten ist.

Handelt es sich um einen "normalen" Block einer Tabelle bzw. Indizes, so wird Active Data Guard und die Datenbank den laufenden Select kurz anhalten und im Hintergrund den Block mit Hilfe von RMAN von einer der Standby Datenbanken wiederherstellen. Dann wird die Abfrage fortgesetzt und der Benutzer bekommt vom aufgetretenen Fehler nichts mit, außer dass der Select kurz "gehangen" hat. Handelt es sich bei dem korrupten Block um einen Block im Tablespace bzw. Datendatei Header, so ist ein Block Recovery mit RMAN nicht möglich. Ist keine Active Data Guard Umgebung vorhanden, so wird der User eine ORA- Fehlermeldung erhalten, wenn er versucht auf den Block zuzugreifen.

Anders sieht es aus, wenn die Ursache in einer I/O Fehlermeldung zu suchen ist. Interessanterweise verhält es sich ab 11.2.0.2 anders als früher, wie auch in MOS Note 7691270.8 "Crash the DB in case of write errors (rather than just offline files)" beschrieben. Unter 10g wird der Tablespace einfach OFFLINE genommen, wenn der Fehler nicht im System Tablespace auftritt und sich die Datenbank im Archivelog Modus befindet. Ohne den Archivelog Modus wird auch in 10g die Datenbankinstanz "hart" beendet. Mit 11.2.0.2 hat sich dieser Default geändert: Nun wird die Datenbank Instanz immer hart beendet - unabhängig vom Archivelog Modus und Tablespace. Speziell in Multitenant Umgebungen kann dies negativ auffallen, wie der Autor selbst bei einigen Tests erfahren musste.

Allerdings kann das ehemalige Verhalten wieder erzwungen werden, indem man den folgenden, sprechenden Instanzparameter "_datafile_write_error_crash_instance" auf FALSE setzt (Defaultwert ist TRUE):

alter system set "_datafile_write_errors_crash_instance" = FALSE

(Automatische) Reparatur

RMAN> recover corruption list;

Starting recover at 05-FEB-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=151 device type=DISK
finished standby search, restored 1 blocks

starting media recovery
media recovery complete, elapsed time: 00:00:04

Finished recover at 05-FEB-14
Eine weitere Vereinfachung liefert die Nutzung einer Active Data Guard Umgebung. Denn dort werden die einzelnen Block Recoveries angestoßen, sobald ein Prozess auf einen Block Fehler trifft - online und ohne Interaktion. Wer also seine Datenbank vor Block Korruption schützen möchte, sollte die Active Data Guard Technologie verwenden.

Best Practices & Fazit

  • RMAN Backup !! (und TRIAL Recovery)
  • Periodische Abfragen von V$DATABASE_BLOCK_CORRUPTION
  • Überwachung von I/O Fehlermeldungen in den ALERT.LOGs
  • Periodisch RMAN Befehle mit der Option "CHECK LOGICAL"
  • ANALYZE Statement mit der Option VALIDATE STRUCTURE für wichtige Objekte oder bei Verdacht
Mit diesen Technologien und mit Active Data Guard verschwindet "das Schreckgespenst Datenkorruption".

Nützliche Links und Referenzen

  • Best Practices for Corruption Detection, Prevention, and Automatic Repair - in a Data Guard Configuration (Doc ID 1302539.1)
  • Crash the DB in case of write errors (rather than just offline files) (Doc ID 7691270.8)
  • Prevention, Detection and Repair of Database Corruption (Doc ID 76375.1)
  • Zurück zur Community-Seite