Consistency error using DBCC CheckDB

Hi,
when I run DBCC CHECKDB against one of my call databases it tells me there
are two consistency errors and 0 allocation errors. The minimum repair
option is REPAIR_REBUILD.
So I have my db in single user mode and I execute:
dbcc checkdb ('Leigh_Call2', REPAIR_REBUILD) WITH ALL_ERRORMSGS
this returns:
Server: Msg 1505, Level 16, State 1, Line 1
CREATE UNIQUE INDEX terminated because a duplicate key was found for index
ID 1. Most significant primary key is '17847'.
DBCC results for 'Leigh_Call2'.
....
DBCC results for 'CallDataItemEnumeratedStaging'.
There are 201627 rows in 2000 pages for object
'CallDataItemEnumeratedStaging'.
Server: Msg 8936, Level 16, State 1, Line 1
Table error: Object ID 1106102981, index ID 1. B-tree chain linkage
mismatch. (1:21981)->next = (1:21983), but (1:21983)->Prev = (1:22065).
Server: Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 1106102981, index ID 1. Page (1:22065) is missing a
reference from previous page (1:21981). Possible chain linkage problem.
....
DBCC results for 'CallEventStaging'.
Could not repair this error.
Repairing this error requires other errors to be corrected first.
There are 178358 rows in 1487 pages for object 'CallEventStaging'.
CHECKDB found 0 allocation errors and 2 consistency errors in table
'CallEventStaging' (object ID 1106102981).
....
CHECKDB found 0 allocation errors and 2 consistency errors in database
'Leigh_Call2'.
repair_rebuild is the minimum repair level for the errors found by DBCC
CHECKDB (Leigh_Call2 repair_rebuild).
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
The statement has been terminated.
This seems to be the error portion of the results returned.
Each time I run it the name of the table with the problem changes.
Is this pointing to perhaps some physical corruption on the disks?
Info, views and opinions appreciated.
Martin
The repair is trying to rebuild the index - obviously that's failing because
of the duplicate key violation.
My guess as to what's causing dbcc to report these issues are stale reads
from your disk controller and there's an active workload on the database
that's causing page splits in various tables. I bet if you shut everything
down and power it back up then a checkdb will come back clean for the
database. If so, you need to run diagnostics on your IO subsystem and make
sure all the firmware is up to date.
Thanks
Paul Randal
Principal Lead Program Manager
Core Storage Engine, Microsoft SQL Server Team
http://blogs.msdn.com/sqlserverstorageengine/default.aspx
"Martin Selway" <martin.selway@.csdss.com> wrote in message
news:uxahkybOHHA.3900@.TK2MSFTNGP06.phx.gbl...
> Hi,
> when I run DBCC CHECKDB against one of my call databases it tells me there
> are two consistency errors and 0 allocation errors. The minimum repair
> option is REPAIR_REBUILD.
> So I have my db in single user mode and I execute:
> dbcc checkdb ('Leigh_Call2', REPAIR_REBUILD) WITH ALL_ERRORMSGS
> this returns:
> Server: Msg 1505, Level 16, State 1, Line 1
> CREATE UNIQUE INDEX terminated because a duplicate key was found for index
> ID 1. Most significant primary key is '17847'.
> DBCC results for 'Leigh_Call2'.
> ...
> DBCC results for 'CallDataItemEnumeratedStaging'.
> There are 201627 rows in 2000 pages for object
> 'CallDataItemEnumeratedStaging'.
> Server: Msg 8936, Level 16, State 1, Line 1
> Table error: Object ID 1106102981, index ID 1. B-tree chain linkage
> mismatch. (1:21981)->next = (1:21983), but (1:21983)->Prev = (1:22065).
> Server: Msg 8978, Level 16, State 1, Line 1
> Table error: Object ID 1106102981, index ID 1. Page (1:22065) is missing a
> reference from previous page (1:21981). Possible chain linkage problem.
> ...
> DBCC results for 'CallEventStaging'.
> Could not repair this error.
> Repairing this error requires other errors to be corrected first.
> There are 178358 rows in 1487 pages for object 'CallEventStaging'.
> CHECKDB found 0 allocation errors and 2 consistency errors in table
> 'CallEventStaging' (object ID 1106102981).
> ...
> CHECKDB found 0 allocation errors and 2 consistency errors in database
> 'Leigh_Call2'.
> repair_rebuild is the minimum repair level for the errors found by DBCC
> CHECKDB (Leigh_Call2 repair_rebuild).
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> The statement has been terminated.
> This seems to be the error portion of the results returned.
> Each time I run it the name of the table with the problem changes.
> Is this pointing to perhaps some physical corruption on the disks?
> Info, views and opinions appreciated.
> Martin
>
sqlsql