May 8, 2012 at 12:31 pm
Hi -
I have two physically large servers. 64 Cores X 1 TB RAM.
SQL Services utilizes a 1 GB connection on the 10.2.X.X network and I've configured Async mirroring from A to B using endpoints over a 10GB pipe on 192.168.X.X.
Today we ran into an issue where we lost connection on the 192.168.X.X interface and this caused the SQL mirrors to be disconnected from one another.
When the connection was finally re-established, it took the mirrors almost 3 mirrors the become synchronized.
So - my question - has anyone attempted to disable the log compression (trace flag 1462) in an attempt to make the mirroring process faster.
The fastest send rate experienced is 65 MB/Sec...
Also - has anyone seen/heard a send rate > 65 MB/sec?
Please let me know.
May 8, 2012 at 12:55 pm
Actually, log compression for the data transfer between mirrored databases is designed to increase throughput of data between mirroed databases as more data can be transmitted in each packet. Disabling compression would slow the transfer of data.
With as big as your database, it lloks like there was quite a bit of data that needed to be transferred.
May 8, 2012 at 2:14 pm
Did futher diagnostic work - the sending rate had an approx. average of 40 MB/sec and the principal sent 37 GB to the mirror node in 15 min.
The restore rate was not nearly as efficient. The restore rate was quite slow - most times the restore rate was < 5 MB/sec but on individual occassions, the restore rate jumped to 36 MB/sec.
Any idea why the restore rate was so slow? FYI - the underlying subsystem is FusionIO, so writes should be fast.
October 2, 2013 at 4:20 am
Would you mind posting entire set of performance counters, any trace and / or SQL Server log records.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply