What’s the issue?
SQL Server offers three page verification options — NONE, TORN_PAGE_DETECTION, and CHECKSUM — that determine how the database engine validates the integrity of data pages read from and written to disk. CHECKSUM, introduced in SQL Server 2005 and the default ever since, calculates a checksum across the entire page when it is written and re-verifies it on read. TORN_PAGE_DETECTION is an older, less reliable method that only inspects a small number of bits per sector, and NONE performs no verification at all.
This issue arises when one or more databases are configured with PAGE_VERIFY set to NONE or TORN_PAGE_DETECTION, commonly found on databases that were originally created on SQL Server 2000 or earlier and later upgraded, since the upgrade process does not automatically change this setting.
Why is this a problem?
Without CHECKSUM, SQL Server cannot reliably detect many forms of I/O-related data corruption caused by faulty storage, controllers, drivers, or other hardware issues. TORN_PAGE_DETECTION only catches corruption that occurs mid-write across sector boundaries and misses corruption within a sector, while NONE provides no protection whatsoever.
The real danger is that corruption can silently accumulate and propagate into backups, meaning by the time a problem surfaces — often during a restore, a DBCC CHECKDB, or an application failure — you may no longer have a clean backup to recover from.
What should you do about this?
Change the page verification option to CHECKSUM on each affected database using ALTER DATABASE [DatabaseName] SET PAGE_VERIFY CHECKSUM WITH NO_WAIT;. This command is lightweight and executes quickly, but it only applies CHECKSUM to pages going forward — existing pages retain their original verification method (or none at all) until they are rewritten. To apply CHECKSUM protection to all existing pages immediately, rebuild all indexes and heaps in the database, understanding that this is an I/O and log-intensive operation that should be scheduled during a maintenance window.
Also ensure your full and differential backups are taken with the WITH CHECKSUM option so that corruption is detected during backup operations, and run DBCC CHECKDB regularly to catch any existing corruption.