Dear TIMMCMIC,
it's great article :)
Just my thought, Can we create the new database then moving all mailbox to the new database?
BR,
Khemarin
7 May 2014 1:48 PM
7 May 2014 2:06 PM
@@Khemarin...
I'm not sure what you mean by this comment.
You can always create a new database, add the copies, and migrate the users to it.
If you create any single copy database and perform a backup of it you will have this issue.
TIMMCMIC
Simple issue
12 May 2014 12:11 PM
It seems to me that this issue is rather simple and that most people would run in to this problem. Would it not have been good of microsoft to come up with a solution to this problem as a part of the software? So that you could just make a database copy even if you have zero copies and you have performed a backup. Wouldn't have that been a better solution than having to break all my exchange backups?
12 May 2014 12:39 PM
@Simple Issue...
The decision to change or fix code is always a balance between the cost of taking the change, the potential destabilizations that may occur, and many other factors. Although this would seem like a "simple issue" the change is potentially very complicated as it crosses two different processes. Architecturally to fix this would require modifying portions of the store code while the replicated database behavior resides within the replication service.
With that in mind - the number of cases that present to support with this particular issue were very low. When looking at the majority of database handling in a DAG it appeared the more common method was to have the DAG fully established and have the copies fully established prior to backing them up or moving mailboxes to them. With that in mind though there should not be an issue with backing up a single copy database that is populated etc. In some cases this issue was actually encountered by customers who were intentionally removing all copies and readding them (with backups that has occurred in between). The issue becomes even less frequent as we continue to see installations moving to native data protection and forgoing all backups completely.
The workaround highlighted here is simple and low risk with the only side effect being the break of the restore chain moving from a single database to a database with a copy. In the long run that risk is even further mitigated by the fact that you are using a database availability group and would hopefully by now have more than one copy of a database. (The break only occurs after the database copy has successfully seeded and log files start to ship - implying a healthy copy to move to in the short term).
Given the simple work around, the low overall impact, and the high overall impact of taking a code change the decision is to not fix the issue but rather work around it.
Thanks
TIMMCMIC
Simple issue
13 May 2014 4:10 PM
Hi thank you for the prompt and informative response. I suspected that there would be a good justification for it.
We ran in to this issue because we upgraded to 2010 from 2003 before adding the second 2010 server as we were waiting on a wan link, which was not installed until after the upgrade.
Interestingly, I managed to seed db2 first time without any problems but suspect that i may have added it suspended and then the following day seeded it, at the time not knowing what i did differently that allowed it to work first time.
I had on the weekend tried another seed of the db1 (before find this article) this db had failed to seed many times as i have been trying for a few months on this problem and not wanting to rename the logs folder as described by many blog and forums posts on the topic.
What I did:
1) removed the failed seed. (without deleting the actual files) this is after a successful seed of the db with a log file error as described in your blog post exactly.
2) enabled circular logging on the db. Waited 30 mins for it replicate.
3) ran the seed command only to be told the DB is not in a suspended state. Ran Get-MailboxDatabaseCopyStatus only to find that it is in a healthy state.
4) disabled circular logging.
This is essentially the same as what you said except i didn't have to reseed.
Thanks for the blog post and taking the time to respond.
13 May 2014 4:12 PM
@Simple Issue
I'd have to look at the logs to explain that. It should not have gone into a healthy state.
TIMMCMIC
simple issue
13 May 2014 4:29 PM
What would you suggest then? to not turn off circular logging right away?
Should I re-renable circular logging and suspend the copy and reseed it with delete existing files? I checked the folders and the log and edb file look ok on the secondary server and the replication status says healthy.
I am bit concerned now.
Thomas
22 Jul 2014 2:50 PM
Excellent Article.Thank You!
hero
17 Sep 2014 4:00 AM
this article help me resolve my datbae copy add problems thanks
Me
5 Oct 2014 12:39 PM
how did I miss this post:)?
amazing info to know, I seen this many times and used to dismount remove logs and mount.
which isn't even supposed to work in DAG(I removed copies before that's probably why it worked)
this is much simpler and supported.
Thanks
6 Oct 2014 1:42 PM
@Me..
I have no idea how you've missed this wonderful post! I'm glad it was able to help...
TIMMCMIC
Me
8 Oct 2014 5:33 PM
i also have no idea:)
i already read it like 3 times just to understand what the "lowest log" is
i am sure 99.99% of people handling exchange dont have a clue about this whole procedure or the fact that c.logging doesn't require dismount mount.
they think "backup should truncate logs" and that's where it ends:)
blame Symantec:)