locked
resynchronizing database copy fails! High Copy Queue Length RRS feed

  • Question

  • Exchange 2010 SP2 2 host DAG.

    The mounted database has a clean shutdown state.

    I reseeded the database copy and that was sucessful.

    However when it tries to do resynchronizing the copy queue length continues to grow and it fails.

    I'm also seeing this in the logs

    The active copy of Mailbox Database Faculty has a missing or corrupted log file (E030042A9B0.log). To keep this copy healthy, replication will restart at generation 4368817. A full backup must be performed before an incremental backup is possible.

    Should I delete the database copy and create a new one and let it reseed?

    Thursday, July 11, 2013 3:35 PM

Answers

  • You make a copy of the working database by copying the database file, not the logs.

    Seeding a database makes a copy of the .edb file, it doesn't care about the logs at all. The part of the process that's tripping up your copy right now is the stage between copying the .edb file and catching up with all of the logs. The seeded copy is copying more logs than it needs to (from the point of view of just itself), so you need to convince it to start copying at a later point in the log stream.

    Thursday, July 11, 2013 11:06 PM

All replies

  • The Exchange 2010 Forum is http://social.technet.microsoft.com/Forums/en-US/home?forum=exchangesvravailabilityandisasterrecoverylegacy

    The problem you're running into is called Source Log Corruption. What's happening is that log E030042A9B0.log is corrupt. It can't be replayed into either a passive copy or a backup. If you caught this right away (and knew what it was) you could have forced a lossy failover to one of the passive copies and then reseeded the old active.

    When you seed the passive copy the copy will have the required range of the seeding source at the point of time that the seed began. But when it's done seeding and starts copying logs, it doesn't start copying logs at it's required range, it starts copying every log it can find. So even though the newly seeded copy doesn't need E030042A9B0.log it still tries to copy and inspect it (which is where it's failing).

    So what you can do is run Update-MailboxDatabaseCopy -ManualResume, and once it's complete use eseutil.exe to check the required range of the copy. Then manually copy the required range over to that copy yourself. Then Resume-MailboxDatabaseCopy, and the copy will start copying from that point on, working around the corrupt log on the source.

    Thursday, July 11, 2013 6:34 PM
  • Ok so my original copy is fine. I removed the second copy and created a brand new copy. WIll this work?

    Thursday, July 11, 2013 6:50 PM
  • No, the code for copying log files is the same code, whether it's an existing copy or a new one.
    Thursday, July 11, 2013 8:11 PM
  • I'm not following you. I have one good database copy and one that won't rebuild because of corrupt logs.

    How can you make a copy of the working database without the logs?

    Thursday, July 11, 2013 9:06 PM
  • You make a copy of the working database by copying the database file, not the logs.

    Seeding a database makes a copy of the .edb file, it doesn't care about the logs at all. The part of the process that's tripping up your copy right now is the stage between copying the .edb file and catching up with all of the logs. The seeded copy is copying more logs than it needs to (from the point of view of just itself), so you need to convince it to start copying at a later point in the log stream.

    Thursday, July 11, 2013 11:06 PM
  • What is the eseutil command to check the required range of the copy?
    Tuesday, March 10, 2015 11:20 PM