-1018 Fehler im Eventlog

Und nun zu einem beliebten Thema der Newsgroup, welches untrennbar mit Backup zusammenhängt, auch wenn es eigentlich eher auf die Datenbank bezogen ist. Die immer wieder gefürchteten -1018 Fehler, die seit Exchange 2003 SP1 etwas entschärft wurden.

Unterstützung durch Net at Work:
Wenn Sie selbst nicht abschätzen können, was der nächste richtige Schritt für die Korrektur einen -1018-Fehlers ist, dann können Wie sie auch unterstützen.

Was ist das ?

Die Datenbank von Exchange ist in 4kByte Blöcken organisiert und jeder Block hat eine "Prüfsumme"(CRC Check). Damit sichert Exchange die Integrität der Datenbank. So kann Exchange schnell feststellen, ob "etwas" die Datenbank verändert hat.  Die Fehlermeldung bedeutet, dass die Prüfsumme des gelesenen Blocks nicht stimmt. Also hat "irgendetwas" seit dem letzten Schreiben bis eben den Block verändert. oder etwas" hindert" Exchange daran, "richtig" zu lesen.

Eine ähnliche Funktion gibt es für das Dateisystem NTFS selbst leider nicht. Ich weiß nicht wie oft sie schon auf Office geschimpft haben, weil es eine DOC-Datei nicht mehr lesen konnte aber eigentlich war weder Office noch Windows NT schuld, sondern eigentlich das Plattensubsystem.

Das hilf aber nichts. Mindestens eine Seite der Datenbank ist nicht mehr lesbar und da Exchange nun mal binäre Bäume nutzt hängt es nun allein davon ab, wie hoch diese Seite aufgehängt ist.

Fällt eine Seite am Ende des Baumes aus, dann betrifft dies vielleicht nur eine einzige Mail oder nur die Anlage einer Mail. Fällt jedoch eine höher eingeordnete Seite aus, dann sind alle darunter liegenden Seiten nicht mehr erreichbar, selbst denn deren Inhalt noch in Ordnung ist. In der Regel ist ein -1018 aber nicht der einzige Fehler, sondern der erste, der erkannt wurde. Es können also durchaus noch weitere Datenbankseiten "defekt" sein. Generell gilt bei einem -1018:

Datenverluste werden sich nicht verhindern lassen, da erforderliche Informationen nicht mehr korrekt lesbar sind.

Um den Bogen zum Thema Backup zu spannen: Eine "Onlinesicherung" ist immer so angelegt, dass sie die Protokolldateien erst dann löscht löscht, wenn die Datenbank gesichert werden konnte (also kein -1018). Schlägt das Backup aber fehl, dann werden die Protokolldateiein nicht gelöscht und bleiben für die Wiederherstellung erhalten.

Ursachen

Ursachen für so einen Fehler dafür gibt es viele. Entweder wurde der Block schon fehlerhaft geschrieben, weil zu der Zeit schon ein Fehler im Treiber oder Speichersubsystem vorlag oder der Fehler trat beim Lesen auf. Beim lesen versucht Exchange aber diese Seite insgesamt sechzehn mal zu lesen. Damit ist ein temporärer Fehler ausgeschlossen. Meist ist es wirklich ein Hardwaredefekt oder Treiberdefekt. In seltenen Fällen auch ein Filtertreiber im Dateisystem, wie ihn Virenscanner gerne verwenden. Schau im Eventlog nach. Seit wann gibt es die Fehler. Wenn man ein "tägliches Online-Backup " macht, dann hat man den Fehler  im Eventlog und im Backupprotokoll, nachdem das "etwas" passiert ist.

Also gehe von einem Hardwarefehler aus und versuche hier für die Zukunft eine Lösung zu schaffen, sonst kommt der Fehler garantiert wieder zurück. Denkbar sind noch 

  • Server ausgeschaltet und Schreibcache auf Platte und/oder Controller aktiv
  • Speicherfehler, Blue Screen etc. der Daten der Festplatte verändert hat
  • Virenscanner verhindert Festplattenzugriff
  • Fehler im RAID-Kontroller 
  • SCSI-Treiber Bug.
  • Software Bug Exchange 
    (verrechnen kann man sich ja mal, ist aber sehr sehr sehr unwahrscheinlich).

Viren scheiden in der Regel aus, da Exchange die Dateien geöffnet hält. Und mir auch keine Viren bekannt sind, die die Exchange-Datenbank angreifen.

Was darf ich nicht tun

Nun ja, die traurige Wahrheit (vermutlich Datenverlust) kennst du schon. Wie geht es weiter. Machen wir das beste draus. Auf keinen Fall unkoordiniert Dateien löschen oder die bekannten Tools wie ESEUTIL und ESEFILE aufzurufen.

Eigentlich müsste man nun erst die Ursache für den -1018 beseitigen, d.h. die Plattensysteme reparieren. Das ist aber ein schwieriges Ding, da man nicht genau weiß, was kaputt ist. Meiner Erfahrung nach hatte ich einen -1018 bisher immer nur auf "Selbstbauhardware". Aber das heißt ja erst mal nichts.

Vorbereitung zum Fixen

Der Fehler ist da und es gibt eine Ursache dafür. Diese muss erst gefunden und beseitigt werden. Versuchen Sie keine Reparatur mit ISINTEG, ESEUTIL oder ein Restore auf einem Server, bei dem Sie nicht irgendetwas "gebessert" haben. Ansonsten wird der Fehler wieder kommen. Vielleicht nicht sofort aber garantiert und wer sagt ihnen, dass sie dann nicht noch mehr Probleme haben ?. Wenn Sie kein Backup haben, dann kann es hilfreich sein, die ESEUTIL-Schritte auf einem schnellen Server durchzuführen um Zeit zu sparen.

Wie fixe ich das (ich habe ein Backup)

Wenn Sie wirklich ein Backup haben, dann nutzen Sie es. Prüfen Sie aber vorher noch mal nach:

  • JA ich habe ein Online Backup von gestern 
  • JA ich habe alle Protokolldateien (keine umlaufprotokollierung aktiv)
  • JA das Backup ist auf dem Band und Lesbar

Gibt es kein "anderes" Backup (Offline, OFM etc.) dann gehe direkt zu: "Wie fixe ich das (ich habe KEIN Backup)

Dann ist der Weg klar vorgegeben:

  • Stoppe allen Mailverkehr (MTA Runterfahren etc.)
  • Fahre die Exchange┬┤-Dienste (Ausnahme Exchange Systemaufsicht) herunter
  • Kopiere die Datenbank auf einen andern Server (auf jeden Fall weg von diesem Server, der offensichtlich kein sauber funktionierendes Subsystem hat)
  • Kopiere auch die Protokolldateien auf einen anderen Server (sicher ist sicher)
  • Repariere nun die Platte (Firmware-Update auf RAID Controller, Treiberupdate unter NT, Firmware der Festplatten, Schreibcache abschalten, Mach was du machen kannst.
  • Restauriere das letzte erfolgreiche Backup (Das hatte ja noch keinen -1018)
  • Starte die Exchange Dienste

Exchange wird nun anhand seiner Protokolldateien einiges zu Tun haben, um die Transaktionen seit dem letzten Backup nachzuziehen. Wenn er dann fertig ist, dann starte gleich wieder ein "Onlinebackup". So stellst du sofort fest, dass die Datenbank noch heile ist.

Datenverluste dürften bei dieser Konstellation nicht aufgetreten sein. Aber du hast eventuell immer noch das defekte Subsystem in dem Server. Warte nicht zu lange mit der Reparatur. Prüfe dauernd dein Backup. Sichere eventuell die Protokolldateien auch unter Tage weg.

Wie fixe ich das (ich habe KEIN Backup !)

Kein Backup bedeutet kein "Online Backup". Bei jedem anderen Backup kann man nicht sicher sein, dass die Datenbank beim letzten Backup nicht auch schon defekt war. Du hast den -1018 erst dann bemerkt, als jemand zufällig diese Seite lesen wollte. Einen regelmäßigen Check gibt es ohne Onlinebackup nicht. Ich gehe recht in der Annahme, dass du auch keine Protokolldateien hast. Schließlich ist das Löschen doch nervig, weswegen man beim Offline Backup gerne auch die umlaufprotokollierung aktiv lässt. Selbst mit den Protokolldateien wäre es mühselig alle Protokolldateien bis zu dem Zeitpunkt zu haben, an dem die Datenbank noch konsistent war. Egal machen wir das beste daraus

  • Stoppe allen Mailverkehr (MTA Runterfahren etc.)
  • Fahre die Exchange-Dienste NICHT herunter
  • Hole dir die aktuelle Version von EXMERGE aus dem Ressource Kit. (oder Exchange Tools und Hilfsprogramm)
  • Schaffe genug Platz auf einer Festplatte, denn nun werden alle Postfächer mit EXMERGE in PST-Dateien exportiert. Damit holen wir das "maximale" Aus der Datenbank, was wir noch lesen können. Ohne Single Instance Store kann das Volumen aber problemlos groß werden)
  • Starte ein Outlook mit ausreichend Rechten und exportiere alle öffentlichen Ordner in eine weitere PST-Datei.
  • Nun fahre die Exchange-Dienste runter
  • Kopiere die Datenbank auf einen andern Server (auf jeden Fall weg von diesem Server, der offensichtlich kein sauber funktionierendes Subsystem hat)
  • Kopiere auch die Protokolldateien  auf einen anderen Server (sicher ist sicher)
  • Repariere nun die Platte (Firmware-Update auf RAID Controller, Treiberupdate unter NT, Firmware der Festplatten, Schreibcache abschalten, Mach was du machen kannst.
  • Mit ESEUTIL müssen wir nun Exchange beibringen die Seiten mit dem -1018-Fehler "hart" zu löschen. Lies dazu bitte die Dokumentation zu ESEUTIL durch, damit du auch sicher weißt, was du da tust und nicht am Ende mich verklagst
  • Mit ISINTEG müssen wir ihm nun beibringen die logische Integrität zu prüfen und eventuell zu korrigieren. Auch hier bitte Dokumentation gewissenhaft lesen.
  • Information
    Diese Durchläufe können eventuell mehrfach notwendig sein, bis sie fehlerfrei sind
    Diese Programme können Stunden und manchmal Tag brauchen. Werte von 2-3 Gigabyte/Stunde sind schon recht passabel
    Diese Programme brauchen temporär viel Platz. Eventuell ist es sinnvoll eine weitere Festplatte an den Server für diese Zeit anzuschließen.
  • Nun starte die Exchange Dienste wieder

Wir haben nun wieder eine korrekte Datenbank, die von Prüfsummenfehlern bereinigt ist und noch Reste der Information enthält. Wenn wir Glück haben, fehlt nur wenig, so dass wir weitermachen können und nicht alles neu einrichten müssen. Eventuell fehlen aber Ordner oder Inhalte. Diese kann man nun mit EXMERGE oder Outlook  wieder importieren. Mühselig aber es gibt keine Alternative

Statt der Reparatur kann man auch eine alte Datenbank die nachweislich korrekt ist, zurückholen und dort die fehlenden Einträge wieder importieren. Die Sicherheitskopie der Datenbank ist notwendig, wenn während der Reparatur mehr kaputt geht, als man erwartet hat und man mit neueren Tools oder mit Hilfe eines Fachmann/frau noch mal einen Versuch starten will.

Schreibcache und -1018

(Basierend auf einer News von Jens Tolkmitt)

Überhaupt weist ein -1018 immer auf Fehler außerhalb der JET hin. Was deinen Kontroller (bes. verzögertes Schreiben) angeht: so etwas kann und ist in den meisten Fällen irgendwann tödlich. Write-Back Caching ist bei transaktionsorientierten Datenbanksystemen (und das ist auch Exchange) immer verkehrt. In Bezug auf Exchange  kann z.B. folgendes passieren: eine Transaktion wird durch die JET in die Datenbank geschrieben, der Checkpoint weitergeschaltet. Jetzt stürzt der Server ab, die Daten stehen aber noch im Cache und nicht in der EDB-Datei, verschwinden also. Fährt der Server wieder hoch, so wird das Recovery für alle Daten hinter den aktuellen Checkpoint ausgeführt. Versuchst du dann, auf solche Daten zuzugreifen.... Aus jeden Fall solltest du einen Fehler bekommen, dass die DB inkonsistent ist (aber nicht -1018, sondern eher -550).

-1018 und Exchange 2003 SP1

Ab Exchange 2003 SP1 hat Microsoft das Prüfsummenverfahren derart verbessert, dass so genannte "1-Bit-Fehler" erkannt und korrigiert werden. Solche Verfahren sind in der Datenübertragung aber auch beim Hauptspeicher (Stichwort: ECC-Ram) schon lange bekannt. Die bisherige Prüfsumme wurde durch einen Algorithmus abgelöst, der nicht nur den Fehler in einem Bit erkennt, sondern auch welches Bit falsch ist. Exchange 2003 SP1 kann dann diesen Fehler per Software korrigieren. Ihr Exchange Server verweigert in diesem Fall also nicht plötzlich den Dienst, sondern Sie können ohne Probleme weiter arbeiten.

Allerdings sollte Sie diesen Fehler nicht auf die leichte Schulter nehmen, denn das Problem ist wie beim echten -1018 weiterhin vorhanden und kann sich weiter verschlimmern. Spätestens beim zweiten Bitfehler sind ihre Daten defekt. Verstehen Sie daher diesen Fehler einfach als "Vorwarnung", dass ihr Speichersubsystem nicht 100% fehlerfrei funktioniert und Sie etwas tun sollten.

Weitere Links