Applies to: SQL Server (all supported versions)
|Product Name||SQL Server|
|Message Text||A page that should have been constant has changed (expected checksum: <expected value>, actual checksum: <actual value>, database <dbid>, file '<filename>', page <pageno>). This usually indicates a memory failure or other hardware or OS corruption.|
An external factor has caused a database page to be modified outside the normal SQL Server engine code used to change database pages. The conditions could be:
- A thread running in the SQL Server process that incorrect writes on a database page. This is often referred to as a "scribbler"
- A hardware or operating system problem were the memory backing the database page is incorrect modified or damaged
When SQL Server detects this behavior error 832 is raised.
To find the cause of the error, consider these options:
- You should run any normal hardware or system checks to determine if a memory, CPU, or other hardware-related problem exists. Ensure all system drivers, Operating system updates, and hardware updates have been applied to our system. Consider running any hardware manufacture diagnostics including memory-related tests.
- Evaluate what "external" DLLs may be loaded in SQL Server that could cause this problem including extended stored procedures, COM objects, or other DLLs that may be incorrectly modifying SQL Server memory reserved for database pages.
Anytime you see this error, you should immediately consider running
DBCC CHECKDB against the database referenced by the <dbid> in the error message.
This error is detected by the background task often referred to as the LazyWriter. (The "command" for this task is seen as LAZY WRITER). Therefore, this error is not returned to a client application. The error will be written to the Windows Application Event Log as EventID=832.
Only pages that are not currently modified in cache (or "dirty") are checked. It is why the message uses the terms "constant" because the page has never been changed since it was read in from disk. Furthermore, the page was read in "clean" from disk because it has a checksum value on the page and has not encountered a checksum failure (Msg 824). However, the page could be modified at some point after this error, and then written to disk with the incorrect modification. If this error occurs, a new checksum is calculated based on all modifications before it is written to disk. Therefore, the page could be damaged on disk but a subsequent read from disk may not trigger a checksum failure. It is important to run
DBCC CHECKDB on any database that is referenced by this error.
It is possible that even
DBCC CHECKDB will not report an error for a page in this state after being written to disk. It is because the incorrect modification could be at locations on the page that don't hold any data, nor contain any important page or row structure information, or could be modifications to data that CHECKDB cannot detect.
More details and information about Msg 832 can also be read in the whitepaper SQL Server I/O Basics, Chapter 2.