January 27, 2016 at 2:06 am
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms
------------------------------------------------------ --------------------
DBMIRROR_DBM_EVENT 240946 36973348 58712
January 27, 2016 at 6:53 am
February 2, 2016 at 9:20 pm
Well I figured it out. This wait type occurs when lot of time is taken to harden the data at both the mirror server and principal server.This could be issue with slow network.when I changed the operating mode to asynchronous
it worked fine without any issues...:-)
February 3, 2016 at 7:13 am
I'm glad you found the resources you needed to understand the wait type.
Just keep in mind that when switching to asynchronous you're not just getting the same mirroring without the overhead of waiting on the mirror instance.
In asynchronous you don't see the overhead associated with that wait type, but that's precisely because transactions on the principal are free to commit without the log being hardened on the mirror. That means if something terrible happens to the principal and you have to go live on the mirror instance, you could actually lose data from committed transactions.
If the mirroring is being used for DR to another geographical site, that's probably acceptable, but should be known. If the mirroring is being used to keep a copy of the data available for HA, that possibility of data loss may not be acceptable (although it might still be; that's a business decision, really).
You also lose the ability to configure mirroring for automatic failover, if that feature is important to you.
You're probably aware of all that, but in case someone else stumbled across this thread, I figured I would point it out.
Cheers!
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply