I was reading a thread on SQL Server Central today where someone replied to a question and confused 823 with 832. Now, 823 is a nasty error to get – it says that an I/O operation failed at the OS level and the I/O subsystem is causing corruption – SQL Server didn't even get a chance to check the page checksum (and potentially raise an 824 error).
Error 832 is way worse. When you get one, you'll see an error like the following:
A page that should have been constant has changed (expected checksum: 1dcb28a7, actual checksum: 68c626bb, database 13, file 'E:\Program Files\microsoft sql server\MSSQL\data\BlahBlah.mdf', page (1:112644)). This usually indicates a memory failure or other hardware or OS corruption.
This error occurs *AFTER* a page has been read into memory. Once the page passes all checks as it's read in from disk, it's a known clean page sitting in the buffer pool. When the time comes to update the page and mark it as a dirty page, the checksum is checked again, juuuust to make sure. If the checksum is no longer valid, error 832 is raised. This is saying that something apart from SQL Server stomped on the page while it was in SQL Server's memory – either hardware memory corruption (bad RAM), an OS memory-management bug, or a rogue process writing into SQL Server's memory space.
It's really bad. If memory diagnostics don't show up any issues, there's a way to start to track down what's going on, but only by enabling an expensive trace-flag at server startup that prevents untoward accesses to SQL Server's memory unless an exclusive page latch is held. And this should only be enabled under Product Support's supervision.
One other thing to consider is taking out half the server's memory and running with one half for a few days, then swapping over and running with the other half – that may allow you to figure out which memory is bad. Newer servers also allow memory mirroring to reduce the likelihood of bad memory causing you actual data corruption, and server management software should be able to pinpoint a bad memory module.
So – hopefully you'll never see this – they're very rare – I've only seen a handful in my time. If you do, run memory diagnostics, and if nothing shows up, call PSS to help you out.
Hope this helps.
5 thoughts on “Don’t confuse error 823 and error 832”
You really should have saved this post for Halloween. Very spooky.
Does RESTORE a PAGE from thje backup fix the problem?
Well, I confused 832 with 824 not 823, but that’s just minor details ;-)
Was there a SQL 2000 version of this error?
Hey Uri – yes, single-page restore will fix it if the page is written to disk.
Hmm – not a checksum specific error, as checksums weren’t there. There was debug-only page image protection but nothing exposed in the released builds AFAIK.