Events
Mar 31, 11 PM - Apr 2, 11 PM
The biggest SQL, Fabric and Power BI learning event. March 31 – April 2. Use code FABINSIDER to save $400.
Register todayThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Applies to:
SQL Server
Attribute | Value |
---|---|
Product Name | SQL Server |
Event ID | 832 |
Event Source | MSSQLSERVER |
Component | SQLEngine |
Symbolic Name | B_CONSTPAGECHANGED |
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:
When SQL Server detects this behavior error 832 is raised.
To find the cause of the error, consider these options:
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.
Events
Mar 31, 11 PM - Apr 2, 11 PM
The biggest SQL, Fabric and Power BI learning event. March 31 – April 2. Use code FABINSIDER to save $400.
Register today