DBCC CHECKDB ends with false positives

Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

All Forums

General SQL Server Forums

Data Corruption Issues

DBCC CHECKDB ends with false positives

Author

Topic

ChuckOlufson
Starting Member

4 Posts

Posted - 2010-03-27 : 20:51:40

We have numerous instances of false positives on our DBCC CHECKDB runs on our production SAP servers with SQL Server 2005. That is the CHECKDB founds consistency errors in one or more tables, but when a DBCC CHECKTABLE is run on that table or another DBCC CHECKDB is run it shows no errors. We run DBCC CHECKDB daily on our 2 production systems and get a false positive about every one or two weeks.
The DBCC CHECKDB runs from 5 to 6 hours.
Whenever we get a false positive usually one of these two errors has occured during the run:

spid189 DBCC CHECKDB is performing an exhaustive search of indexes for possible inconsistencies.

spid2s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [f:\pecdata2\pecdata2.ndf] in database [PEC]

Here is an example of the error log:

2010-03-11 22:47:17.49 spid135 DBCC CHECKDB (PEC) WITH no_infomsgs executed by RPU\SAPServicePEC found 4 errors and repaired 0 errors. Elapsed time: 5 hours 47 minutes 16 seconds.
2010-03-11 22:47:17.51 spid135 Using 'dbghelp.dll' version '4.0.5'
2010-03-11 22:47:17.60 spid135 **Dump thread - spid = 135, PSS = 0x00000001B875DBD0, EC = 0x00000001B875DBE0
2010-03-11 22:47:17.60 spid135 ***Stack Dump being sent to F:\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\SQLDump0018.txt
2010-03-11 22:47:17.60 spid135 * *******************************************************************************
2010-03-11 22:47:17.60 spid135 *
2010-03-11 22:47:17.60 spid135 * BEGIN STACK DUMP:
2010-03-11 22:47:17.60 spid135 * 03/11/10 22:47:17 spid 135
2010-03-11 22:47:17.60 spid135 *
2010-03-11 22:47:17.60 spid135 * DBCC database corruption
2010-03-11 22:47:17.60 spid135 *
2010-03-11 22:47:17.60 spid135 * Input Buffer 86 bytes -
2010-03-11 22:47:17.60 spid135 * DBCC CHECKDB WITH NO_INFOMSGS;
2010-03-11 22:47:17.60 spid135 *
2010-03-11 22:47:17.60 spid135 * *******************************************************************************
2010-03-11 22:47:17.60 spid135 * -------------------------------------------------------------------------------
2010-03-11 22:47:17.60 spid135 * Short Stack Dump
2010-03-11 22:47:17.91 spid135 Stack Signature for the dump is 0x00000000000002CC
2010-03-11 22:47:20.96 spid135 External dump process return code 0x20000001.

And what job log looks like:

Job 'CheckDB' : Step 1, 'Check Database' : Began Executing 2010-03-11 17:00:00

Msg 8928, Sev 16, State 1, Line 1 : Object ID 1789795471, index ID 1, partition ID 72057602467495936, alloc unit ID 72057602585395200 (type In-row data): Page (1:2387521) could not be processed. See other errors for details. [SQLSTATE 42000]
Msg 8939, Sev 16, State 1, Line 1 : Table error: Object ID 1789795471, index ID 1, partition ID 72057602467495936, alloc unit ID 72057602585395200 (type In-row data), page (1:2387521). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 180488201 and -4. [SQLSTATE 42000]
Msg 8976, Sev 16, State 1, Line 1 : Table error: Object ID 1789795471, index ID 1, partition ID 72057602467495936, alloc unit ID 72057602585395200 (type In-row data). Page (1:2387521) was not seen in the scan although its parent (1:2387779) and previous (1:2387520) refer to it. Check any previous errors. [SQLSTATE 42000]
Msg 8978, Sev 16, State 1, Line 1 : Table error: Object ID 1789795471, index ID 1, partition ID 72057602467495936, alloc unit ID 72057602585395200 (type In-row data). Page (1:2387522) is missing a reference from previous page (1:2387521). Possible chain linkage problem. [SQLSTATE 42000]
Msg 8990, Sev 16, State 1, Line 1 : CHECKDB found 0 allocation errors and 4 consistency errors in table 'pec.DSYS_PHCONT_E_CD' (object ID 1789795471). [SQLSTATE 01000]
Msg 8989, Sev 16, State 1, Line 1 : CHECKDB found 0 allocation errors and 4 consistency errors in database 'PEC'. [SQLSTATE 01000]
Msg 8958, Sev 16, State 1, Line 1 : repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (PEC). [SQLSTATE 01000]

What is the reason for so many false positives?
Is DBCC CHECKDB an unreliable way to check the databases?
Any suggestions?
Thanks!

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2010-03-27 : 20:54:27

You've got slow disks (the I/O warning), but that shouldn't cause data corruption. The stack dump is a concern though. You need to open a case with Microsoft to figure out why you are getting this. But for first make sure you are running service pack 3 for SQL2k5 and the latest cumulative update package. If you aren't running it already, you could be encountering a bug that has already been fixed.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2010-03-27 : 21:03:21

quote:

Is DBCC CHECKDB an unreliable way to check the databases?

No, your system is having issues that need to be addressed.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2010-03-28 : 05:02:26

Are you sure they're false positives? Are you doing anything like index rebuilds between the checkDB that gives errors and the checkDB that doesn't?

--
Gail Shaw
SQL Server MVP

ChuckOlufson
Starting Member

4 Posts

Posted - 2010-03-30 : 00:58:49

quote:
Originally posted by GilaMonster

Are you sure they're false positives? Are you doing anything like index rebuilds between the checkDB that gives errors and the checkDB that doesn't?

--
Gail Shaw
SQL Server MVP

They are false positives, because without doing anything another CheckDB run right away comes clean with no errors.

ChuckOlufson
Starting Member

4 Posts

Posted - 2010-03-30 : 01:15:51

We are running service pack 3 for SQL2k5.
After we have a false positive that system may go a week or up to a month with daily checkDB running with no errors. We have two systems that this is happening. We have other systems running daily checkDB, that have never had this problem, but they have smaller databases or not as much activity as the systems with the problem.

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2010-03-30 : 01:17:37

I'd open a case with Microsoft on this then as even the possibility of data corruption is too risky. I'm thinking something is going on with your disks.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2010-03-30 : 05:28:58

quote:
Originally posted by tkizer

I'd open a case with Microsoft on this then as even the possibility of data corruption is too risky. I'm thinking something is going on with your disks.

Agreed. If checkDB reports errors it means that it found errors.

Are you seeing any 825 errors in your error log? They're severity 10, so the standard alerts won't pick them up.

--
Gail Shaw
SQL Server MVP

ChuckOlufson
Starting Member

4 Posts

Posted - 2010-04-01 : 01:15:44

We are not having any 825 errors.

Subscribe to SQLTeam.com

SQLTeam.com Articles via RSS

SQLTeam.com Weblog via RSS

- Advertisement -

Resources