Database mirroring is a mechanism for achieving high availability within SQL Server. It automates the process of sending transaction logs between two databases on different servers.  A number of mechanisms within mirroring require communication between the two databases involved, and a mirroring witness. The witness manages failover from the primary to the secondary in a mirrored environment. You may begin to see this wait as the number of signals grows between the databases, and the network resources become loaded down.

Waits caused by mirroring can come from a number of sources. You may have network latency issues between the two databases. You may have contention issues with other resources on the second database that are preventing the mirroring messages from being processed, resulting in waits on the primary machine. Frequently using synchronous mirroring calls (the safest call in terms of protection of the data, but the most costly in terms of performance) can also lead to DBMIRROR_SEND waits.

Investigating network issues

• Make sure you have adequate network bandwidth and speed to support mirroring.

• Test the network for general latency due to load or distance. See: sys.dm_io_virtual_file_stats (MSDN).

• Check for network configuration issues which may lead to high latency between systems.

• Make sure your network interface cards (NICs) are configured correctly.

• You may need to add additional NIC cards and  split your backup into multiple files through the new NICs.

Investigating mirroring

• Make sure your mirroring environment is set up correctly. See: Troubleshoot Database Mirroring Configuration (TechNet).  

• Determine if you actually need synchronous calls for your mirroring set up.

Investigating the mirroring partner

Determine if there are excessive waits or resource use on the secondary database that is preventing timely communication.