Hi,

we have a strange problem on one of our server. It is an SQL 2008 R2 all updates are installed(SP3). The DB and log is about 2 GB, in the last weeks we get very often an curruption of an clustered index( PK of the table). If we drop and recreate it , the problemnormally is resolved, until the next time. But some times we get double values in the table, if we perform the following query before the PK is droped we get 0 rows but when we perfom it after we get results, some rows in the table are dupliated(about 20), always other but "old" rows which were not updated / accssed in the last time.

    SELECT * FROM table WHERE ID IN (
    SELECT ID FROM table GROUP BY ID HAVING COUNT(ID) > 1)

The type of the column is uniqueidentifier.

In the log we see following:

CPerIndexMetaQS::ErrorAbort - Index corruption
Unable to find index entry in index ID 1<c/> of table 5575058<c/> in database 'db'.
The indicated index is corrupt or there is a problem with the current update plan.

And the dump.

Query for PK:

ALTER TABLE [table] ADD  CONSTRAINT [PK_table] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, 
SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, 
ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON)

The HDD and RAM were checken and are ok.

Which other reasons can cause a corruption like this?

• Edited by KT-Support 2 hours 14 minutes ago

Corruption is almost always due to bad hardware. Typically issues in the I/O subsystem, but bad memory boards can also be a culrprit. The I/O subsystem is not only the disks themselves, but the whole slew of things in between: drivers, controllers etc. Are the disks local or on a SAN?

Since they are recurring problems, I would advice you to escape to different hardware.

Looks strange... Do you rebuild the index? Is that possible to create CI on another column, meaning adding an IDENTITY proper

Corruption is almost always due to bad hardware. Typically issues in the I/O subsystem, but bad memory boards can also be a culrprit. The I/O subsystem is not only the disks themselves, but the whole slew of things in between: drivers, controllers etc. Are the disks local or on a SAN?

Since they are recurring problems, I would advice you to escape to different hardware.

Hi,

thanks for the answer. It is an VM on VMware ESXi 5.1 but the server has his own HDDs, standard configuration, nothing special runs on other servers without problems(other Hardware), write cache in Windows disabled. An ecape to different hardware is expesive :-), would it make sens first to chage the NIC or would only be a waste of time?