How to troubleshoot Msg 832 (constant page has changed) in SQL Server
Symptoms
The SQL Server Engine may write out to the ERRORLOG file the following error when it detects a database page has been modified unexpectedly while in cache:
Error: 832, Severity: 24, State: 1.
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.
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.
Cause
Some "external" condition 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 where the memory backing the database page is incorrect modified or damaged
Resolution
The 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.
More Information
Only pages that are not currently modified in cache (or "dirty") are checked. This 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 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. This 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