Quick Answer
LATCH_UP waits occur when sessions need update-level access to internal SQL Server data structures but must wait for other sessions holding conflicting latches to release them. This typically indicates high concurrency on metadata structures, buffer pool contention, or intensive DML operations competing for the same resources.
Root Cause Analysis
UPDATE latches protect SQL Server's internal data structures during read-modify-write operations. Unlike locks that protect user data, latches are lightweight synchronization primitives that guard access to pages in the buffer pool, allocation structures, and metadata objects. When a session requests an UPDATE latch, it can coexist with SHARED latches but must wait for any existing UPDATE or EXCLUSIVE latches to be released.
The most common scenarios generating LATCH_UP waits involve buffer pool pages where multiple sessions attempt to modify page headers, free space information, or row data simultaneously. Heavy INSERT, UPDATE, or DELETE workloads on the same pages create natural contention points. Allocation page contention occurs during rapid table growth when multiple sessions compete to allocate new extents or pages, particularly in databases with insufficient file growth settings or single data files.
SQL Server 2016 introduced significant improvements to latch handling through reduced latch duration and better memory ordering. SQL Server 2019 further optimized buffer pool latch contention with intelligent query processing features. SQL Server 2022 added enhanced telemetry for latch diagnostics, while SQL Server 2025 includes additional buffer pool optimizations that reduce overall latch pressure.
The scheduler component manages latch requests through a cooperative yield mechanism. When a session cannot immediately acquire an UPDATE latch, it yields its quantum and enters a wait state. The buffer pool manager coordinates latch acquisition with page lifecycle operations, ensuring data consistency during concurrent access patterns.
AutoDBA checks Buffer pool configuration, file allocation patterns, and latch contention monitoring across your entire SQL Server instance in 60 seconds. Download the free diagnostic script and see what else needs attention.
Diagnostic Queries
-- Identify top latch contention sources by resource
SELECT
latch_class,
waiting_requests_count,
wait_time_ms,
max_wait_time_ms,
wait_time_ms / NULLIF(waiting_requests_count, 0) AS avg_wait_ms
FROM sys.dm_os_latch_stats
WHERE latch_class NOT IN ('BUFFER', 'LOG_MANAGER', 'FULLTEXT_SEARCH')
AND waiting_requests_count > 0
ORDER BY wait_time_ms DESC;
-- Current sessions experiencing LATCH_UP waits
SELECT
s.session_id,
s.host_name,
s.program_name,
r.wait_type,
r.wait_resource,
r.wait_time,
t.text AS current_sql
FROM sys.dm_exec_sessions s
INNER JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.wait_type = 'LATCH_UP'
ORDER BY r.wait_time DESC;
-- Buffer pool contention: identify hot objects via index operational stats
SELECT TOP 20
DB_NAME(database_id) AS database_name,
OBJECT_NAME(object_id, database_id) AS object_name,
index_id,
page_latch_wait_count,
page_latch_wait_in_ms,
page_latch_wait_in_ms / NULLIF(page_latch_wait_count, 0) AS avg_page_latch_wait_ms
FROM sys.dm_db_index_operational_stats(NULL, NULL, NULL, NULL)
WHERE page_latch_wait_count > 0
ORDER BY page_latch_wait_in_ms DESC;
-- Allocation contention patterns from latch stats
SELECT
latch_class,
waiting_requests_count,
wait_time_ms,
max_wait_time_ms,
wait_time_ms / NULLIF(waiting_requests_count, 0) AS avg_wait_ms
FROM sys.dm_os_latch_stats
WHERE latch_class LIKE '%ALLOC%'
AND waiting_requests_count > 0
ORDER BY wait_time_ms DESC;
-- Current BUFFER latch wait summary
SELECT
latch_class,
waiting_requests_count,
wait_time_ms,
max_wait_time_ms,
wait_time_ms / NULLIF(waiting_requests_count, 0) AS avg_wait_ms
FROM sys.dm_os_latch_stats
WHERE latch_class = 'BUFFER'
AND waiting_requests_count > 0;
Fix Scripts
Increase Multiple Data Files for Allocation Relief Creates additional data files to distribute allocation latch pressure across multiple allocation structures.
-- Add additional data files to reduce allocation contention
-- TEST IN DEVELOPMENT FIRST - Monitor disk space and I/O patterns
USE master;
DECLARE @db_name NVARCHAR(128) = 'YourDatabaseName';
DECLARE @logical_name NVARCHAR(128) = @db_name + '_Data2';
DECLARE @file_path NVARCHAR(260) = 'C:\Data\' + @db_name + '_Data2.mdf';
EXEC('ALTER DATABASE [' + @db_name + ']
ADD FILE (NAME = ''' + @logical_name + ''',
FILENAME = ''' + @file_path + ''',
SIZE = 1GB,
FILEGROWTH = 256MB)');
Enable Instant File Initialization Reduces allocation wait times by eliminating zero-initialization overhead during file growth operations.
-- Enable instant file initialization at service level
-- Requires SQL Server service restart and proper service account privileges
-- Grant "Perform Volume Maintenance Tasks" to SQL Server service account
-- Verify current status first
SELECT
instant_file_initialization_enabled,
service_account
FROM sys.dm_server_services
WHERE servicename LIKE 'SQL Server (%';
-- Note: This requires Windows-level configuration, not T-SQL
-- Use SQL Server Configuration Manager or Group Policy
Optimize Buffer Pool Memory Configuration Adjusts memory settings to reduce buffer pool pressure and subsequent latch contention.
-- Increase max server memory if system has available RAM
-- Monitor Buffer Manager\Page Life Expectancy counter
-- TEST CAREFULLY - Incorrect memory settings can destabilize the instance
DECLARE @total_memory_gb INT = 16; -- Adjust based on server capacity
DECLARE @max_memory_mb INT = (@total_memory_gb - 4) * 1024; -- Reserve 4GB for OS
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', @max_memory_mb;
RECONFIGURE;
PRINT 'Max server memory set to ' + CAST(@max_memory_mb AS VARCHAR(10)) + ' MB';
Implement Partitioning for Hot Tables Reduces latch contention by distributing data modifications across multiple partition structures.
-- Create partition function and scheme for high-contention table
-- TEST THOROUGHLY - Partitioning changes require careful planning
USE YourDatabaseName;
-- Example: Partition by date range for time-series data
CREATE PARTITION FUNCTION pf_monthly_range (DATETIME2)
AS RANGE RIGHT FOR VALUES
('2024-01-01', '2024-02-01', '2024-03-01', '2024-04-01');
CREATE PARTITION SCHEME ps_monthly_scheme
AS PARTITION pf_monthly_range
TO (fg_partition1, fg_partition2, fg_partition3, fg_partition4, [PRIMARY]);
-- Apply to existing table (requires rebuilding)
-- ALTER TABLE YourHotTable
-- DROP CONSTRAINT pk_constraint_name;
-- ALTER TABLE YourHotTable
-- ADD CONSTRAINT pk_constraint_name PRIMARY KEY (id, date_column)
-- ON ps_monthly_scheme(date_column);
AutoDBA generates fix scripts like these automatically, with impact estimates and rollback SQL included.
Prevention
Configure multiple data files with equal initial sizes and identical growth settings to distribute allocation workload. Set reasonable autogrowth increments (256MB or higher) to minimize frequent allocation operations that generate latch contention. Enable instant file initialization through service account permissions to reduce allocation wait times.
Monitor Buffer Manager performance counters including Page Life Expectancy, Buffer Cache Hit Ratio, and Page Writes/sec. Implement proactive memory pressure monitoring using sys.dm_os_memory_clerks to identify memory consumers before they force excessive buffer pool churn.
Design table structures to minimize hot spots through appropriate indexing strategies. Avoid single-column identity keys on high-volume OLTP tables; consider composite keys or partitioning schemes that distribute insert activity. Implement proper maintenance windows for index rebuilds to prevent fragmentation that increases page split frequency and associated latch pressure.
Establish baseline performance metrics using sys.dm_os_latch_stats during normal operations. Create automated alerts when LATCH_UP wait times exceed historical averages by more than 200% for sustained periods. Schedule regular analysis of allocation unit distribution across filegroups to identify growing imbalances that concentrate latch activity.
Configure SQL Server instances with adequate memory allocation, typically 75-80% of available system memory for dedicated database servers. Implement connection pooling and query plan reuse strategies to reduce metadata access patterns that contribute to non-buffer latch contention.
Need hands-on help?
Dealing with persistent latch_up issues across your environment? Samix Technology provides hands-on SQL Server performance consulting with 15+ years of production DBA experience.