DBMIRROR_WORKER_QUEUE Wait Type Explained

Database mirroring in SQL Server uses a dedicated worker thread pool to handle the asynchronous transfer of transaction log records from the principal to the mirror database. The DBMIRROR_WORKER_QUEUE wait occurs when these worker threads have completed their current batch of work and are waiting in a queue for the next set of log records to process.

The mirroring architecture employs a producer-consumer pattern where the log reader thread on the principal database extracts committed transactions from the transaction log and places them into internal message buffers. The mirroring worker threads consume these messages and transmit them over the mirroring endpoint connection. When transaction volume is low or during idle periods, worker threads naturally enter this wait state.

SQL Server 2012 and later versions improved the mirroring worker thread management by implementing better thread pooling and reducing unnecessary context switching. In SQL Server 2016 and beyond, the wait statistics became more granular, making DBMIRROR_WORKER_QUEUE more visible in monitoring tools.

The wait duration directly correlates with transaction frequency on the principal database. High-frequency OLTP workloads typically show minimal accumulation of this wait type, while batch processing systems or databases with periodic activity patterns show higher wait times during quiet periods. This behavior is expected and does not indicate performance degradation.

-- Check current database mirroring status and worker activity
SELECT 
    db_name(database_id) AS database_name,
    mirroring_state_desc,
    mirroring_role_desc,
    mirroring_safety_level_desc,
    mirroring_witness_state_desc
FROM sys.database_mirroring 
WHERE mirroring_guid IS NOT NULL;

-- Analyze DBMIRROR_WORKER_QUEUE wait statistics
SELECT 
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    max_wait_time_ms,
    signal_wait_time_ms,
    wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms
FROM sys.dm_os_wait_stats 
WHERE wait_type = 'DBMIRROR_WORKER_QUEUE';

-- Monitor mirroring performance counters for worker queue depth
SELECT 
    instance_name,
    counter_name,
    cntr_value
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Database Mirroring%'
    AND counter_name IN ('Log Send Queue KB', 'Redo Queue KB', 'Transaction Delay');

-- Check mirroring endpoint status and associated connections
SELECT 
    e.name AS endpoint_name,
    e.state_desc AS endpoint_state,
    e.role_desc,
    c.session_id,
    c.connect_time,
    c.net_transport
FROM sys.database_mirroring_endpoints e
LEFT JOIN sys.dm_exec_connections c ON e.endpoint_id = c.endpoint_id;

-- Review mirroring-related error log entries
EXEC xp_readerrorlog 0, 1, 'mirroring', null, null, null, 'DESC';

Monitor mirroring lag and adjust send buffer sizes

-- Check if mirroring is experiencing lag that could cause worker queue buildup
DECLARE @lag_threshold_seconds INT = 30;

SELECT 
    DB_NAME(database_id) AS database_name,
    mirroring_state_desc,
    mirroring_connection_timeout AS timeout_seconds
FROM sys.database_mirroring 
WHERE mirroring_guid IS NOT NULL
    AND mirroring_state = 4; -- SYNCHRONIZED

-- If lag exceeds threshold, consider increasing TCP buffer sizes
-- This should be tested in development first

Reset wait statistics to establish baseline

-- Clear wait statistics to get fresh measurements
-- WARNING: This clears ALL wait stats, use during maintenance window
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR);

-- Alternative: Capture baseline for comparison
SELECT 
    GETDATE() AS capture_time,
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    max_wait_time_ms
INTO #wait_stats_baseline
FROM sys.dm_os_wait_stats 
WHERE wait_type = 'DBMIRROR_WORKER_QUEUE';

Configure mirroring timeout settings

-- Adjust partner timeout if worker queues are frequently idle
-- This affects how long SQL Server waits before considering partner disconnected
-- Default is 10 seconds, increase for high-latency networks

USE [your_mirrored_database];
GO

-- Increase timeout to 20 seconds for high-latency scenarios
-- Test thoroughly before implementing in production
ALTER DATABASE [your_mirrored_database] 
SET PARTNER TIMEOUT 20;

Monitor and alert on mirroring queue depths

-- Create monitoring query for automated alerting
-- Alert if send queue exceeds 10MB or redo queue exceeds 5MB
DECLARE @send_queue_threshold_kb INT = 10240;  -- 10MB
DECLARE @redo_queue_threshold_kb INT = 5120;   -- 5MB

SELECT 
    'MIRRORING_QUEUE_ALERT' AS alert_type,
    instance_name AS database_name,
    counter_name,
    cntr_value AS queue_size_kb,
    CASE counter_name
        WHEN 'Log Send Queue KB' THEN @send_queue_threshold_kb
        WHEN 'Redo Queue KB' THEN @redo_queue_threshold_kb
    END AS threshold_kb
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Database Mirroring%'
    AND counter_name IN ('Log Send Queue KB', 'Redo Queue KB')
    AND cntr_value > CASE counter_name
        WHEN 'Log Send Queue KB' THEN @send_queue_threshold_kb
        WHEN 'Redo Queue KB' THEN @redo_queue_threshold_kb
    END;

Implement comprehensive mirroring monitoring that tracks queue depths, connection stability, and worker thread utilization. Set up Performance Monitor counters for "Database Mirroring: Log Send Queue KB" and "Database Mirroring: Redo Queue KB" with appropriate thresholds based on your transaction volume patterns.

Configure mirroring endpoints with optimal TCP buffer sizes for your network latency. For high-latency networks, increase the partner timeout value beyond the default 10 seconds to prevent premature connection resets that can cause worker threads to queue unnecessarily.

Establish baseline measurements for DBMIRROR_WORKER_QUEUE wait times during normal operations. Create automated alerts that trigger when wait times deviate significantly from established patterns, indicating potential network issues or partner database performance problems.

Consider implementing Always On Availability Groups for new deployments, as they provide better worker thread management and more granular monitoring capabilities compared to traditional database mirroring.

Monitor the mirroring witness server (if configured) to ensure it remains accessible. Witness connectivity issues can cause unnecessary failover attempts that increase worker queue activity and associated wait times.