spid61 Could not find the index entry for RID '16afe06e0100000000ed170000020000' in index page (1:16904330), index ID 2, database 'SCADAHistorical'

  • Hi all,

    Im facing with this error , when i saw in error logs. the same error facing with three production server and the database went to suspect mode.Can anyone please give remedy and root cause analysis

    2008-09-03 06:19:45.21 spid61 Error: 644, Severity: 21, State: 5

    2008-09-03 06:19:45.21 spid61 Could not find the index entry for RID '16afe06e0100000000ed170000020000' in index page (1:16904330), index ID 2, database 'SCADAHistorical'..

    2008-09-03 06:19:45.31 spid61 Error: 644, Severity: 21, State: 5

    2008-09-03 06:19:45.31 spid61 Could not find the index entry for RID '16afe06e0100000000ed170000020000' in index page (1:16904330), index ID 2, database 'SCADAHistorical'.

  • The databases are marked suspect and are not accessible? Do you have up-to-date backups?

    Just to confirm, you are using SQL 2005?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Hi gail, thank you for responding. We are having up to date backups. we are restoring from them by deleting sespect mode database nad creating new database with same name and restoring. can you plz help , what will be root cause of the above error.

  • Usually hardware.

    http://www.sqlskills.com/blogs/paul/2008/08/27/SearchEngineQA26MythsAroundCausingCorruption.aspx

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • this error comes when 1 of ur data in the tables gets corrupted or wen 1 of ur index gets corrupted....

    Try this ....

    ALTER DATABASE name SET EMERGENCY

    GO

    ALTER DATABASE name SET SINGLE_USER

    GO

    DBCC CHECKDB (name, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS

    GO

  • Also try this.....

    DBCC CHECKTABLE('audit_record',REPAIR_FAST) can not fix this problem.

    DBCC CHECKTABLE('audit_record',REPAIR_ALLOW_DATA_LOSS)

  • samsql (9/21/2008)


    Also try this.....

    DBCC CHECKTABLE('audit_record',REPAIR_FAST) can not fix this problem.

    DBCC CHECKTABLE('audit_record',REPAIR_ALLOW_DATA_LOSS)

    Do not, do not, do not run repair as the first thing tried when dealing with corruption. It should be the very last resort considered when there's no other options left.

    The preferred and recommended way for fixing corruption is to restore a backup.

    Repair_allow_data_loss, as it's name implies, will lose data. What and how much depends on the corruption. When it discards data it will not take foreign keys into account and you may be left with inconsistent data in the database

    See the following two blog posts:

    http://www.sqlskills.com/blogs/paul/2007/10/02/CHECKDBFromEveryAngleEMERGENCYModeRepairTheVeryVeryLastResort.aspx

    http://www.sqlskills.com/blogs/paul/2007/09/15/CorruptionLastResortsThatPeopleTryFirst.aspx

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • If its nonclustered index try dropping & recreating it .

  • Index id 2 generally a non cluster index you can drop this index and recreate it.

    "More Green More Oxygen !! Plant a tree today"

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply