March 15, 2007 at 8:37 am
Hello,
Did anyone familiar with these errors:
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x1a00d2fd; actual: 0x1a02d2fd). It occurred during a read of page (1:103329) in database ID 11 at offset 0x00000032742000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\Server01.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database c (Source: MSSQLServer, Error number: 824)
Get help: http://help/824
Thank you
TJ
March 15, 2007 at 10:15 am
TJ
Sounds like you have a corruption in your database and you need to run DBCC CHECKDB.
John
March 15, 2007 at 10:24 am
Call PSS. Consistency errors are not worth screwing with.
March 15, 2007 at 2:28 pm
I saw this when I ran SQL in a VM and it was running a heavy load. I moved the application to a physical server and the problem went away.
March 15, 2007 at 3:38 pm
John,
I run:
DBCC CHECKDB ('Server01', NOINDEX)
DBCC CHECKDB ('Server01', REPAIR_FAST)
DBCC CHECKDB ('Server01', REPAIR_REBUILD)
have several errors on certain tables.
March 15, 2007 at 3:40 pm
Steve, I'm newbee. Not sure what is PSS?
March 16, 2007 at 2:04 am
Do you have a backup you can restore from without losing more than an acceptable amount of data?
March 19, 2007 at 1:40 am
SQL 2005 has an feature called CHECKSUM. CheckSum is calculated for each database page whenever any modifcations are done on that page. The checksum is also stored on same page.
The error that you got simply means, something has happened on that page, while writing/reading from actual disk. hence the current checksum is not matching the chekcksum value stored on the page.
These are signs of Database corruption.
As I explained to you above, there issue is that the page read from Disk is not same as what SQL asked to write to disk. so it is worth investigating the H/W doing IO(in this case a Virtual enviornment).
you can call up PSS (PSS == SQL Server Product Support Group), they would ask you to run checkdb , and if there are corruption messages, you need to either fix them by using repair options
or revert to a clean backup.
Also, the issue might be because of some limitations of Virtual enviornment. Be aware that MS may not support investigating a corruption issue under a third party Virtualization software.
March 19, 2007 at 1:42 am
Some more reading from SQL 2005 BOL:
Alter database command
...
PAGE_VERIFY { CHECKSUM | TORN_PAGE_DETECTION | NONE }
Discovers damaged database pages caused by disk I/O path errors. Disk I/O path errors can be the cause of database corruption problems and are generally caused by power failures or disk hardware failures that occur at the time the page is being written to disk.
CHECKSUM
Calculates a checksum over the contents of the whole page and stores the value in the page header when a page is written to disk. When the page is read from disk, the checksum is recomputed and compared to the checksum value stored in the page header. If the values do not match, error message 824 (indicating a checksum failure) is reported to both the SQL Server error log and the Windows event log. A checksum failure indicates an I/O path problem. To determine the root cause requires investigation of the hardware, firmware drivers, BIOS, filter drivers (such as virus software), and other I/O path components.
....
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply