8
SBS 2011 irreparabel??
Guten Morgen liebe IT-ler.
Da dies mein erster Beitrag ist kurz zu meiner Person. Mein Name ist Lucas, ich bin 27 Jahre jung/alt komme aus Sachsen-Anhalt.
Ich hoffe mein neues Thema stößt niemandem auf, da ich es nicht so recht in vorhande einordnen kann da es mehrere Bereiche betrifft denke ich.
Zur Sache: Ich wurde frisch in ein Projekt geworfen, bei dem der alte Admin "gegangen worden ist". Übergabezeit im Grunde 0.
Es existiert folgende Konstellation:
Ein Hyper-V Server mit einem Server 2012 - nicht R2 auf dem neben einem 2008er Terminalserver auch ein SBS 2011 läuft. Updates soweit alle drauf.
Dieser hat wohl seit Ewigkeiten das Problem das er die Windows Server Sicherung nicht durchführt weil er Fehler beim Exchange bzw. dessen Datenbank findet.
Ich wollte nun die Datenbank mit eseutil defragmentieren, jedoch stoppte dieser Vorgang mit dem Fehler 1018.
Im Anschluss neuer Versuch zuerst mit dem Repair-Schalter. Das lief auch eine ganze Weile, brach aber auch irgendwann ab.
Ende vom lied: Manche Nutzer konnten sich nicht mehr intern Mailen und erhieten die Mails zurück mit Fehler die sich auf den Informationsspeicher beziehen.
In meiner Not hatte ich versucht die Datenbank auf einer Testinstallation von einem SBS 2011 auf einer anderen Maschine mit eseutil zu bearbeiten, und siehe da:
sowohl Repair als auch Defrag liefen auf Anhieb durch und auch die anschließende Prüfung auf Checksummenfehler blieb ohne negativen Befund.
Also kopierte ich Datenbank zurück auf den Originalen SBS und startete den Informationsspeicher neu: Ergebniss: Alle Funktionen wieder i.O.
ABER: Das Backup vom SBS bescheinigte mir am Abend erneut: "Fehler bei der Konsistenzprüfung"
Nachdem ich nochmal kurz die Chance hatte mit dem alten Admin zu sprechen meinte er, dass es wohl mal irgendwann RAM Probleme gab und die SQL Logfiles auf C voll liefen und er einfach mal alles mögliche gelöscht hatte und Platz zu schaffen. Alle zumindest was die Logfiles betrifft. Die Maschine mit dem defekten RAM gibt es jetzt nicht mehr und den neuen Hyper-V habe ich jetzt über Ostern auch im Test gehabt. RAM ohne Fehler. Das RAID10 auf dem die VM´s liegen hat auch keine defekte.
Nun meine Frage: Muss ich eventuell noch selber irgendwelche logs ode Sonstige Dateien irgendwo löschen oder Transportdateien anpassen damit der Server bei der Sicherung nicht fälschlicherweise annimmt, dass die Exchange Datenbank defekt sei? Was kann ich sonst noch tun? Oder ist der Fall hoffnungslos und nur eine komplette Neuinstallation hilft? Das wäre aber echt der Horror und ich hoffe Sehr auf eure Hilfe.
Nebebei. Ich habe mal versucht irgendwelche "normalen" Dokumente aus dem Backup zurück zu holen: Das klappt soweit ganz gut.
Vielen vielen Dank.
lg Lucas
Da dies mein erster Beitrag ist kurz zu meiner Person. Mein Name ist Lucas, ich bin 27 Jahre jung/alt komme aus Sachsen-Anhalt.
Ich hoffe mein neues Thema stößt niemandem auf, da ich es nicht so recht in vorhande einordnen kann da es mehrere Bereiche betrifft denke ich.
Zur Sache: Ich wurde frisch in ein Projekt geworfen, bei dem der alte Admin "gegangen worden ist". Übergabezeit im Grunde 0.
Es existiert folgende Konstellation:
Ein Hyper-V Server mit einem Server 2012 - nicht R2 auf dem neben einem 2008er Terminalserver auch ein SBS 2011 läuft. Updates soweit alle drauf.
Dieser hat wohl seit Ewigkeiten das Problem das er die Windows Server Sicherung nicht durchführt weil er Fehler beim Exchange bzw. dessen Datenbank findet.
Ich wollte nun die Datenbank mit eseutil defragmentieren, jedoch stoppte dieser Vorgang mit dem Fehler 1018.
Im Anschluss neuer Versuch zuerst mit dem Repair-Schalter. Das lief auch eine ganze Weile, brach aber auch irgendwann ab.
Ende vom lied: Manche Nutzer konnten sich nicht mehr intern Mailen und erhieten die Mails zurück mit Fehler die sich auf den Informationsspeicher beziehen.
In meiner Not hatte ich versucht die Datenbank auf einer Testinstallation von einem SBS 2011 auf einer anderen Maschine mit eseutil zu bearbeiten, und siehe da:
sowohl Repair als auch Defrag liefen auf Anhieb durch und auch die anschließende Prüfung auf Checksummenfehler blieb ohne negativen Befund.
Also kopierte ich Datenbank zurück auf den Originalen SBS und startete den Informationsspeicher neu: Ergebniss: Alle Funktionen wieder i.O.
ABER: Das Backup vom SBS bescheinigte mir am Abend erneut: "Fehler bei der Konsistenzprüfung"
Nachdem ich nochmal kurz die Chance hatte mit dem alten Admin zu sprechen meinte er, dass es wohl mal irgendwann RAM Probleme gab und die SQL Logfiles auf C voll liefen und er einfach mal alles mögliche gelöscht hatte und Platz zu schaffen. Alle zumindest was die Logfiles betrifft. Die Maschine mit dem defekten RAM gibt es jetzt nicht mehr und den neuen Hyper-V habe ich jetzt über Ostern auch im Test gehabt. RAM ohne Fehler. Das RAID10 auf dem die VM´s liegen hat auch keine defekte.
Nun meine Frage: Muss ich eventuell noch selber irgendwelche logs ode Sonstige Dateien irgendwo löschen oder Transportdateien anpassen damit der Server bei der Sicherung nicht fälschlicherweise annimmt, dass die Exchange Datenbank defekt sei? Was kann ich sonst noch tun? Oder ist der Fall hoffnungslos und nur eine komplette Neuinstallation hilft? Das wäre aber echt der Horror und ich hoffe Sehr auf eure Hilfe.
Nebebei. Ich habe mal versucht irgendwelche "normalen" Dokumente aus dem Backup zurück zu holen: Das klappt soweit ganz gut.
Vielen vielen Dank.
lg Lucas
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 236209
Url: https://administrator.de/contentid/236209
Printed on: April 24, 2024 at 06:04 o'clock
8 Comments
Latest comment
Moin,
mal abgesehen davon, das man mit Deiner wenig detaillierten Beschreibung nicht viel anfangen kann ... wenn der MX und die Sicherung auf einem neu aufgesetztem SBS anstandslos läuft und Du nicht weisst, was an der Kiste alles verbogen ist:
Warum versuchst Du nicht eine Migration SBS2011 --> SBS 2011??
LG, Thomas
mal abgesehen davon, das man mit Deiner wenig detaillierten Beschreibung nicht viel anfangen kann ... wenn der MX und die Sicherung auf einem neu aufgesetztem SBS anstandslos läuft und Du nicht weisst, was an der Kiste alles verbogen ist:
Warum versuchst Du nicht eine Migration SBS2011 --> SBS 2011??
LG, Thomas
Vielen Dank für deie Antwort.
Migration .. eventuell eine Idee Wert. Was braucht ihr denn noch für Informationen um das alles besser einschätzen zu können?
Migration .. eventuell eine Idee Wert. Was braucht ihr denn noch für Informationen um das alles besser einschätzen zu können?
Hi
Zu erst mal willkommen in Forum.
Wenn du nach diesem Fehler googelst erhällst du folgendes:
Beim Ausführen einer Transaktions mit der Jet-Datenbank schreibt den Informationsspeicher und Verzeichnisspeicher die Transaktion in einer Transaktionsprotokolldatei (in "Mdbdata" oder Dsadata.log). Die Transaktion ist dann verpflichtet, die Jet-Datenbank. Die Jet-Engine während dieses Vorgangs berechnet die Seite Prüfsummenwert geschrieben werden, werden im Seitenkopf und dann angefordert wird, dass das Dateisystem auf dem Datenträger die 4-KB-Seite der Daten in die Datenbank geschrieben. Kurz gesagt, das Dateisystem verwendet dieser Aufruf und verwendet Windows NT-Systemdienste zum Weiterleiten dieser Anforderung an den entsprechenden Hardwaregerätetreiber, tatsächlich den Schreibvorgang auszuführen. Treiber für das Hardwaregerät gibt diese Informationen in das Dateisystem, das dann an die Jet-Engine zurückgegeben. Wenn der Aufruf erfolgreich ist, wird die Jet fortgesetzt.
Fehlerhafte Hardware oder Hardwaregerätetreiber zurückliefern Erfolg für Anrufe an sie, bevor sie tatsächlich den physischen Betrieb durchgeführt. Wenn die tatsächliche physische Operation durchgeführt wird, jedoch ein Fehler auftritt und die Daten werden nicht wie erwartet erfolgreich geschrieben.
In bestimmten Datenbankvorgänge wie z. B., aber nicht beschränkt auf Online Backup, backup-Routine wird aufgerufen, das Betriebssystem, um eine 4-KB-Seite mit Daten aus der Datenbank auf dem Datenträger gelesen und auf Band zu schreiben. Vor dem Ausführen eines Commits für die Daten von der Betriebssystem-Aufruf auf dem Band zurückgegeben, vergleicht der Onlinesicherung des Prüfsummenwert im Seitenkopf (aufgezeichnet, wann diese Seite geschrieben wurde auf der Festplatte) aufrufen, die von den LESEVORGANG zurückgegeben wird. Wenn die Prüfsummenwerte nicht übereinstimmen, wird das JET-Datenbankmodul erkennt dies und gibt-1018 (JET_errReadVerifyFailure) zurück.
Gibt es den bei dir die beiden Log Files noch ?? ("Mdbdata" , Dsadata.log) ?
Wenn nicht hast du die möglichkeit diese aus einer Sicherung wiederherzustellen ??
PS: Quelle http://support.microsoft.com/kb/151789/de
LG Andy
Zu erst mal willkommen in Forum.
Wenn du nach diesem Fehler googelst erhällst du folgendes:
Beim Ausführen einer Transaktions mit der Jet-Datenbank schreibt den Informationsspeicher und Verzeichnisspeicher die Transaktion in einer Transaktionsprotokolldatei (in "Mdbdata" oder Dsadata.log). Die Transaktion ist dann verpflichtet, die Jet-Datenbank. Die Jet-Engine während dieses Vorgangs berechnet die Seite Prüfsummenwert geschrieben werden, werden im Seitenkopf und dann angefordert wird, dass das Dateisystem auf dem Datenträger die 4-KB-Seite der Daten in die Datenbank geschrieben. Kurz gesagt, das Dateisystem verwendet dieser Aufruf und verwendet Windows NT-Systemdienste zum Weiterleiten dieser Anforderung an den entsprechenden Hardwaregerätetreiber, tatsächlich den Schreibvorgang auszuführen. Treiber für das Hardwaregerät gibt diese Informationen in das Dateisystem, das dann an die Jet-Engine zurückgegeben. Wenn der Aufruf erfolgreich ist, wird die Jet fortgesetzt.
Fehlerhafte Hardware oder Hardwaregerätetreiber zurückliefern Erfolg für Anrufe an sie, bevor sie tatsächlich den physischen Betrieb durchgeführt. Wenn die tatsächliche physische Operation durchgeführt wird, jedoch ein Fehler auftritt und die Daten werden nicht wie erwartet erfolgreich geschrieben.
In bestimmten Datenbankvorgänge wie z. B., aber nicht beschränkt auf Online Backup, backup-Routine wird aufgerufen, das Betriebssystem, um eine 4-KB-Seite mit Daten aus der Datenbank auf dem Datenträger gelesen und auf Band zu schreiben. Vor dem Ausführen eines Commits für die Daten von der Betriebssystem-Aufruf auf dem Band zurückgegeben, vergleicht der Onlinesicherung des Prüfsummenwert im Seitenkopf (aufgezeichnet, wann diese Seite geschrieben wurde auf der Festplatte) aufrufen, die von den LESEVORGANG zurückgegeben wird. Wenn die Prüfsummenwerte nicht übereinstimmen, wird das JET-Datenbankmodul erkennt dies und gibt-1018 (JET_errReadVerifyFailure) zurück.
Gibt es den bei dir die beiden Log Files noch ?? ("Mdbdata" , Dsadata.log) ?
Wenn nicht hast du die möglichkeit diese aus einer Sicherung wiederherzustellen ??
PS: Quelle http://support.microsoft.com/kb/151789/de
LG Andy
Hallo,
wenn Du die Datenbank auf einem anderen Rechner "repariert hast" wo es keine Protokolldateien gab die hätten verwendet werden können, dann ist die Datenbankdatei repariert, aber mails die noch nicht in die Datenbank geschrieben wurden sind futsch.
Wenn Die "reparierte Date nun schon im Einsatz war und da auch Mails angekommen sind würden Aktionen mit der alten Datei (also falls die noch da ist) dazu führen das alle neune Mails weg sind.
Die erste Frage ist immer, ist das Dateisystem in Ordnung und sind die Festplatten in Ordnung oder haben da welche defekte Sektoren?
Vermutlich gibt es noch Logfiles die zur alten Datenbankdatei gehören und das ist ein Problem, weil die mit der neuen Version nix anfangen können, aber Exchange weiß ja nicht das Du fremd gegangen bist.
Gruß
Chonta
wenn Du die Datenbank auf einem anderen Rechner "repariert hast" wo es keine Protokolldateien gab die hätten verwendet werden können, dann ist die Datenbankdatei repariert, aber mails die noch nicht in die Datenbank geschrieben wurden sind futsch.
Wenn Die "reparierte Date nun schon im Einsatz war und da auch Mails angekommen sind würden Aktionen mit der alten Datei (also falls die noch da ist) dazu führen das alle neune Mails weg sind.
Die erste Frage ist immer, ist das Dateisystem in Ordnung und sind die Festplatten in Ordnung oder haben da welche defekte Sektoren?
Vermutlich gibt es noch Logfiles die zur alten Datenbankdatei gehören und das ist ein Problem, weil die mit der neuen Version nix anfangen können, aber Exchange weiß ja nicht das Du fremd gegangen bist.
Gruß
Chonta
Danke vielmals für die neuen Antworten:
Ich hatte bevor ich die Datenbank auf den "temporären Server" geschoben hatte, den Infromationsspeicher angehalten und die Mailzustellung beendet. In der zwischenseit wurde also nicht versucht etwas neues hinzuzufügen.
Nach der Rep. habe ich die .edb Datei wieder an die Originale Stelle kopiert und die alte vom System genommen ( aber noch auf einem NAS zur Not abgelegt ) und den Informationsspeicher wieder gestartet. Ab dem Moment lief alles wieder normal.
Ein Mdbdata oder dsadata.log konnte ich auf dem Server leider nicht finden. Wo sollten den denn überlicherweise liegen?
Eventuell hier? C:\Program Files\Microsoft\Exchange Server\V14\Logging
Die Platten im Raidverbund zeigen keinerlei Fehler und sowohl auf dem Hypver-V als auch auf innherlab der VM verläuft das chkdsk fehlerfrei.
Muss ich eventuell nur ein paar andere Datein wie z.B. ein paar der .log oder .chk Dateien im C:\Program Files\Microsoft\Exchange Server\V14 verzeichnis löschen damit der Exchange diese eventuell von neuem beginnt zu schreiben und damit keine Fehler mehr von vorher mehr übernimmt?
Ich glaube es gab da mal was mit der Umlaufprotokolierung?? Dieses ist für die Entsprechende Datenbank bei mir auf Aktiv gestellt.
Könnte es helfen, wenn ich diese mal deaktiveren und den Informationsspeicher mal neustarten und im Anschluss wieder aktivieren würde?
Danke!!
Ich hatte bevor ich die Datenbank auf den "temporären Server" geschoben hatte, den Infromationsspeicher angehalten und die Mailzustellung beendet. In der zwischenseit wurde also nicht versucht etwas neues hinzuzufügen.
Nach der Rep. habe ich die .edb Datei wieder an die Originale Stelle kopiert und die alte vom System genommen ( aber noch auf einem NAS zur Not abgelegt ) und den Informationsspeicher wieder gestartet. Ab dem Moment lief alles wieder normal.
Ein Mdbdata oder dsadata.log konnte ich auf dem Server leider nicht finden. Wo sollten den denn überlicherweise liegen?
Eventuell hier? C:\Program Files\Microsoft\Exchange Server\V14\Logging
Die Platten im Raidverbund zeigen keinerlei Fehler und sowohl auf dem Hypver-V als auch auf innherlab der VM verläuft das chkdsk fehlerfrei.
Muss ich eventuell nur ein paar andere Datein wie z.B. ein paar der .log oder .chk Dateien im C:\Program Files\Microsoft\Exchange Server\V14 verzeichnis löschen damit der Exchange diese eventuell von neuem beginnt zu schreiben und damit keine Fehler mehr von vorher mehr übernimmt?
Ich glaube es gab da mal was mit der Umlaufprotokolierung?? Dieses ist für die Entsprechende Datenbank bei mir auf Aktiv gestellt.
Könnte es helfen, wenn ich diese mal deaktiveren und den Informationsspeicher mal neustarten und im Anschluss wieder aktivieren würde?
Danke!!
Hi
Hier noch ein Link der dir erklärt was für dateien da gemeint sind.
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exc ...
Ich vermute das du in diesen verzeichnissen Exchsrvr\Mdbdata und Exchsrvr\Dsadata eine Log datei hast die beschädigt ist.
In dem von mir oben geposteten Link wird auch beschrieben wie du diese Dateien richtig entfernst.
Wenn du dann erneut eine Sicherung ausführst sollte diese nicht mehr mit diesem Fehler fehlschlagen.
LG Andy
Hier noch ein Link der dir erklärt was für dateien da gemeint sind.
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exc ...
Ich vermute das du in diesen verzeichnissen Exchsrvr\Mdbdata und Exchsrvr\Dsadata eine Log datei hast die beschädigt ist.
In dem von mir oben geposteten Link wird auch beschrieben wie du diese Dateien richtig entfernst.
Wenn du dann erneut eine Sicherung ausführst sollte diese nicht mehr mit diesem Fehler fehlschlagen.
LG Andy
Hallo Ausserwoeger.
Danke für den Link und die Infos... das scheint für eine ältere Exchange Variante zu sein. Ich glaube 2003. Ich kann nämlich weder mdbdata noch dsadata verzeichnisse finden.
Ich habe wie im Artikel beschrieben mal nach edb*.log Dateien gesucht und dabei auch ein paaar gefunden:
Aber in folgendem Verzeichnis: C:\Windows\System32\CertLog. Dort gibt es knapp 400 Stück davon.
Um sicher zu gehen, dass ich nicht nur auf diesen Problemserver diese Verzeichnisse nicht finden kann habe ich mal auf einem anderen SBS 2011 geschaut bei dem alles normal läuft. Auch dort kein mdbdat aoder dsadata....
Somit ist die Anleitung von Microsoft in diesem fall warscheinlich nicht 1 zu 1 auf meinen Fall anwendbar....
Weiß jemand wie die gesuchten Datein unter einem Exchange 2010 heißen müssten und wo sie liegen könnten?
Oder sollte ich die edb Dateien in C:\Windows\System32\CertLog trotzdem löschen und sonst wie nach Anleitung in dem Link verfahren?
Danke und ein schönes WE.
Lucas
Danke für den Link und die Infos... das scheint für eine ältere Exchange Variante zu sein. Ich glaube 2003. Ich kann nämlich weder mdbdata noch dsadata verzeichnisse finden.
Ich habe wie im Artikel beschrieben mal nach edb*.log Dateien gesucht und dabei auch ein paaar gefunden:
Aber in folgendem Verzeichnis: C:\Windows\System32\CertLog. Dort gibt es knapp 400 Stück davon.
Um sicher zu gehen, dass ich nicht nur auf diesen Problemserver diese Verzeichnisse nicht finden kann habe ich mal auf einem anderen SBS 2011 geschaut bei dem alles normal läuft. Auch dort kein mdbdat aoder dsadata....
Somit ist die Anleitung von Microsoft in diesem fall warscheinlich nicht 1 zu 1 auf meinen Fall anwendbar....
Weiß jemand wie die gesuchten Datein unter einem Exchange 2010 heißen müssten und wo sie liegen könnten?
Oder sollte ich die edb Dateien in C:\Windows\System32\CertLog trotzdem löschen und sonst wie nach Anleitung in dem Link verfahren?
Danke und ein schönes WE.
Lucas
Zitat von @Lucas112:
Weiß jemand wie die gesuchten Datein unter einem Exchange 2010 heißen müssten und wo sie liegen könnten?
Oder sollte ich die edb Dateien in C:\Windows\System32\CertLog trotzdem löschen und sonst wie nach Anleitung in dem Link
verfahren?
Weiß jemand wie die gesuchten Datein unter einem Exchange 2010 heißen müssten und wo sie liegen könnten?
Oder sollte ich die edb Dateien in C:\Windows\System32\CertLog trotzdem löschen und sonst wie nach Anleitung in dem Link
verfahren?
Hi
Kann ich leider nicht sagen. Ich würde in dem Fall ein Image des gesamten Systems machen und den Ordner mit den Logs umbenennen, ein testlauf würde dann zeigen ob das System funktioniert.
Wenn du das Life System nicht angreifen möchtest kannst du auch ein Image auf einem anderen Server wiederherstellen und mit dem testen.
LG Andy
