none
Exchange 2010: DAG Initial Seed funktioniert nicht - Logfile is missing on the active copy.

    Pregunta

  • Hallo Leute,

    ich teste gerade Datenbankkopien in einer DAG bestehend aus zwei Servern. Merkwürdigerweise funktioniert bei einigen Datenbank der Initial Seed nicht und ich erhalte folgende Fehlermeldung:

    The required log file 19 for DB002\2010-MIG-EX02 is missing on the active copy. If you removed the log file, please replace it. If the log file is lost, the database copy will need to be reseeded using Update-MailboxDatabaseCopy.

    Ein Dismounten/Mounten hilft nicht; prüfe ich die entsprechenden Datenbanken mit einem eseutl /mh, sieht aber scheinbar alles gut aus:

    State: Clean Shutdown
    Log Required: 0-0 (0x0-0x0)
    Log Committed: 0-0 (0x0-0x0)
    Log Recovering: 0 (0x0)

    Erstelle ich eine neue Datenbank, funktioniert der Initial Seed dafür problemlos. Am Anfang hatte ich Backup Exec 2010 R3 in Verdacht - die betroffenen Datenbanken sind damit zuvor gesichert worden. Bei der neuen Datenbank funktioniert der Initial Seed aber auch nach einer Sicherung.

    Hat da jemand vielleicht eine Idee?

    Danke
    Michael


    • Editado sam.bell jueves, 14 de junio de 2012 16:52
    jueves, 14 de junio de 2012 16:48

Respuestas

  • Hi,

    jetzt funktioniert es: Habe die aktive Datenbank einfach gedismounted und alle Logs gelöscht. Danach hat das initiale Seeding funktioniert.

    Gruß
    Michael

    • Marcado como respuesta sam.bell viernes, 15 de junio de 2012 7:50
    viernes, 15 de junio de 2012 7:50

