What’s the issue?
A database snapshot is a read-only, point-in-time view of a SQL Server database, implemented via NTFS sparse files that grow as original pages are modified in the source database (copy-on-write). Snapshots are useful for reporting, testing, or quick reverts, but they are often created ad-hoc and left behind indefinitely, accumulating on production instances.
Why is this a problem?
Every write to the source database triggers a copy-on-write to each snapshot’s sparse file, adding I/O overhead that grows significantly with each additional snapshot. Performance can degrade sharply with more than one or two active snapshots on a busy database.
Snapshots also consume increasing disk space over time; if the volume runs out of space, the snapshot goes suspect and becomes unusable. Also, snapshots are not backups; they depend on the source database being online, live on the same storage, and prevent certain operations like restoring the source from backup while they exist.
What should you do about this?
Identify all existing snapshots by querying sys.databases where source_database_id IS NOT NULL. Review each one with the owning team to determine whether it’s still needed; most forgotten snapshots can simply be dropped with DROP DATABASE [SnapshotName].
For snapshots that serve a legitimate ongoing purpose, limit the count to one or two per source database, monitor sparse file size on disk, and establish a process to drop and recreate them on a schedule rather than letting them age indefinitely.