DBMIRROR_SEND

(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)

(Back to main page…)

Description:

This wait type is just as Books Online describes.

(Books Online description: “Occurs when a task is waiting for a communications backlog at the network layer to clear to be able to send messages. Indicates that the communications layer is starting to become overloaded and affect the database mirroring data throughput.”)

Questions/comments on this wait type? Click here to send Paul an email, especially if you have any information to add to this topic.

Added in SQL Server version:

Pre-2005/2005

Removed in SQL Server version:

N/A

Extended Events wait_type value:

The map_key value in sys.dm_xe_map_values is 139 in 2008 and 2008 R2, and 143 in 2012 and 2014 RTM. After 2014 RTM, you must check the DMV to get the latest value as some map_key values have changed in later builds.

Other information:

This wait type can become prevalent if a database mirroring session is set to synchronous, and there is a high volume of transaction log. This often results on the workload on the primary running more slowly because the network and/or mirror simply cannot process the log volume quickly enough. If that is the case, setting the mirroring session to asynchronous will alleviate the performance issue (and this wait type), at the expense of a send queue building up on the primary and the potential for data loss increasing if a failure occurs. You could also increase network performance and make sure the mirror server does not have any performance bottlenecks.

This wait type can also occur if the number of mirroring sessions on one server and/or the combined amount of log traffic results in a network or mirror overload, in which case similar troubleshooting steps apply as described above.

Known occurrences in SQL Server (list number matches call stack list):

  1. Waiting for network traffic (in this case, the mirror is asking for some log from the principal)
  2. Waiting for network traffic (in this case, the mirror is asking for some data pages from the principal)

And other similar call stacks.

Abbreviated call stacks (list number matches known occurrences list):

  1. SOS_Task::PostWait+9e
    EventInternal<SuspendQueueSLock>::Wait+1fb
    DbmStream::Receive+fa
    LsBuffer::Receive+40
    LsMgr::ProcessLogStream+314
    LsMgr::ProcessLogStreamResponse+6e
    LsWorkRequest::Execute+47
    LsWorker::ThreadRoutine+152
    LsWorker::ThreadRoutine+1c7
    SOS_Task::Param::Execute+21e
    SOS_Scheduler::RunTask+a8
  2. SOS_Task::PostWait+9e
    EventInternal<SuspendQueueSLock>::Wait+1fb
    DbmStream::Receive+fa
    LsBuffer::Receive+40
    LsMgr::ProcessDataStream+141
    LsMgr::ProcessDatabasePagesResponse+6c
    LsWorkRequest::Execute+47
    LsWorker::ThreadRoutine+152
    LsWorker::ThreadRoutine+1c7
    SOS_Task::Param::Execute+21e
    SOS_Scheduler::RunTask+a8