Mirror commit overhead

  • 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

  • Why are you using Without Automatic Failover?

    Wouldn't using With Automatic Failover give you high availability.

  • 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.

    [font="Arial"]---

    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]

    How to ask for help .. Read Best Practices here[/url].

  • What is acceptable to your colleague? Are you talking the delay between the commit in server A and then on B?

  • 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

  • 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.

  • 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