April 17, 2009 at 2:09 am
Hi,
We had a discussion about mirror commit overhead and what an acceptable overheadtime is. Right now the overhead is 2-5 milliseconds per commit. In my opinion, this is acceptable. My colleguae disagrees. What's your opinion?
We're talking about 250-300 users in a 200GB database.
We use High safety without automatic failover (synchronous)
Thanks!
Wilfred
The best things in life are the simple things
April 17, 2009 at 1:53 pm
Why are you using Without Automatic Failover?
Wouldn't using With Automatic Failover give you high availability.
April 17, 2009 at 2:05 pm
Wilfred van Dijk (4/17/2009)
Hi,We had a discussion about mirror commit overhead and what an acceptable overheadtime is. Right now the overhead is 2-5 milliseconds per commit. In my opinion, this is acceptable. My colleguae disagrees. What's your opinion?
We're talking about 250-300 users in a 200GB database.
We use High safety without automatic failover (synchronous)
Thanks!
2-5 ms is not bad; it is with in acceptable levels. The question your colleguaes have to answer is would they have no automatic failover/DR? Yes you can use clustering; but its costs are higher then mirroring because you need to buy Microsoft certified hardware. Another benfit of mirroring is you can have a partner in a different location then your main Data center; where as in clustering it recommended they are side-by-side.
Thanks.
Mohit.
Mohit K. Gupta, MCITP: Database Administrator (2005), My Blog, Twitter: @SQLCAN[/url].
Microsoft FTE - SQL Server PFE
* Some time its the search that counts, not the finding...
* I didn't think so, but if I was wrong, I was wrong. I'd rather do something, and make a mistake than be frightened and be doing nothing. :smooooth:[/font]
April 17, 2009 at 2:15 pm
What is acceptable to your colleague? Are you talking the delay between the commit in server A and then on B?
April 17, 2009 at 4:15 pm
We started this discusion, because we had a terrible delay in our Axapta application on some forms. My colleguae was pointing to the mirror commit overhead (5-10 ms) because that's a new implementation since we moved from clustering to mirroring. So I think only 0 ms is acceptable to him 😀
I noticed that an index rebuild is dramatic if you use synchronous mirroring. The amount of unrestored log is increasing rapidly and so is the mirror commit overhead, but we normally don't run these actions during peak-hours. And no, asynchronous mirroring is not an option.
(btw the delay was caused by a fragmented index)
Wilfred
The best things in life are the simple things
April 17, 2009 at 6:07 pm
I would say Switch to Asynchronous as the first step before Index rebuild and as a last step after Index rebuild, Switch to Synchronous.
Just curious, why no Asynchronous mirroring?
Thanks,
Sudhie.
April 17, 2009 at 6:09 pm
Also keep a monitor on Unsent_log and send_rate using sp_dbmmonitorresults
Thanks,
Sudhie.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply