Nachträglich DAG einrichten

[NorbertFe 1.799]

Ich nehme an, du hast den hier gelesen: http://technet.microsoft.com/de-de/library/bb397387%28v=exchg.80%29.aspx Also wenn sowas regelmässig bei dir vorkommt, dann spricht da eher was für Hardwaredefekt als für einen Exchangefehler, wenn du mich fragst.

 

Zusätzlich http://support.microsoft.com/kb/314917/en-us

 

Bye

Norbert

[sakoti 11]

Sprich, ich könnte mal eseutil /p und mitunter noch eseutil /d versuchen und wenn das in 2-3 Monaten wieder kommt die HW tauschen?

[Daniel -MSFT- 129]

Sprich, ich könnte mal eseutil /p und mitunter noch eseutil /d versuchen und wenn das in 2-3 Monaten wieder kommt die HW tauschen?

 

Diese Methode sollte nur verwendet werden, wenn andere Methoden nicht erfolgreich waren. Das ist sozusagen die letzte Verteidigungslinie. Nach einem Hard Recovery musst Du zwingend eine Offlinedefragmentierung der reparierten Datenbank sowie das Tool Isinteg ausführen, um die logischen Fehler zu reparieren. Diese Schritte können mithilfe des Reparaturtasks der Datenbank-Problembehandlung von Exchange durchgeführt werden. Auf diese Weise werden automatisch die Reparaturprogramme Eseutil /P, Eseutil /D und Isinteg ausgeführt. Also kein "mitunter" an dieser Stelle.

 

Ein ESE 474-Ereignis mit einem Fehler -1018 kann aufgrund einer defekten Festplattenteilsystem-Hardwarekomponente oder aufgrund veralteter oder inkompatibler Treiber und/oder Firmware im Festplattenteilsystem auftreten.

Nachdem ein Fehler -1018 aufgetreten ist, melden Diagnosehardwaretests, die für den Server ausgeführt werden, möglicherweise keine Festplattenteilsystem-Hardwareprobleme, und die Annahme liegt nahe, dass Exchange Server für das Problem verantwortlich ist.

 

Umfangreiche Untersuchungen durch Microsoft und die Hardwarehersteller haben ergeben, dass komplexe Probleme mit den Festplattenteilsystem-Hardwarekomponenten und den unterstützenden Treibern bzw. der Firmware für die meisten Fehler -1018 verantwortlich sind.

 

Exchange meldet einen Fehler -1018, wenn eine initialisierte Seite in der Datenbankdatei gefunden wird, für die eine der folgenden Bedingungen gilt:

• Die auf der Seite gespeicherte Prüfsumme entspricht nicht dem Ergebnis der Prüfsummenneuberechnung, die beim Lesen der Seite durchgeführt wird. 
• Die auf der Seite gespeicherte Seitennummer entspricht nicht der Seitennummer, die sich unter Berücksichtigung des physikalischen Speicherorts in der Datenbankdatei auf der Seite befinden sollte. 

Exchange kann dafür verantwortlich sein, selbst einen Fehler -1018 zu generieren, wenn eines der folgenden Szenarien eintritt:

• Exchange erstellt eine Seite, die die falsche Prüfsumme aufweist. 
• Exchange erstellt eine Seite ordnungsgemäß, weist das Betriebssystem jedoch an, diese an den falschen Speicherort zu schreiben.

Exchange generiert eine Prüfsumme für eine Seite, die auf den Datenträger geschrieben werden soll, nachdem alle Daten auf die Seite geschrieben wurden. Hierzu gehört auch die Seitennummer selbst. Nachdem Exchange der Seite die Prüfsumme hinzugefügt hat, weist Exchange das Betriebssystem Windows an, die Seite mithilfe von veröffentlichten, auf Windows basierenden Standard-APIs auf den Datenträger zu schreiben.

 

Vorübergehende Speicherfehler können dann bewirken, dass die Seite an den falschen Speicherort auf der Festplatte geschrieben wird. Obwohl die Prüfsumme der Seite richtig ist, meldet Exchange einen Fehler -1018, weil die logische Seitennummer nicht der physikalischen Seitennummer entspricht.

 

Ein einzelner Fehler -1018, der in einer Exchange-Datenbank gemeldet wird, bewirkt im Allgemeinen nicht, dass die Exchange-Datenbank beendet wird. Als einziges Symptom tritt das Vorhandensein des Fehlers -1018 auf. Die betroffene Seite befindet sich möglicherweise in einem Ordner, auf den nur selten zugegriffen wird (z. B. im Ordner Gesendete Elemente oder Gelöschte Elemente), oder in einer Anlage, die selten geöffnet wird oder sogar leer ist.

 

Es ist unwahrscheinlich, dass ein einzelner Fehler -1018 große Datenverluste verursacht. Fehler -1018 stellen jedoch ein Problem dar, weil sie anzeigen können, dass ein Speichersystem mindestens einmal Daten nicht zuverlässig gespeichert oder abgerufen hat. Der Fehler -1018 ist eine frühzeitige Warnung zu einem Problem, dass sich wahrscheinlich laufend verschlimmert. Selbst wenn der erste Fehler -1018 für eine leere Seite in der Datenbank gemeldet wird, ist nicht bekannt, welche Seite als nächstes beschädigt wird. Wenn eine wichtige globale Tabelle beschädigt wird, wird die Exchange-Datenbank möglicherweise nicht gestartet, und die Datenbankreparatur ist ggf. nicht oder nur teilweise erfolgreich.

 

Nachdem ein Fehler -1018 protokolliert wurde, sollten Sie die Möglichkeit eines drohenden Ausfalls oder zusätzlicher zufälliger Beschädigungen an der Datenbank in Betracht ziehen und bei Ihrer Planung berücksichtigen, bis Sie die eigentliche Ursache des Fehlers ermittelt haben.

 

Quelle: ESE 474 -1018: Nicht behebbarer Fehler in Datenbank

bearbeitet 11. Juli 2014 von Daniel -MSFT-

[NorbertFe 1.799]

;) Rate mal, was oben verlinkt ist. ;)

[Daniel -MSFT- 129]

Tja, wenn der OP aber dem Link nicht folgt, hilft vielleicht ein Zitat weiter? BTW: Mit Exchange 2003 SP1 hatten wir einen Error Correction Modus eingeführt, der ECC Einzelbit-Fehler in der Exchange-Datenbank automatisch zu reparieren hilft. Wenn man mit Nachfolgern trotzdem regelmäßig -1018-Fehler hat, dann sind das Multibit-Fehler und ein deutliches zeichen für ein Hardware- und/oder Treiberproblem. Ich würde hier auch mal den Bad Sector Count von den Festplatten nachverfolgen sowie Franks Hinweise ernst nehmen: 

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.
http://www.msxfaq.de/notfall/-1018.htm 

[sakoti 11]

Wieso ist dann immer nur eine der Datenbanken betroffen, wenn es sich um einen HW Fehler handeln soll.

Passt nicht wirklich....

[tesso 360]

Wieso ist dann immer nur eine der Datenbanken betroffen, wenn es sich um einen HW Fehler handeln soll.

Passt nicht wirklich....

Murphy? Pferd und Apotheke?

Was willst du hören. Viele Leute hier haben Exchange 2010 und keine Probleme. Dein Exchange muckt alle paar Monate. Da ist doch die Annahme HW-Fehler nicht abwegig. Vor allem bei der Beschreibung aus dem Link.

[Dukel 436]

Wieso ist dann immer nur eine der Datenbanken betroffen, wenn es sich um einen HW Fehler handeln soll.

Passt nicht wirklich....

 

Ich würde einfach mal die Hardware überprüfen und damit dies als Fehler ausschließen, wenn dies das naheliegendste Problem ist.

Exchange wird nicht umsonst diesen Fehlercode loggen.

[NorbertFe 1.799]

Wieso ist dann immer nur eine der Datenbanken betroffen, wenn es sich um einen HW Fehler handeln soll.

Passt nicht wirklich....

Kannst du Virenscanner usw. denn ausschliessen? Hast du ggf. eine andere Hardware, auf der du das zu Testzwecken laufen lassen kannst? Eventuell ja ein guter Zeitpunkt um mit Virtualisierung zu starten?

 

Bye

Norbert

[sakoti 11]

Auf dem Server läuft MS Security Essentials. Der sollte keine Probleme machen.

 

3rd Party läuft noch Spamfighter, mit dem es aber auch nie Probleme gab.

 

Virtualisierung ist aktuell kein Thema, wäre aber wohl ein guter Zeitpunkt.

 

Ich könnte eine Sicherung auf eine andere Hardware spielen und da einfach laufen lassen in eigenem / autarken Netz meinst du?

 

Macht denke ich jetzt aber keinen Sinn, weil in 3 Wochen in andere Räumlichkeiten umgezogen wird und die Server dann ohnehin runtergefahren werden müssen. Aber ein Klon kann ja dennoch schon einmal aufgebaut werden und bis dahin laufen. Danke Dir.

[NeMiX 76]

Hast du dir mal die Smartwerte der HDDs angeschaut? Wurde ja schon oben nachgefragt. Wir hatten das Problem mal bei einem Exchange 2007 als eine HDD im Raid1 (dort lag die DB) kurz vorm sterben war laut Smart. Der Raid Controller hat noch alles als ok angezeigt.

[sakoti 11]

Ich hab ein Raid5 laufen mit einem Promise Controller + HotSpare HDD.

 

Kannst du mir ein Tool empfehlen zum Auslesen der Smart-Werte? Danke.

bzw. glaube nicht, dass ich mit Software durch das Raid zur einzelnen HDD durchgreifen kann? aber lasse mich da gerne verbessern...

[NorbertFe 1.799]

Auf dem Server läuft MS Security Essentials. Der sollte keine Probleme machen.

Warum sollte er das nicht? Der kann genauso falsch konfiguriert werden wie andere. Abgesehen davon, darf der auf Servern eingesetzt werden?

 

Bye

Norbert

bzw. glaube nicht, dass ich mit Software durch das Raid zur einzelnen HDD durchgreifen kann? aber lasse mich da gerne verbessern...

Also ein "richtiger" RAID Controller liefert dir natürlich den Zustand einzelner Platten. Wäre ja wohl sonst ziemlich "fahrlässig", oder?

 

Bye

Norbert

[sakoti 11]

Ah, war ein wenig versteckt bei der promise software - bei allen 4 HDD wird jeweils 0 bei Fehler allgemein, bei andere Fehler als lesen / Schreiben und auch bei Schreib- und Lesefehler angezeigt.

Dann sind die HDD wohl auch ok

 

Kann es sein, dass der ESE Fehler sich erledigt, wenn ich alle aktuellen Patches und SP drauf hab? Aktuell ist SP2 drauf ohne RUs ;-)

bearbeitet 11. Juli 2014 von shafner

[NorbertFe 1.799]

Nicht unmöglich, aber im Allgemeinen entsteht ein Datenbankfehler nicht durch fehlende Servicepacks. Aber einen Versuch ist es schon allein deswegen wert.

 

Bye

NOrbert