none
Exchange 2010 Fehler in Mailbox Database RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    wir haben seit 28.04. auf einem Kundenserver (SBS 2011) das Problem, dass in unregelmäßigen Abständen täglich 1-2x folgende Meldungen im Eventlog zu finden sind:

    MSExchangeIS Mailbox Store Error-ID 1242:

    Fehler bei dem Versuch, eine Ansicht zu aktualisieren.
    Datenbank: Mailbox Database
    Ordner: [MBX:Stefan S][0315]
    Nachrichtenheader-ID: 2699-2BD9E
    Ordner-ID: 2-9843806B
    Ansichts-ID: 2699-207993
    Ansichtsname: 2-9843806B *A-D+N67fe
    Dokument-ID: 2274360
    Wasserzeichen für zurückgestellte Ansichtsupdate: 588583
    Fehlercode: 0xfffffba1

    und: ExchangeStoreDB Error-ID: 233:

    Für die Datenbankkopie 'Mailbox Database' auf diesem Server ist ein Fehler aufgetreten. Überprüfen Sie das Ereignisprotokoll für 'ExchangeStoreDb'- oder 'MSExchangeRepl'-Ereignisse, um weitere Informationen zu erhalten.

    Alle paar Tage tauchen außerdem folgende 2 Meldungen auf:

    ESE Error-ID 530:

    Information Store (2312) Mailbox Database: Fehler bei der Überprüfung der Datenbankseite, die aus der Datei "C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database\Mailbox Database.edb" mit dem Offset 6415876096 (0x000000017e6a8000)  (Datenbankseite 195796 (0x2FCD4)) mit 32768 (0x00008000) Bytes gelesen wurde. Ursache: keine Übereinstimmung des Zeitstempels für verlorene Leerungserkennung. Der Lesevorgang wird mit dem Fehler '-1119 (0xfffffba1)' beendet. Wenn dieser Zustand andauert, stellen Sie die Datenbank mithilfe einer früheren Sicherung wieder her. Der Grund für dieses Problem ist wahrscheinlich defekte Hardware. Wenden Sie sich an den Hardwarehersteller, um Hilfe bei der Problemdiagnose zu erhalten.

    und: ExchangeStoreDB Error-ID: 234

    Für die Kopie von Datenbank 'Mailbox Database' ist auf diesem Server ein schwerwiegender E/A-Fehler aufgetreten, der sich möglicherweise auf alle Kopien der Datenbank ausgewirkt hat. Überprüfen Sie das Ereignisprotokoll auf dem Server hinsichtlich der 'ExchangeStoreDb'-  und 'MSExchangeRepl'-Ereignisse, um Informationen zum Fehler zu erhalten. Alle Daten sollten umgehend aus dieser Datenbank in eine neue Datenbank verschoben werden.

    Alle Meldungen passieren immer zu unterschiedlichen Zeiten, ich kann kein Muster erkennen. Die Windows Server Datensicherung läuft ohne Fehler im Eventlog durch.

    Kann es sein, dass hier nur in der Mailbox des Users, der in der Fehlermeldung genannt ist, eine korrupte Mail drin ist?

    Was sollte ich am besten tun? Das erstmal ausführen?: New-MailboxRepairRequest -Mailbox "Stefan S" -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview

    Danke für die Hilfe und viele Grüße


    • Bearbeitet InfoCN Dienstag, 10. Mai 2016 09:02
    Dienstag, 10. Mai 2016 08:53
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden
    zeigt also auch keine fehler. heißt das nicht, dass die Datenbank ok ist?

    sollte ich trotzdem die user in eine neue db verschieben?
    es gab seit dem 12.05. auch keine db fehler im eventlog mehr.

    Jein. Die Prüfungen zeigen, dass die aktuelle EDB-Datei keine Fehler hat. Sie kann aber mal welche gehabt haben, die ESE ist mittlerweile sehr stabil und korrigiert gewisse Fehler von alleine.

    Die Fehlermeldungen oben können auch ein temporäres Problem mti der Hardware anzeigen. Neben einer defekten Platte könnte das z.B. auch ein defekter Controler oder ein fehlerhafter Treiber sein mit einem Problem, dass nur unter gewissen Umständen auftritt.

    Exchange kann halt schlecht die echte Ursache ermitteln und sieht nur die Symptome.

    Wir im Forum haben das gleiche Problem: Eine echte Ursachenforschung kannst nur Du vor Ort machen.

    Ich würde bei der aktuellen Lage:

     - wenig Fehlermeldungen
     - keine neuen Fehlermeldungen
     - alle offensichtlichen Tests ok

    kritisch das Backup prüfen (falls ich es doch brauche) und sonst aber außer intensiver Beobachtung noch nichts weiter machen.

    Aber sobald der nächste "Hicks" kommt, würde ich umgehend die hier beschriebenen Schritte (neue DB; PF verschieben) einleiten.

    Es kann ja auch die Unkündigung eines drohenden Ausfalls gewesen sein.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort vorgeschlagen Evgenij Smirnov Mittwoch, 18. Mai 2016 14:33
    • Als Antwort markiert InfoCN Donnerstag, 19. Mai 2016 15:09
    Mittwoch, 18. Mai 2016 14:26
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    der erste Fehler ist m.E. unkritisch. Lass einen MailboxRepairRequest laufen - der wird es vermutlich nicht richten, wird aber auch nichts kaputt machen. Ist es immer dieselbe Mailbox, die betroffen ist? Versuche mal, sie in eine andere Datenbank zu schieben oder als PST zu exportieren (mit Exchange, nicht aus Outlook natürlich).

    Aufgrund der anderen Fehler würde ich langsam damit anfangen, Plattenplatz bereitzustellen und eine neue Datenbank anzulegen, möglichst auf anderen physischen Spindeln als die jetzige (ich weiß, bei SBS-Kunden ist das alles etwas schwieriger, aber vielleicht geht's ja irgendwie...). Verschieb die Mailboxen in die neue DB und mach die alte platt, dann meinetwegen alles wieder zurück. Solche I/O-Fehler können sich aber eines Tages böse rächen, wenn man sie ignoriert.

    Sachen, die im Vorfeld noch zu prüfen sind:

    - RAM-Auslastung

    - Generell Fehler im Platten-Subsystem und dessen Queue Length, speziell wenn die obigen Fehler auftreten (kannst mit PerfMon mitschneiden)

    - ESE-Hintergrundwartung sollte sich nicht mit Backup überschneiden

    Gruß

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de

    my personal blog (mostly German) -> http://it-pro-berlin.de

    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de

    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    Dienstag, 10. Mai 2016 10:37
    |
  • Question
    Anmelden
    0
    Anmelden

    ok dann mache ich erstmal einen mailboxrepair und gucke was dabei rauskommt. ist immer der selbe user der bemängelt wird.

    der Server hat 2 raid1 und zum glück reichlich platz, ist aber leider nicht der schnellste, die Queue length geht ab und zu (vor allem während nächtlicher backups) auch gerne mal über 4.

    ram Auslastung ist bei allen SBS immer am oberen Limit, es sind 16gb drin, aber wir haben auch Server wo 32 drin sind und da ist es genau so (store.exe nimmt sich alles was geht).

    ist das arg kompliziert die Mailboxen in eine neue db zu verschieben? gibt's oft Probleme? hab ich noch nie gemacht. sind auch ein paar user jenseits der 10gb im Postfach dabei...

    danke schonmal!


    • Bearbeitet InfoCN Dienstag, 10. Mai 2016 13:24
    Dienstag, 10. Mai 2016 13:23
    |
  • Question
    Anmelden
    1
    Anmelden

    Nö, Mailboxen verschieben ist normalerweise recht einfach:

    Get-Mailbox <user> | New-MoveRequest -TargetDatabase <DB_NEU>

    und dann mit Get-MoveRequest | Get-MoveRequestStatistics den Fortschritt verfolgen.

    Knallt es dabei (die ursprüngliche Instanz der Mailbox bleibt dabei die ganze Zeit aktiv), kann man mit

    Get-MoveRequest | Get-MoveRequestStatistics -IncludeReport

    einen ausführlichen Bericht sehen. Den Rest bitte im TechNet nachlesen ;-)

    Gruß

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de

    my personal blog (mostly German) -> http://it-pro-berlin.de

    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de

    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Dienstag, 10. Mai 2016 13:39
    |
  • Question
    Anmelden
    0
    Anmelden

    sind auch ein paar user jenseits der 10gb im Postfach dabei...


    Da würde ich knallhart mal eine Quota einführen. eMail ist keine Dateiablage. 2GB pro User sollten dicke reichen, eigentlich schon 1GB. Wenn jemand ein Problem damit hat: Angebot für stärkeren Server kommen lassen, dann ist das Problem meistens schon keines mehr.

    MCTS (70-642), MCP Please click the "Mark as Answer" or "Vote As Helpful button" if a post solves your problem or is helpful! Bitte klicke auf "Als Antwort vorschlagen" oder "Als hilfreich bewerten", wenn mein Beitrag Dein Problem löst oder hilfreich ist.

    Dienstag, 10. Mai 2016 14:30
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin Markus,

    ->Zitat: 2GB pro User sollten dicke reichen, eigentlich schon 1GB

    was hat das mit dem Problem von InfoCN zu tun?

    Und bei den aktuellen Preisen für Festplatten würde ich noch nicht einmal drüber nachdenken, den Usern weniger als 30GB in der primären zu erlauben, das sind übrigens per Default 10 GB.

    So kleine Quotas sind heute kaum noch vorzufinden, noch nicht einmal in Behörden oder richtig großen Umgebungen (größer 10k Seats)

    O365 / Exo (Exchange Online) darf die primäre Mailbox ohne Aufpreis 75GB sein.

    @IncoCN - auch beim SBS kannst du einfach eine weitere DB anlegen, ich würde diese auf dem 2ten RAID-1 Volumen erzeugen.
    Geht entweder über die GUI oder die Shell, ebenso wie das verschieben, hat Evgenij ja schon beschrieben.
    Anpassen des Backups nicht vergessen, sonst laufen auch dort die Logs voll.

    ;)

    Nachtrag: bitte mal die GENAUE Version vom Exchange posten:
    http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern

    Gruß Norbert


    Dienstag, 10. Mai 2016 16:54
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Microsoft Exchange Server 2010 SP1 RU8 14.01.0438.000

    hab mich bisher davor gedrückt sp3 zu installieren, da es ja doch etwas aufwand ist (Server offline nehmen, datensicherung machen, updaten, testen, geht halt nur am wochenende) und wir ziemlich viele SBS draußen stehen haben...

    bei den postfachgrößen sehe ich auch kein Problem. ab 10gb kann man mal über Archivierung nachdenken, aber der kunde ist auch gerne mal faul und die großen Mailboxen waren auch ein verkaufsargument ;)

    der mailboxrepair des users bricht immer ab mit:

    MSExchangeIS Mailbox Store Error-ID 10049:
    Fehler -1119 bei Onlinesystemdiagnose für Anforderung ce68c8d7-98ec-4cdf-a001-7ca7e0918768.

    TechNet zu 10049:
    Die Postfach- oder Datenbankreparaturanforderung ist fehlgeschlagen, weil Exchange ein Problem mit der Datenbank festgestellt hat oder weil gerade ein anderer Task für die Datenbank ausgeführt wird. Führen Sie zum Beheben dieses Problems die folgenden Schritte aus:
    1.Führen Sie den Befehl erneut aus.
    2.Falls das Problem weiterhin besteht, führen Sie Eseutil (Exchange Server Database Utilities) aus, um das Laufwerk auf Fehler zu überprüfen.
    3.Führen Sie Microsoft Exchange Troubleshooting Assistant v1.1 (ExTRA) (möglicherweise in englischer Sprache) mit der Eigenschaft tagISINTEG aus. Speichern Sie die Informationen des ExTRA-Ablaufverfolgungsprotokolls, und wenden Sie sich dann an Microsoft Support Services.

    sollte ich erstmal ein mailboxrepair gegen die Datenbank versuchen? beim verschieben der Postfächer wird es wohl ziemlich sicher zu fehlern kommen. eseutil /p sollte wohl als letztes versucht werden, da es destruktiv ist?

    Mittwoch, 11. Mai 2016 07:36
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    Repair gegen die DB wird nichts bringen.

    Versuch mal, die Mailbox in eine PST zu exportieren mit -AcceptLargeDataLoss und -BadItemLimit Unlimited . Das ist zumindest erst mal nicht mit Downtime für den User verbunden.

    Schau, wieviele Items und wo knallen, vielleicht ist es ja akzeptabel. Dann kannst Du mit demselben Verlust auch die Mailbox verschieben...

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de

    my personal blog (mostly German) -> http://it-pro-berlin.de

    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de

    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Mittwoch, 11. Mai 2016 07:42
    |
  • Question
    Anmelden
    1
    Anmelden

    Microsoft Exchange Server 2010 SP1 RU8 14.01.0438.000

    hab mich bisher davor gedrückt sp3 zu installieren, da es ja doch etwas aufwand ist (Server offline nehmen, datensicherung machen, updaten, testen, geht halt nur am wochenende) und wir ziemlich viele SBS draußen stehen haben...

    Das ist jetzt nicht Dein Ernst, oder?

    Du bist DIENSTLEISTER und das da sind Deine KUNDEN!

    Was würdest Du denken, wenn Dein Arzt eine Herzuntersuchung nicht macht, weil es ihm "zu aufwendig ist" oder die KFZ-Werkstatt den seit Jahren überfälligen Ölwechsel nicht durchführt - Auto fährt ja und der Aufwand ist hoch!

    So etwas musst Du einpreisen, das sind absolut notwendige Arbeiten. Was sagt der Kunden denn, wenn es crasht und dann herauskommt, dass sein Betrieb steht (oder schlimmer: Pleite geht!), weil Du mit notwendiger Wartung geschlampt hast?

    Auch wenn ich jahrelang gutes Geld damit verdient habe, hinter anderen Dienstleistern aufzuräumen und das Chaos zu beseitigen, ein wenig fremdschämen war auch dabei.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Mittwoch, 11. Mai 2016 08:02
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin Markus,

    ->Zitat: 2GB pro User sollten dicke reichen, eigentlich schon 1GB

    was hat das mit dem Problem von InfoCN zu tun?

    Und bei den aktuellen Preisen für Festplatten würde ich noch nicht einmal drüber nachdenken, den Usern weniger als 30GB in der primären zu erlauben, das sind übrigens per Default 10 GB.

    So kleine Quotas sind heute kaum noch vorzufinden, noch nicht einmal in Behörden oder richtig großen Umgebungen (größer 10k Seats)

    O365 / Exo (Exchange Online) darf die primäre Mailbox ohne Aufpreis 75GB sein.

    @IncoCN - auch beim SBS kannst du einfach eine weitere DB anlegen, ich würde diese auf dem 2ten RAID-1 Volumen erzeugen.
    Geht entweder über die GUI oder die Shell, ebenso wie das verschieben, hat Evgenij ja schon beschrieben.
    Anpassen des Backups nicht vergessen, sonst laufen auch dort die Logs voll.

    ;)

    Nachtrag: bitte mal die GENAUE Version vom Exchange posten:
    http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern

    Gruß Norbert


    Hallo Norbert,

    das stimmt alles soweit, aber wir reden von einer SBS-Installation. Also mindestens AD, Exchange und SharePoint auf einem Server. In der Praxis sind das dann gerne auch mal Dual-Kern Maschinen mit 8 oder 16 GB RAM und 2 SATA-Festplatten im RAID 1. Die Dienste dürfen sich dann um den RAM und die Festplatte (Space + IO) prügeln. Zum Glück ist das Ganze sowieso auf 75 User limitiert.
    In solchen Umgebungen, wie sie oft bei KMU (eher K als M) vorzufinden sind, ergibt für mich ein Quota in der genannten Größe definitv einen Sinn. Außerdem sollte die SQL-Instanz von SharePoint noch massiv im RAM begrenzt werden, sofern SP nicht genutzt wird.
    Bei Behörden habe ich demletzt wieder ein Beispiel erhalten, wo auch mir die Haare zu Berg standen: Quota 5 MB (kein Tippfehler, ich meine Megabyte). Extra nachgefragt, ob es nicht pro eMail ist. Antwort: Nein, tatsächlich für das gesamte Postfach.

    Gruß, Markus

    MCTS (70-642), MCP Please click the "Mark as Answer" or "Vote As Helpful button" if a post solves your problem or is helpful! Bitte klicke auf "Als Antwort vorschlagen" oder "Als hilfreich bewerten", wenn mein Beitrag Dein Problem löst oder hilfreich ist.

    Mittwoch, 11. Mai 2016 09:03
    |
  • Question
    Anmelden
    1
    Anmelden

    Ich denke, man kann das mit den Postfachgrößen nicht verallgemeinern und muss sowohl die organisatorischen, als auch die technischen Belange betrachten.

    Organisatorisch kann es Gründe für und gegen große Postfächer geben. Gibt es eine Archivierung, sollten die Daten dort landen. Gibt es wie bei mir keine, ist mit die Aufbewahrung im Postfach deutlich lieber, als wenn die Leute das in PST-Dateien speichern müssen.

    Technisch ist Exchange 2010 für Postfachgrößen von 10 GB optimiert, supported aber "unendlich" große Postfächer (technisch bedingt wären das max. 2 TB). Exchange 2013 hat mit 100 GB hier einen deutlichen Schub bekommen.

    Wir geben bei uns bis max. 30 GB und aus Erfahrung kann ich sagen, dass es ab dieser Größe auch langsam hakelig wird und sich die kleinen Probleme häufen. Bei Vollzugriff nehmen wir z.B. schon deutlich früher Automapping raus.

    Also ganz pauschal gesagt: Es gibt keine pauschal Antwort - kommt auf den Einzellfall an.

    @Problem: Würde ich wie schon mehrfach angedeutet, mit einer neuen Datenbank auf neuen Platten angehen. Die Fehlermeldungen deuten auf Low-Level-Fehler auf Datenbank-Engine Ebene hin und die sind zu 99,9% bedingt durch Hardwarefehler.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Mittwoch, 11. Mai 2016 09:14
    |
  • Question
    Anmelden
    0
    Anmelden

    also der pst Export des betroffenen users wurde augenscheinlich erfolgreich abgeschlossen (Status completed), jedenfalls sehe ich nix im eventlog und "get-mailboxexportrequest | get-mailboxexportrequeststatistics -includereport" zeigt mir auch nicht mehr an als "get-mailboxexportrequest | get-mailboxexportrequeststatistics" oder kann ich woanders noch mehr sehen?

    hardwarefehler kann man natürlich nie zu 100% ausschließen, aber ich wüsste nicht wo der liegen sollte. es ist schon ein ausgewachsener Server mit entsprechender Hardware und USV und der Server läuft sonst auch sehr gut und stabil. der RAID Controller macht auch regelmäßig ein patrol read und zeigt keine fehler.

    ich werde dann mal eine neue Datenbank erstellen und das lange Wochenende für die umzüge nutzen.

    bezüglich des SP3 gelobe ich Besserung, bin gerade dabei eine angebotsvorlage für alle kunden zu verfassen ;)

    gibt's bei dem update erfahrungsgemäß öfter Probleme?





    • Bearbeitet InfoCN Mittwoch, 11. Mai 2016 13:34
    Mittwoch, 11. Mai 2016 13:30
    |
  • Question
    Anmelden
    0
    Anmelden

    Du solltest Get-MailboxExportRequestStatistics -IncludeReport | fl ausführen, damit Du auch siehst, wieviele Bad Items es gab und so und auch den Report lesen kannst.

    Aber wenn der PST Export klappt, stehen die Chancen recht gut, dass es auch mit einem Move Request funktioniert :-)

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de

    my personal blog (mostly German) -> http://it-pro-berlin.de

    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de

    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Mittwoch, 11. Mai 2016 14:12
    |
  • Question
    Anmelden
    0
    Anmelden

    EstimatedTransferSize         : 25.16 GB (27,012,066,861 bytes)
    EstimatedTransferItemCount    : 56432
    BytesTransferred              : 25.62 GB (27,505,350,278 bytes)
    ItemsTransferred              : 56432
    PercentComplete               : 100

    hat ganz schön gedauert das durch zu lesen, 278 ordner und jeder erzeugt einen längeren eintrag :)
    es wurden 3 Elemente in 3 verschiedenen Ordnern übersprungen, aber keine fehler angezeigt.

    der Server wurde gestern wegen Windows updates rebootet, ich habe spaßeshalber nochmal einen mailboxrepair des users gemacht und dann ist dieser ohne Probleme durchgelaufen... seitdem gab es auch keine Fehlermeldungen der Datenbank mehr im eventlog.

    sollte ich nochmal einen mailboxrepair über die Datenbank laufen lassen? evtl. kann ich mir das verschieben in eine neue db sparen?

    Donnerstag, 12. Mai 2016 08:02
    |
  • Question
    Anmelden
    0
    Anmelden
    sollte ich nochmal einen mailboxrepair über die Datenbank laufen lassen? evtl. kann ich mir das verschieben in eine neue db sparen?

    Mailbox-Repair und Move sind quasi technische die gleichen Reparaturen. Sie sind High-Level Werkzeuge, beeinflussen also die Integrität der Daten für die Anwendung Exchange/Outlook.

    Deine Fehlermeldungen oben sind aber Low-Level Fehler auf Datenbank Ebene.

    Das Reparatur-Werkzeug hierfür wäre "eseutil.exe". Hierfür muss die Datenbank offline geschaltet werden.

    Ich würde die DB offline nehmen (wenn man weiß wie, kann man das auch Online via VSS machen), dann eine Kopie der edb-Datei ziehen und mit eseut.exe /p DATEINAME eine Test-Reparatur durchführen. Alles weitere siehst Du dann.

    Bitte beachte aber folgendes: Du offizielle Exchange Support-Policy ist, dass die Daten aus einer reparierten DB verschoben werden muss.

    Siehe auch hier:https://blogs.technet.microsoft.com/exchange/2015/05/01/new-support-policy-for-repaired-exchange-databases/

    Oder anders ausgedrückt: Sie die Datei auf Datenbank-Ebene einmal defekt, trauen die Exchange-Leute der Datenbank nicht mehr und erwarten, dass man eine neue nimmt.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 12. Mai 2016 08:22
    |
  • Question
    Anmelden
    0
    Anmelden

    habe die edb offline genommen, auf eine größere platte kopiert und eseutil darauf angewendet.
    eseutil /mh zeigt clean shutdown und bisher keine repairversuche.
    habe dann eseutil /k gemacht mit folgendem Ergebnis:

    6627618 pages seen
    0 bad checksums
    0 correctable checksums
    26171 uninitialized pages
    0 wrong page numbers

    sieht erstmal gut aus, ich weiß aber nicht genau was uninitialized pages sind.
    habe dann noch ein eseutil /p gemacht:

    Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
    Version 14.01
    Copyright (C) Microsoft Corporation. All Rights Reserved.

    Initiating REPAIR mode...
            Database: .\Mailbox Database.edb
      Temp. Database: TEMPREPAIR18892.EDB


    Checking database integrity.


                         Scanning Status (% complete)

              0    10   20   30   40   50   60   70   80   90  100
              |----|----|----|----|----|----|----|----|----|----|
              ...................................................

    Integrity check successful.

    Operation completed successfully in 2214.481 seconds.

    zeigt also auch keine fehler. heißt das nicht, dass die Datenbank ok ist?
    sollte ich trotzdem die user in eine neue db verschieben?
    es gab seit dem 12.05. auch keine db fehler im eventlog mehr.

    • Bearbeitet InfoCN Mittwoch, 18. Mai 2016 14:17
    Mittwoch, 18. Mai 2016 14:15
    |
  • Question
    Anmelden
    1
    Anmelden
    zeigt also auch keine fehler. heißt das nicht, dass die Datenbank ok ist?

    sollte ich trotzdem die user in eine neue db verschieben?
    es gab seit dem 12.05. auch keine db fehler im eventlog mehr.

    Jein. Die Prüfungen zeigen, dass die aktuelle EDB-Datei keine Fehler hat. Sie kann aber mal welche gehabt haben, die ESE ist mittlerweile sehr stabil und korrigiert gewisse Fehler von alleine.

    Die Fehlermeldungen oben können auch ein temporäres Problem mti der Hardware anzeigen. Neben einer defekten Platte könnte das z.B. auch ein defekter Controler oder ein fehlerhafter Treiber sein mit einem Problem, dass nur unter gewissen Umständen auftritt.

    Exchange kann halt schlecht die echte Ursache ermitteln und sieht nur die Symptome.

    Wir im Forum haben das gleiche Problem: Eine echte Ursachenforschung kannst nur Du vor Ort machen.

    Ich würde bei der aktuellen Lage:

     - wenig Fehlermeldungen
     - keine neuen Fehlermeldungen
     - alle offensichtlichen Tests ok

    kritisch das Backup prüfen (falls ich es doch brauche) und sonst aber außer intensiver Beobachtung noch nichts weiter machen.

    Aber sobald der nächste "Hicks" kommt, würde ich umgehend die hier beschriebenen Schritte (neue DB; PF verschieben) einleiten.

    Es kann ja auch die Unkündigung eines drohenden Ausfalls gewesen sein.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort vorgeschlagen Evgenij Smirnov Mittwoch, 18. Mai 2016 14:33
    • Als Antwort markiert InfoCN Donnerstag, 19. Mai 2016 15:09
    Mittwoch, 18. Mai 2016 14:26
    |
  • Question
    Anmelden
    0
    Anmelden

    So werde ich es machen.

    Vielen Dank für die Hilfe.

    Donnerstag, 19. Mai 2016 15:09
    |