March 3, 2010 at 10:44 am
Hi, i posted a few days ago in general discussion about a problem i was having with the databases on our server, with an incorrect checksum error that kept appearing even after repairing.
Reference: http://www.sqlservercentral.com/Forums/Topic874370-149-1.aspx
After taking some advice i looked into seeing what could be causing the problem. This lead me to installing SQLIOSim utility into seeing what could be going wrong. Program installed no problem, ran a check filtered back some reports yet i have no idea what i'm looking for.
I'm wondering if anyone can point me in the right direction if they've used this utility before, pretty much stuck between a rock and a hard place at the moment.
thanks in advance
March 3, 2010 at 11:16 am
Picking up the thread here, can you share some of the CHECKDB output please? Were the checksum failures re-appearing on the same databases? Are the databases stored on the same I/O subsystem? Can you share the list of page IDs that the checksum failures happened on?
Thanks
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
March 8, 2010 at 5:35 am
Hi Paul, sorry for the late reply.
The error returns with the following:
Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x971e7bfa; actual: 0x971e73fa). It occurred during a read of page (1:486758) in database ID 34 at offset 0x000000edacc000 in file 'D:\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MEDHOTELS_v2.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 consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
However running 'DBCC CHECKDB (MEDHOTELS_v2) WITH NO_INFOMSGS, ALL_ERRORMSGS' doesn't return any error messages.
The error is not consistent, as in one day it won’t produce an error, and the next day it will produce the above, sometimes with or without any error messages when running dbcc checkdb.
The server is new, and was activated a few days prior to sql server installation.
March 8, 2010 at 9:30 am
Do you have any index maintenance that runs nightly, or is the data in the tables very volatile? I think you're seeing 'disappearing corruptions' - real corruptions but the pages gets deallocated before CHECKDB can run. See Misconceptions around corruptions: can they disappear?.
You need to run memory and I/O subsystem diagnostics - something in your hardware is causing these.
Thanks
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
March 8, 2010 at 10:09 am
The data that's held inside the tables, as you can probably tell by the database name, contains basic information on accommodation (Name, check-in date, duration, price... etc). We insert into a table from an overnight 'xml scrape/parsing', where in the morning after the scrape/parse has finished we manipulate the data and insert into a larger table, which holds info that is continuously updated/refreshed over a 2/3 day cycle.
When people suggest if we will miss the data if we run the 'allow nulls repair', it isn't a big of a deal as most might think. If we lose some data, we'll pick it up again in a day or two. So far we've noticed we aren't losing any records when we run a repair_allow_nulls report.
How do you suggest we check the I/O subsystems? I've ran that SQLIOSim utility, but to be honest i'm not sure what i should be looking at.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply