These two waits synchronise I/O against database snapshot sparse files, and this page covers both: FCB_REPLICA_READ for reads through a snapshot’s context (queries against the snapshot, or DBCC’s internal snapshot reading its own copied pages) and FCB_REPLICA_WRITE for the synchronised writes that push copy-on-write pages into the sparse file.
They complete the snapshot I/O picture alongside WRITE_COMPLETION and REPLICA_WRITES.
Are They a Problem?
Not as contention; neither has been a noticeable bottleneck in its own right. They are activity meters for snapshot usage: reporting queries against user snapshots on the read side, write workloads on snapshotted databases (and DBCC CHECKDB on busy databases) on the write side. When they carry real time, the snapshot sparse files are busy, and the sparse files’ storage speed is the underlying variable.
The DBCC angle repeats across this whole wait family: integrity checks against active databases exercise all the snapshot machinery invisibly.
What To Do
- Attribute the activity: user snapshots in play (
sys.databaseswithsource_database_id) versus DBCC windows. - Keep snapshot sparse files on storage that can absorb the copy-on-write load; by default they sit beside the data files.
- Apply the standing snapshot hygiene: short lifetimes, few concurrent snapshots, integrity checks off-peak or offloaded.
How To See It
Rank waits with Get-WaitStatistics, reading them with WRITE_COMPLETION and REPLICA_WRITES as one snapshot-I/O story.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply