none
Exchange 2007 ESE 474/1018 RRS feed

  • Frage

  • Hallo,

    auf einem Exchange 2007 tritt folgender Fehler auf, was festgestellt wurde,
    weil die Sicherung des Exchange sich weigerte zu arbeiten:

    Ereignisquelle:    ESE
    Ereigniskennung:    474
    Fehler "-1018 (0xfffffc06)"

    Der Fehler ist "nur" im Eventlog, der Exchange arbeitet derzeit noch
    problemlos.

    Die Ursache vermute ich bei einem Hauptspeicherproblem, das zeitlich mit
    ersten Auftreten des Fehlers zusammenfällt. Diese Ursache ist bereits
    behoben. Meine Frage:

    Ich hatte vor, gemäß Methode 1 aus diesem Vorschlag

    http://technet.microsoft.com/de-de/library/bb397387(v=exchg.80).aspx

    übers Wochenende eine neue DB anzulegen und die Postfächer dorthin zu
    verschieben. Das klappt jetzt aber nicht mehr, da der Server keinen HD-Platz
    mehr hat und ich heute am Freitag Nachmittag keine neue HD mehr bekommen
    habe.

    Kann ich es riskieren, noch bis nächstes WE zu warten, oder ist schnellstes
    Handeln angesagt?

    Die Werte im Fehler sind immer exakt die gleichen, es scheint sich da also
    nix aufzuschaukeln:

    Fehler beim Überprüfen der aus Datei "D:\Exchange Server\Mailbox\First
    Storage Group\Mailbox Database.edb" bei Offset 274457698304
    (0x0000003fe6f42000) (Datenbankseite 33503136 (0x1FF37A0)) für 8192
    (0x00002000) Byte gelesenen Datenbankseite aufgrund einer Inkonsistenz der
    Seitenprüfsumme. Die erwartete Prüfsumme lautet 8388364919437223013
    (0x7469757365676465), die tatsächliche Prüfsumme ist 143894874943537006
    (0x01ff37a05a023f6e).

    Christoph Sternberg */\

    Freitag, 13. April 2012 15:28

Antworten

  • Hi Christoph Sternberg,

    Christoph Schmeer meinte:

    Ich an Deiner Stelle würde auf Nummer Sicher gehen und das *nicht*auf die lange Bank schieben

    Ja, hast sicher Recht, ich werde nächste Woche mal 'ne Nachtschicht
    einschieben und die User drauf vorbereiten, dass es am nächsten Tag ggfls.
    noch nicht läuft (die DB hat eine physische Größe von >300 GB und eine
    logische von >270).

    Was hältst Du grundsätzlich von dem Vorgehen, die Postfächer in eine neue DB
    zu schieben? Eine Alternative wäre ja evtl., mit eseutil eine Reparatur
    zuprobieren.

    wenn du irgendwo 600GB freien Speicherplatz hast kannst du es ja parallel versuchen bis die Platten da sind und dir das Ergebnis anschauen... es wird wohl etwas länger dauern.

    Hast du nur die eine DB? Mehr als 100GB sollte sie nicht als größe haben. Lieber mehrere kleinen, dann hättest du jetzt auch nicht ganz so viel zu tun.

    Mach also lieber einen Move und teil die Mailboxen etwas auf...
     -- Viele Grüße
    Christian

    Samstag, 14. April 2012 07:30
    Moderator
  • Hallo Christoph,

    die Postfächer in die 2te DB zu verschieben ist die wohl die sicherste Variante. Zumal diese auch in einem solchen Fall als beste Lösung von Microsoft angesprochen wird.

    Die Reparatur mit ESEUTIL läuft ja auf eine HARD-Recovery Reparatur raus, diese würde ich nur durchführen wenn sonst nichts mehr geht.

    Da Du im Moment noch alles am Laufen hast, würde ich die Postfächer in eine neue DB verschieben.


    Grüße, Christoph

    Samstag, 14. April 2012 07:32

