mediumLocking

LCK_M_IU_ABORT_BLOCKERS Wait Type Explained

LCK_M_IU_ABORT_BLOCKERS wait type occurs during low-priority ALTER TABLE/INDEX operations with abort blockers. Learn causes, diagnostics, and fixes.

Quick Answer

LCK_M_IU_ABORT_BLOCKERS occurs when a task waits for an Intent Update lock with Abort Blockers enabled, typically during low-priority ALTER TABLE or ALTER INDEX operations. This wait type prevents schema modification operations from blocking user workloads by allowing them to be aborted when blocking occurs.

Root Cause Analysis

This wait type was introduced in SQL Server 2014 as part of the low-priority wait infrastructure for online index operations. When executing ALTER TABLE or ALTER INDEX with the WAIT_AT_LOW_PRIORITY option, SQL Server attempts to acquire Intent Update (IU) locks on the affected resources. The "ABORT_BLOCKERS" suffix indicates the operation is configured to terminate blocking transactions when the specified timeout expires.

The lock manager handles IU locks differently from standard shared or exclusive locks. Intent locks exist in the lock hierarchy to signal intentions at higher levels (table, page) while actual data modifications occur at lower levels (row). When ABORT_BLOCKERS is specified, the lock manager maintains a separate queue for these requests and monitors blocking transactions.

SQL Server 2016 improved the abort blockers mechanism by reducing false positives in blocking detection. SQL Server 2019 and later versions enhanced the precision of timeout calculations, particularly for operations involving large tables with extensive locking hierarchies. The lock escalation threshold calculations also became more accurate in determining when to abort blockers versus waiting.

The scheduler handles these waits by placing the requesting task in a specialized wait queue. Unlike traditional lock waits that can persist indefinitely, abort blockers waits have built-in timeout mechanisms that actively monitor and terminate conflicting transactions when thresholds are exceeded.

AutoDBA checks Low priority wait configuration, blocking session monitoring, and index maintenance scheduling across your entire SQL Server instance in 60 seconds. Download the free diagnostic script and see what else needs attention.

Diagnostic Queries

-- Check current abort blockers waits and associated sessions
SELECT 
    r.session_id,
    r.wait_type,
    r.wait_time,
    r.blocking_session_id,
    t.text as current_sql,
    r.command,
    r.percent_complete
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.wait_type = 'LCK_M_IU_ABORT_BLOCKERS';
-- Identify the specific objects being modified with low priority waits
SELECT 
    r.session_id,
    DB_NAME(r.database_id) as database_name,
    OBJECT_NAME(p.object_id, r.database_id) as object_name,
    l.resource_type,
    l.request_mode,
    l.request_status,
    r.start_time,
    r.estimated_completion_time
FROM sys.dm_exec_requests r
INNER JOIN sys.dm_tran_locks l ON r.session_id = l.request_session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st
INNER JOIN sys.partitions p ON l.resource_associated_entity_id = p.hobt_id
WHERE r.wait_type = 'LCK_M_IU_ABORT_BLOCKERS';
-- Find blocking chains affecting abort blockers operations
WITH BlockingChain AS (
    SELECT 
        session_id,
        blocking_session_id,
        wait_type,
        wait_time,
        1 as level
    FROM sys.dm_exec_requests 
    WHERE blocking_session_id != 0
    
    UNION ALL
    
    SELECT 
        r.session_id,
        r.blocking_session_id,
        r.wait_type,
        r.wait_time,
        bc.level + 1
    FROM sys.dm_exec_requests r
    INNER JOIN BlockingChain bc ON r.session_id = bc.blocking_session_id
    WHERE bc.level < 10
)
SELECT 
    bc.*,
    s.login_name,
    s.program_name,
    s.host_name,
    t.text as sql_text
FROM BlockingChain bc
INNER JOIN sys.dm_exec_sessions s ON bc.session_id = s.session_id
OUTER APPLY sys.dm_exec_sql_text(s.most_recent_sql_handle) t
WHERE EXISTS (
    SELECT 1 FROM sys.dm_exec_requests r2 
    WHERE r2.wait_type = 'LCK_M_IU_ABORT_BLOCKERS'
    AND (r2.session_id = bc.session_id OR r2.blocking_session_id = bc.session_id)
);
-- Monitor WAIT_AT_LOW_PRIORITY configuration and effectiveness
SELECT 
    r.session_id,
    r.command,
    r.percent_complete,
    r.estimated_completion_time,
    SUBSTRING(t.text, (r.statement_start_offset/2)+1, 
        ((CASE WHEN r.statement_end_offset = -1 
           THEN LEN(CONVERT(nvarchar(max), t.text)) * 2 
           ELSE r.statement_end_offset END 
           - r.statement_start_offset)/2) + 1) AS statement_text,
    r.start_time,
    DATEDIFF(minute, r.start_time, GETDATE()) as runtime_minutes
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.wait_type = 'LCK_M_IU_ABORT_BLOCKERS'
   OR t.text LIKE '%WAIT_AT_LOW_PRIORITY%';

Fix Scripts

Increase the low priority wait timeout for ongoing operations

-- WARNING: This cancels the current operation and restarts with higher timeout
-- Test timeout values in development first
-- Typical values: 1 minute = 1, 5 minutes = 5, 10 minutes = 10

-- Cancel current operation (if safe to do so)
-- KILL [session_id_from_diagnostic_query]

-- Restart with increased timeout
ALTER INDEX [YourIndexName] ON [YourTable] 
REBUILD 
WITH (
    ONLINE = ON,
    WAIT_AT_LOW_PRIORITY (
        MAX_DURATION = 10,  -- 10 minutes
        ABORT_AFTER_WAIT = BLOCKERS
    )
);

Kill specific blocking sessions preventing abort blockers from proceeding

-- Identify and terminate specific blockers
-- USE WITH EXTREME CAUTION: This will roll back blocking transactions
-- Always verify the blocking session is safe to kill

DECLARE @blocking_spid INT;
SELECT @blocking_spid = blocking_session_id 
FROM sys.dm_exec_requests 
WHERE wait_type = 'LCK_M_IU_ABORT_BLOCKERS'
AND blocking_session_id > 0;

-- Verify what the blocking session is doing before killing
SELECT 
    s.session_id,
    s.login_name,
    s.program_name,
    t.text as current_sql,
    s.last_request_start_time
FROM sys.dm_exec_sessions s
OUTER APPLY sys.dm_exec_sql_text(s.most_recent_sql_handle) t
WHERE s.session_id = @blocking_spid;

-- Only execute after verifying safety
-- KILL @blocking_spid;

Modify operation to use SELF abort after wait

-- Change abort strategy to kill the schema operation instead of blockers
-- Safer option that won't impact user transactions
ALTER INDEX [YourIndexName] ON [YourTable] 
REBUILD 
WITH (
    ONLINE = ON,
    WAIT_AT_LOW_PRIORITY (
        MAX_DURATION = 5,   -- 5 minutes
        ABORT_AFTER_WAIT = SELF  -- Abort the index operation, not blockers
    )
);

AutoDBA generates fix scripts like these automatically, with impact estimates and rollback SQL included.

Prevention

Configure appropriate MAX_DURATION values based on historical blocking patterns. Monitor sys.dm_exec_requests during maintenance windows to establish baseline lock wait times for your environment. Typical production values range from 5-15 minutes depending on workload characteristics.

Schedule schema modification operations during low-activity periods when possible. Implement connection timeout policies for long-running user transactions that could block maintenance operations. Applications should use appropriate isolation levels and minimize transaction scope.

Enable Query Store to identify queries that frequently hold locks during maintenance windows. Use sys.dm_tran_locks monitoring to establish normal locking patterns before implementing abort blockers strategies.

Consider using resumable online index operations in SQL Server 2017+ for large tables. These operations can be paused and resumed, reducing the impact of blocking scenarios. Set up automated monitoring for wait types exceeding thresholds during maintenance operations.

Implement proper transaction log management to ensure sufficient log space during large index operations. Inadequate log space can extend operation duration and increase blocking likelihood.

Need hands-on help?

Dealing with persistent lck_m_iu_abort_blockers issues across your environment? Samix Technology provides hands-on SQL Server performance consulting with 15+ years of production DBA experience.

Related Pages