DBA Community - Februar 2014
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.
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.
Erkennung
Unterschiedliche Oracle Utilities und eingebaute Technologien führen eine Überprüfung der Datenblöcke durch.
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=TYPICALDiese 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.
alter system set "_datafile_write_errors_crash_instance" = FALSE (Automatische) Reparatur Die Reparatur einzelner Blöcke kann natürlich direkt über das Kommando "RECOVER BLOCK" funktionieren. Allerdings kann es doch sehr aufwändig sein, sich alle Datendateien und Blöcke aus V$DATABASE_BLOCK_CORRUPTION zu notieren. Einfacher funktioniert das Ganze über den RMAN Befehl "RECOVER CORRUPTION LIST": 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-14Eine 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 Zum Schluss nochmals eine gute Liste zur Prävention und Überwachung von Block Korruption:
Nützliche Links und Referenzen
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||