Alle Antworten

  • Hallo Christoph,

    Je nach Wichtigkeit des Systems, evtl. vorhandenen SLAs solltest Du eine Entscheidung treffen.

    Ich denke niemand kann Dir eine belastbare Empfehlung geben die Woche abzuwarten. Schnelles Handeln ist meiner Meinung nach erforderlich !

    Fakt ist, dass es natürlich zu weiteren Beschädigungen und Inkosistenzen kommen kann, wenn Du die Ursache nicht 100%ig identifiziert hast.

    Ich an Deiner Stelle würde auf Nummer Sicher gehen und das nicht auf die lange Bank schieben -> Sicherlich mit Mehraufwand / Zeit verbunden allerdings sind Auswirkungen der größeren Beschädigung oder gar Stillstand sicher schlimmer. Zumal warscheinlich auch die Sicherung nicht mehr durchläuft.

    justmy2cents


    Grüße, Christoph

    Freitag, 13. April 2012 18:14

  • Christoph Schmeer meinte:

    Ich an Deiner Stelle würde auf Nummer Sicher gehen und das *nicht*auf die lange Bank schieben

    Ja, hast sicher Recht, ich werde nächste Woche mal 'ne Nachtschicht
    einschieben und die User drauf vorbereiten, dass es am nächsten Tag ggfls.
    noch nicht läuft (die DB hat eine physische Größe von >300 GB und eine
    logische von >270).

    Was hältst Du grundsätzlich von dem Vorgehen, die Postfächer in eine neue DB
    zu schieben? Eine Alternative wäre ja evtl., mit eseutil eine Reparatur
    zuprobieren.

    Zumal warscheinlich auch die Sicherung nicht mehr durchläuft.

    Ebent ;)

    Christoph Sternberg */\

    Samstag, 14. April 2012 07:03
  • Hi Christoph Sternberg,

    Christoph Schmeer meinte:

    Ich an Deiner Stelle würde auf Nummer Sicher gehen und das *nicht*auf die lange Bank schieben

    Ja, hast sicher Recht, ich werde nächste Woche mal 'ne Nachtschicht
    einschieben und die User drauf vorbereiten, dass es am nächsten Tag ggfls.
    noch nicht läuft (die DB hat eine physische Größe von >300 GB und eine
    logische von >270).

    Was hältst Du grundsätzlich von dem Vorgehen, die Postfächer in eine neue DB
    zu schieben? Eine Alternative wäre ja evtl., mit eseutil eine Reparatur
    zuprobieren.

    wenn du irgendwo 600GB freien Speicherplatz hast kannst du es ja parallel versuchen bis die Platten da sind und dir das Ergebnis anschauen... es wird wohl etwas länger dauern.

    Hast du nur die eine DB? Mehr als 100GB sollte sie nicht als größe haben. Lieber mehrere kleinen, dann hättest du jetzt auch nicht ganz so viel zu tun.

    Mach also lieber einen Move und teil die Mailboxen etwas auf...
     -- Viele Grüße
    Christian

    Samstag, 14. April 2012 07:30
    Moderator
  • Hallo Christoph,

    die Postfächer in die 2te DB zu verschieben ist die wohl die sicherste Variante. Zumal diese auch in einem solchen Fall als beste Lösung von Microsoft angesprochen wird.

    Die Reparatur mit ESEUTIL läuft ja auf eine HARD-Recovery Reparatur raus, diese würde ich nur durchführen wenn sonst nichts mehr geht.

    Da Du im Moment noch alles am Laufen hast, würde ich die Postfächer in eine neue DB verschieben.


    Grüße, Christoph

    Samstag, 14. April 2012 07:32

  • Christian Weihs meinte:

    Hast du nur die eine DB? Mehr als 100GB sollte sie nicht als größe haben. Lieber mehrere kleinen, dann hättest du jetzt auch nicht ganz so viel zu tun.

    Das war auch schon geplant, der Server sollte eigentlich demnächst ersetzt
    werden. But Murphy is watching you ...

    Christoph Sternberg */\

    Samstag, 14. April 2012 08:43
  • Danke für die hilfreichen Statements, ich hab' meinen Post als beantwortet
    markiert.

    Christoph Sternberg */\

    Samstag, 14. April 2012 08:49

  • Christoph -Ingrid- Sternberg meinte:

    Ich hatte vor, gemäß Methode 1 aus diesem Vorschlag

    http://technet.microsoft.com/de-de/library/bb397387(v=exchg.80).aspx

    übers Wochenende eine neue DB anzulegen und die Postfächer dorthin zu
    verschieben.

    Nur 'ne kleine Rückmeldung:

    Es ist vollbracht, knapp über zwei Tage hat er gebraucht ;-)

    Die Postfächer wurden alle fehlerfrei in zwei neue Datenbanken verschoben.
    Ich hatte aber ebbes zu schwitzen, da ich die Logs doch noch etwas
    unterschätzt hatte, die brauchen dabei noch deutlich mehr Platz als die
    Datenbank (mit etwa genausoviel hatte ich gerechnet). Ich musste letzte
    Nacht noch schnell parallel 'ne Sicherung anwerfen, sonst wäre mir meine HD
    übergelaufen ;-)

    Christoph Sternberg */\

    Donnerstag, 19. April 2012 17:36
  • Hi Christoph,

    jaja die Logfiles :) Im Ziel werden natürlich massiv Änderungen an den DBs produziert und das verursacht natürlich Log-Last :)

    Klasse das das geklappt hat und vielen Dank auch für die Rückmeldung !!


    Grüße, Christoph

    Donnerstag, 19. April 2012 18:39