Todas las respuestas

  • Hi,

    jetzt funktioniert es: Habe die aktive Datenbank einfach gedismounted und alle Logs gelöscht. Danach hat das initiale Seeding funktioniert.

    Gruß
    Michael

    • Marcado como respuesta sam.bell viernes, 15 de junio de 2012 7:50
    viernes, 15 de junio de 2012 7:50
  • Hi Michael,

    das kann aber nicht die Lösung sein. Ich habe hier bei einem Grosskunden das exakt gleiche Problem.

    Symantec Backup Exec 2010 R3 und Exchange 2010 SP2

    Get-MailboxDatabaseCopyStatus -Status -Server <failed server> | fl Name,*error*

    zeigt, dass ein Logfile fehlt. Es handelt sich dabei um das älteste Logfile (das erste Logfile nach Erstellung des BackUp, im aktuellen Zeitpunkt aber das älteste, da ja schon länger vorhanden)

    Bei uns betrifft es alle Datenbanken einer vier-Server DAG.

    Hier liegt ganz sicher ein Fehler vor und ich rate Dir dringend von der Methode ab, einfach Logfiles zu löschen, sobald Du eine Verpflichtung in Bezug auf die Daten hast. (Restore, SLA usw.)

    Einziger Workaround ist im Moment, die Datenbank erst zu sichern, wenn die Replikation steht. Alternativ kann man evtl. die Datenbank auch offline nehmen, sichern und dann replizieren. Geprüft habe ich den letzten Weg aber nicht.

    Wer hat einen besseren Weg oder das gleiche Problem?

    Grüsse aus Zürich

    Stefan

    miércoles, 27 de junio de 2012 20:58
  • Moin,

    Hier liegt ganz sicher ein Fehler vor und ich rate Dir dringend von der Methode ab, einfach Logfiles zu löschen, sobald Du eine Verpflichtung in Bezug auf die Daten hast. (Restore, SLA usw.)´

    wenn:
     - es noch keine Replikation gibt (war ja vor dem Initial Seeding)
     - die DB sauber dismounted wurde
     - der Status clean shutdown ist

    ist es ziemlich ungefährlich, LOG und CHK-Dateien zu löschen, da die dann eh nicht mehr benötigt werden.

    Wichtig ist nur, dass man nach dem Anlegen des initial Seedings und der fertigen Replikation SOFORT ein Backup macht, da die vorherigen inkrementiellen Backups durch das Löschen der Log-Dateien unbrauchbar wurden.

    Einziger Workaround ist im Moment, die Datenbank erst zu sichern, wenn die Replikation steht.´

    Das ist manchmal aber nicht möglich, wenn ein Kunde erst nachträglich DAGs einführt.

    Alternativ kann man evtl. die Datenbank auch offline nehmen, sichern und dann replizieren. Geprüft habe ich den letzten Weg aber nicht.

    Nein, das ist keine Sicherung im Exchange-Sinne.

    Wer hat einen besseren Weg oder das gleiche Problem?

    Wie gesagt: Hatte ich auch schon manchmal und das Problem liegt vermutlich irgendwo im Backup versteckt (nicht das Programm, sondern der gesamte Prozess).

    Wenn es vorher ein Komplettsicherung gibt und nachher auch, ist der oben beschrieben Weg relativ ungefährlich und von MSFT komplett supported (und in manchen Fehlerfällen sogar das offizielle Vorgehen).


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    jueves, 28 de junio de 2012 5:52
  • Hi Robert,

    Deiner Antwort stimme ich zu. Da es sich hier um ein Problem handelt, dass während der Produktion jederzeit aufzutreten scheint bzw. in unserem Fall alle Datenbanken betrifft, habe ich einen Case eröffnet.

    Als Dienstleister bieten wir unseren Kunden 30 Tage GRT mit Hilfe von Symantec BE an. Wenn wir nun Logs löschen, sind wir erst nach 30 Tagen wieder 100% konform.

    Warten wir ab.

    Gruss

    Stefan

    jueves, 28 de junio de 2012 7:08
  • Dem kann ich auch nur zustimmen. Allerdings wirst Du in Deinem Fall eher seltener die Situation erleben, dass Du eine DAG erst im nachhinein einrichtest. Und natürlich muss man dann die Backup-Probleme beachten, die aus solchem Vorgehen entstehen.

    Du hast vorher Deine Infrastruktur sauber, testest alles und gehst erst dann an Kunden mit SLA.

    Bei Michael war es, wenn ich mich nicht irre, eine komplett neue Infrastruktur und seine Erkenntniss stammten aus den erstens Tests.

    Berichte mal, was aus Deinem Case wurde. Da ich das "Problem" schon öfter gesehen habe, interessiert mich das Ergebnis.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    jueves, 28 de junio de 2012 7:13
  • Hallo Zusammen

    Ich bin im Moment auch gerade am DAG testen und hab dafür den Produktiven Exchange in eine Testumgebung kopiert. Soweit so gut, nur scheitere ich genau diesem Problem. Hat jemand von euch nun eine Lösung gefunden zu diesem Problem?

    Die DB zu dismounten und die Logs zu löschen, ist in meinen Augen etwas heikel..

    Gruss

    Stefan

    viernes, 08 de febrero de 2013 13:48
  • Moin,

    Ich bin im Moment auch gerade am DAG testen und hab dafür den Produktiven Exchange in eine Testumgebung kopiert. Soweit so gut, nur scheitere ich genau diesem Problem. Hat jemand von euch nun eine Lösung gefunden zu diesem Problem?

    es gibt keine andere Lösung, weil es kein Problem ist.

    Die DB zu dismounten und die Logs zu löschen, ist in meinen Augen etwas heikel..

    Wieso? Ist doch eine Testumgebung.

    Und sobald die Datenbank "Clean-Shutdown" hat, ist das ganz vollkommen problemlos, weil die Log-Dateien dann eh nicht mehr benötigt werden. Alle Log-Dateien + CHK-Datei löschen, wird beim Neustart dann alles neu erzeugt.

    Und danach gleich eine neue Vollsicherung anstoßen, weil die vorherigen inkrementellen nicht mehr gültig sind.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    sábado, 09 de febrero de 2013 9:17