REPLICA_WRITES is recorded while a task waits for page writes to a database snapshot or a DBCC replica to complete. Both targets are the same machinery: user-created database snapshots receive copy-on-write pages, and DBCC CHECKDB runs against a hidden internal snapshot that works identically.
If this wait is on your board, snapshot files are absorbing page writes somewhere, visibly or invisibly.
Is It a Problem?
Small amounts during DBCC CHECKDB on a busy database are the internal snapshot doing its job. It earns attention when it stretches integrity check durations or when user snapshots make the source database’s writes noticeably slower, because every write to a snapshotted database pays the old-page copy into the sparse file first.
The wait’s timing is the giveaway: aligned with CHECKDB windows means the internal snapshot; constant presence means long-lived user snapshots.
Common Causes
- DBCC CHECKDB’s internal snapshot on a database with concurrent write activity.
- Long-lived user database snapshots on write-heavy databases.
- Sparse snapshot files sitting on slow storage (they default to the same volume as the data files).
- Multiple snapshots of the same database multiplying the copy-on-write cost.
What To Do
- Line up the wait’s spikes with CHECKDB schedules and
sys.databases(source_database_idpopulated = snapshots exist). - Run integrity checks off-peak, or offload them to a restored copy elsewhere, which validates backups at the same time.
- Audit user snapshots: how many, how old, on what storage; drop stale ones and keep lifetimes short.
- If snapshots are essential, give their sparse files fast storage; the copy-on-write path is in your write latency now.
How To See It
Rank it against everything else with Get-WaitStatistics, and read it together with WRITE_COMPLETION, its close sibling in the snapshot write path.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply