December 26, 2011 at 11:25 pm
Comments posted to this topic are about the item Mirroring and different sector sizes? BAD IDEA!
December 27, 2011 at 3:10 am
Good & well written article Theo. Useful to know. Thanks
Rgds,
T.
.be
December 27, 2011 at 5:32 am
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.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
December 27, 2011 at 5:36 am
December 28, 2011 at 9:51 am
Thanks Theo for share your experiences with us!!!!
This article is really very important
December 30, 2011 at 6:00 am
Excellent item. This is a fine example of how to write a technical article.
Thanks.
December 30, 2011 at 12:50 pm
tks for lesson learned without all the pain you endured! cheers
March 26, 2013 at 10:15 am
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.
October 23, 2013 at 5:38 am
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