FCB_REPLICA_WRITE Wait Type Explained

FCB_REPLICA_WRITE waits originate in SQL Server's File Control Block management layer, specifically when the buffer pool manager coordinates writes to sparse files used by database snapshots. When a snapshot is created, SQL Server uses a sparse file that initially contains no data but grows as pages are modified in the source database. The FCB manages the metadata for these sparse file allocations.

The wait occurs during two primary scenarios. First, when a page is being copied from the source database to the snapshot sparse file (copy-on-write operation). Second, during DBCC operations that create internal temporary snapshots for consistency, such as DBCC CHECKDB with PHYSICAL_ONLY or DBCC CHECKTABLE operations.

SQL Server 2016 introduced significant changes to snapshot internals with the addition of accelerated database recovery preparation, though FCB_REPLICA_WRITE behavior remained consistent. SQL Server 2019 improved sparse file handling efficiency, reducing the frequency of these waits under normal conditions. SQL Server 2022 enhanced the FCB caching mechanism, which can reduce wait times but doesn't eliminate the waits entirely.

The underlying issue stems from the FCB layer's need to serialize access to sparse file block allocation metadata. When multiple worker threads simultaneously attempt to allocate new blocks in the sparse file, they queue on the FCB_REPLICA_WRITE wait type. This creates a bottleneck that's typically I/O bound rather than CPU bound.

-- Identify current FCB_REPLICA_WRITE 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 = 'FCB_REPLICA_WRITE';

-- Find active sessions experiencing FCB_REPLICA_WRITE waits
SELECT 
    s.session_id,
    s.status,
    r.command,
    r.database_id,
    DB_NAME(r.database_id) AS database_name,
    w.wait_type,
    w.wait_time,
    w.resource_description,
    t.text AS current_sql
FROM sys.dm_exec_sessions s
INNER JOIN sys.dm_os_waiting_tasks w ON s.session_id = w.session_id
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(c.most_recent_sql_handle) t
WHERE w.wait_type = 'FCB_REPLICA_WRITE';

-- Examine database snapshots that might be causing waits
SELECT 
    name AS snapshot_name,
    source_database_id,
    DB_NAME(source_database_id) AS source_database,
    create_date,
    state_desc,
    is_read_only
FROM sys.databases 
WHERE source_database_id IS NOT NULL
ORDER BY create_date DESC;

-- Check for DBCC operations that create internal snapshots
SELECT 
    s.session_id,
    s.status,
    s.command,
    s.percent_complete,
    s.estimated_completion_time,
    DB_NAME(s.database_id) AS database_name,
    t.text
FROM sys.dm_exec_requests s
OUTER APPLY sys.dm_exec_sql_text(s.sql_handle) t
WHERE s.command LIKE 'DBCC%' 
   OR t.text LIKE '%DBCC%';

-- Monitor I/O statistics for databases with snapshots
SELECT 
    DB_NAME(vfs.database_id) AS database_name,
    vfs.file_id,
    mf.physical_name,
    vfs.num_of_writes,
    vfs.num_of_bytes_written,
    vfs.io_stall_write_ms,
    vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes, 0) AS avg_write_stall_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs
INNER JOIN sys.master_files mf ON vfs.database_id = mf.database_id 
    AND vfs.file_id = mf.file_id
WHERE EXISTS (
    SELECT 1 FROM sys.databases d 
    WHERE d.database_id = vfs.database_id 
    AND d.source_database_id IS NOT NULL
)
ORDER BY vfs.io_stall_write_ms DESC;

Remove unnecessary database snapshots This script identifies and provides commands to drop snapshots that may no longer be needed, reducing FCB contention.

-- Generate DROP DATABASE commands for old snapshots
-- REVIEW CAREFULLY before executing - snapshots may be in use
SELECT 
    'DROP DATABASE [' + name + '];' AS drop_command,
    name AS snapshot_name,
    DB_NAME(source_database_id) AS source_database,
    create_date,
    DATEDIFF(hour, create_date, GETDATE()) AS age_hours
FROM sys.databases 
WHERE source_database_id IS NOT NULL
  AND create_date < DATEADD(day, -1, GETDATE()) -- Older than 1 day
ORDER BY create_date;
-- TEST IN DEV: Verify snapshots are not needed before dropping
-- IMPACT: Eliminates snapshot-related I/O pressure immediately

Optimize DBCC operation scheduling Configure DBCC operations to run during maintenance windows to reduce contention.

-- Create job step for DBCC CHECKDB with minimal impact
-- Replace 'YourDatabase' with actual database name
DECLARE @sql NVARCHAR(MAX) = N'
DBCC CHECKDB([YourDatabase]) 
WITH NO_INFOMSGS, 
     PHYSICAL_ONLY,  -- Faster, less resource intensive
     MAXDOP = 2;     -- Limit parallelism to reduce contention
';

PRINT @sql;
-- Execute during maintenance window only
-- IMPACT: Reduces concurrent snapshot creation and FCB pressure
-- CAVEAT: PHYSICAL_ONLY provides less comprehensive checking

Monitor and alert on excessive FCB waits Set up automated monitoring to detect when FCB_REPLICA_WRITE waits become problematic.

-- Create monitoring query for alerting (embed in monitoring tool)
DECLARE @threshold_ms INT = 10000; -- Alert if total wait time > 10 seconds

SELECT 
    'FCB_REPLICA_WRITE waits detected' AS alert_message,
    wait_time_ms,
    waiting_tasks_count,
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS avg_wait_per_task_ms
FROM sys.dm_os_wait_stats 
WHERE wait_type = 'FCB_REPLICA_WRITE'
  AND wait_time_ms > @threshold_ms;

-- Integrate this into your monitoring solution
-- IMPACT: Proactive detection of FCB contention issues
-- CAVEAT: Adjust threshold based on your environment's baseline

Relocate snapshot files to faster storage Move snapshot files to faster I/O subsystems to reduce wait times.

-- Template for creating snapshots on specific file locations
-- Replace paths and database names with your values
/*
CREATE DATABASE [YourDB_Snapshot_YYYYMMDD] ON 
(NAME = 'YourDB_Data', 
 FILENAME = 'E:\FastStorage\Snapshots\YourDB_Snapshot_YYYYMMDD.ss')
AS SNAPSHOT OF [YourDB];
*/

-- IMPACT: Faster I/O reduces FCB wait duration
-- CAVEAT: Requires dedicated high-performance storage for snapshots
-- TEST: Verify storage performance improvement before implementing

Configure DBCC operations to run with MAXDOP limitations during off-peak hours. Use PHYSICAL_ONLY option when comprehensive logical checking isn't required. Schedule multiple DBCC operations across different time windows to prevent concurrent snapshot creation.

Implement snapshot lifecycle management with automated cleanup of snapshots older than business requirements dictate. Most environments don't need snapshots older than 24-48 hours unless specifically required for point-in-time recovery scenarios.

Place snapshot files on dedicated high-performance storage subsystems separate from primary database files. SSDs with high IOPS capabilities significantly reduce FCB_REPLICA_WRITE wait durations. Configure separate file groups for snapshot storage when possible.

Monitor FCB_REPLICA_WRITE wait statistics weekly and establish baselines. Sudden increases often indicate either increased snapshot usage or I/O subsystem degradation. Set up automated alerts when wait times exceed 2x your established baseline.

Consider consolidating multiple small DBCC operations into single larger operations during maintenance windows rather than running frequent smaller checks throughout the day. This reduces the total number of snapshot creation events.