September 4, 2008 at 9:14 am
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'.
September 4, 2008 at 9:36 am
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
September 4, 2008 at 9:23 pm
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.
September 5, 2008 at 12:04 am
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
September 21, 2008 at 11:03 pm
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
September 21, 2008 at 11:22 pm
Also try this.....
DBCC CHECKTABLE('audit_record',REPAIR_FAST) can not fix this problem.
DBCC CHECKTABLE('audit_record',REPAIR_ALLOW_DATA_LOSS)
September 22, 2008 at 1:23 am
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/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
September 23, 2008 at 5:57 pm
If its nonclustered index try dropping & recreating it .
October 14, 2008 at 1:46 am
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