Mirroring and different sector sizes? BAD IDEA!

  • Comments posted to this topic are about the item Mirroring and different sector sizes? BAD IDEA!

  • Good & well written article Theo. Useful to know. Thanks




  • Very well written article. Thank-you very much for the same.

    It's difficult to keep cool and look for the root cause when such problems arise. I therefore, appreciate your dedication to the issue. I am sure this will help out a lot of the members of the community.

    Thanks & Regards,
    Nakul Vachhrajani.

    Follow me on
    Twitter: @sqltwins

  • Thank you. This is bound to bite me in the future.



    Did you get access denied? Great the security works.

  • Thanks Theo for share your experiences with us!!!!

    This article is really very important

    [font="Times New Roman"]rfr.ferrari[/font]
    DBA - SQL Server 2008

    remember is live or suffer twice!
    the period you fastest growing is the most difficult period of your life!
  • Excellent item. This is a fine example of how to write a technical article.


  • tks for lesson learned without all the pain you endured! cheers

  • The title of the article is about Mirroring with different sector sizes but the content of the article is about disk misalignment. Very helpful info but maybe a title change?

    I have several clients who have bought new SANs that go with a 4k sector sized LUN but keep the old SAN as their mirror failover. In some cases they won't or can't rebuild the old SAN's LUNs to be 4k sector based so they get warnings in the SQL Server logs about the tail of the log having to be re-written. It will slow down performance if the mirroring process has to take each 4k chunk and remap it back to 512B and then process each of the 512B chunks.. but its effects are dependent. One client I have has two HP DL980's running 160 logical cores doing all OLTP and they're mirroring is working fine enough in this setup. It spams their error logs but that's the price of not upgrading the old SAN.

    Disk alignment, as you have shown, causes more IO to be required to do the same task. For a read it will be 2x. It has to grab both physical sectors that the logical sector is on in order to reconstitute the logical sector. For writes it can be worse. It's called a Read Modify Write. It has to read both physical sectors, then modify the parts that changed on both physical sectors, then write both physical sectors to storage. So there's 4x the IO's plus two 'update' transactions in the storage tier.

  • Great article and a very clear and detailed explanation - thank you very much.

    Have just seen this exact same problem with a 4 replica AlwaysOn Availability Group.

    Sure enough the disk sector size on one of the replica servers is different to that on the other three.

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply