Konsistenzprüfung der Datenbank

02.
März
2013
Veröffentlicht von: Bernhard Koch

Haben Sie sich auch schon mal darüber Gedanken gemacht, ob Ihre Datenbank noch konsistent ist?

Haben Sie sich auch schon mal darüber Gedanken gemacht, ob Ihre Datenbank noch konsistent ist? Um die Konsistenz der Daten brauchen wir uns ja keine Gedanken machen, die Applikation ist gut durchdacht, das Datenmodell mit allen Constraints angelegt und für den Rest sorgt die Datenbank.
Wie sieht es aber mit den Tablespace-Dateien aus? Gibt es dort korrupte Bereiche, so dass möglicherweise Daten beschädigt sind?
In diesem Tipp wird beschrieben bei welchen Aktionen Dateien überprüft werden und wie eine manuelle Prüfung angestoßen werden kann.

Alert Log

Erster und wichtigster Punkt ist die Kontrolle der Alert Log-Datei. Sollte bei einem Lese- oder Schreibzugriff ein korrupter Block entdeckt werden, so werden dort die Fehler ORA-01578 oder ORA-01115 ausgegeben.

ORA-01578: ORACLE data block corrupted (file # 1, block # 420)
ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/data/system_01.dbf'

ORA-01115: EA-Fehler beim Lesen von Block aus Datei 1 (Block Nr. 105)

Wenn viele Schreib- und Leseoperationen innerhalb der Datenbank getätigt werden sollte vermutlich ein korrupter Block relativ früh entdeckt werden.

RMAN

Wird der RMAN für die Sicherung der Datenbank verwendet wird ein defekter Block bei einer Sicherung entdeckt. Denn RMAN sichert zwar "nur" benutzte Blöcke, es werden aber alle Blöcke gelesen und dabei tritt der schon bekannte Fehler ORA-01115 auf.

EXP

Der "alte" Export liest ebenfalls alle Blöcke der Datenbank und entdeckt somit korrupte Blöcke, es sei denn der Parameter DIRECT=Y wird verwendet.

EXPDP

ACHTUNG! Data Pump gibt keine Fehlermeldung aus falls korrupte Blöcke vorhanden sind. Es werden auch keine Daten der beschädigten Blöcke exportiert.

 

Wenden wir uns nun der manuellen Prüfung zu. Bei allen Prüfungen auf defekte Blöcke sollte beachtet werden, dass damit Last erzeugt wird. Es müssen alle Blöcke der DB gelesen werden. Je nach Größe der Datenbank dauert das natürlich auch eine gewisse Zeit. Solche Prüfungen sollten also nur stattfinden wenn wenig Last auf der Datenbank ist.

SQL*Plus

Ob bereits korrupte Blöcke in der Datenbank vorhanden sind kann auch über die View V$DATABASE_BLOCK_CORRUPTION abgefragt werden. Jede Oracle Komponente die einen korrupten Block findet trägt den Block in diese View ein;

SQL> select * from v$database_block_corruption;

no rows selected

Mit dem ANALYZE TABLE Statement kann, obwohl es für Tabellenanalysen nicht mehr verwendet werden soll, die Struktur einer Tabelle überprüft werden.

SQL> analyze table scott.emp validate structure;

Table analyzed.

RMAN

Mit RMAN kann manuell überprüft werden ob die Datendateien in Ordnung sind. Mit der Validate Syntax kann angegeben werden ob z. B.: die komplette Datenbank oder nur einzelne Datendateien überprüft werden sollen.

Prüfung der kompletten Datenbank

$ RMAN target /
RMAN> validate database;
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00001 name=/u01/app/oracle/...
...
channel ORA_DISK_1: validation complete, elapsed time: 00:00:35
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1    OK     0              29806        89600           2726196
...
List of Control File and SPFILE
===============================
File Type    Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE       OK     0              2
Control File OK     0              1150
Finished validate at 25-FEB-13

Prüfung eines Datenfiles

$ RMAN target /
RMAN> validate datafile 1;
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
...
channel ORA_DISK_1: validation complete, elapsed time: 00:00:15
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1    OK     0              29806        89600           2726294
  File Name: /u01/app/oracle/oradata/orcl/data/system_01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              47907
  Index      0              9299
  Other      0              2588

Wenn, wie in diesem Beispiel, keine Fehler gelistet werden ist die Datenbank ok.

EXP

Mit dem Export Tool kann eine Prüfung durchgeführt werden ohne dass die Daten wirklich exportiert werden. Unter UNIX wird dafür als Datendatei /dev/null angegeben. Auch unter Windows gibt es eine ähnliche Möglichkeit, dort schreibt man nach >> NUL.

UNIX
exp userid=system/dbsys full=y log=exp.log file=/dev/null
About to export the entire database ...
. exporting tablespace definitions
...
...
Export terminated successfully without warnings.

WINDOWS
exp userid=system/dbsys full=y log=c:\tmp\exp.log file=nul
Die gesamte Datenbank wird gleich exportiert ...
...
Der Exportvorgang endete erfolgreich

Wenn Warnungen ausgegeben werden müssen die Logdateien überprüft werden. Oftmals sind es "nur" Objekte die mit dem EXP Tool nicht exportiert werden können.
Sollten fehlerhafte Blöcke gefunden werden endet der Export mit Fehlern.

DBV

DBVERIFY ist ein Tool von Oracle mit dem die Blockintegrität geprüft werden kann. Es hat aber gegenüber RMAN den Nachteil, dass nur Datenfiles und keine Controlfiles geprüft werden können.

$ dbv file=/u01/app/oracle/oradata/orcl/data/system_01.dbf blocksize=8192
DBVERIFY: Release 11.2.0.2.0 - Production on Mon Feb 25 13:57:48 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/orcl/data/system_01.dbf


DBVERIFY - Verification complete

Total Pages Examined         : 89600
Total Pages Processed (Data) : 47907
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 9299
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 2588
Total Pages Processed (Seg)  : 1
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 29806
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 2727049 (0.2727049)

Auch hier ist natürlich entscheidend, ob bei der Ausgabe auf Fehler verwiesen wird.

 

Nun haben Sie einen kleinen Überblick erhalten mir welchen Werkzeugen festgestellt werden kann, ob es innerhalb der Datenbank zu korrupten Blöcken gekommen ist.
Mehr zu korrupten Blöcken und deren Reparatur erfahren Sie in unseren Backup und Recovery Kursen.

Konsistenz Datenbank Verwaltung

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.