March 1, 2011 at 7:42 pm
Yesterday one of my clients servers did a non-fatal stack dump with the message: CPerIndexMetaQS:: ErrorAbort - Index corruption.
From the dump files I was able to identify the database, table and index, but a DBCC CHECKTABLE(tablename) and DBCC CHECKALLOC(dbname) didn't return any errors. That evening I did a DBCC CHECKDB which also came up clean.
Has anyone come across a disappearing Index Corruption issue? The only thing that makes sence to me is one process was busy creating indexes and splitting pages etc. while another process was accessing the indexes and the locking wasn't keeping the 2nd process out. Once process one was finished everything was correct again. If this is possible it's a significant bug, but I haven't found anything covering this scenario on the internet.
The server is running SQL Server 2005 with SP 2. I know it's out of date, but my client is very slow to patch.
Any pointers would be appreciated.
Thansk
Leo
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated.
March 1, 2011 at 11:46 pm
Post the complete errors please.
Yes, 'dissapearing' corruption is possible, go read Paul Randal's blog posts on that.
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
March 2, 2011 at 1:24 pm
GilaMonster (3/1/2011)
Post the complete errors please.Yes, 'dissapearing' corruption is possible, go read Paul Randal's blog posts on that.
That was the complete error.
Besides all the details in the dump files, and the database, table and index involved the rest is just noise.
Cheers
Leo
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated.
April 27, 2011 at 12:47 pm
I have the same problem in one of our user database, same corruption error message, memory dump, etc.. but checkdb is clean.
I am going to try checkdb with REPAIR_REBUILD to see if that fix it but will take some time to get schedule maint time to run this in production.
if your issue is not in production, try REPAIR_REBUILD and let us know of the results, I will post my results as well.
cheers...
April 27, 2011 at 1:56 pm
shaneat (4/27/2011)
I am going to try checkdb with REPAIR_REBUILD to see if that fix it but will take some time to get schedule maint time to run this in production.if your issue is not in production, try REPAIR_REBUILD and let us know of the results, I will post my results as well.
Don't bother. If checkDB found no errors then it's a waste of time to try and repair errors that aren't there.
As Paul's blog states, it is possible to have corruption 'disappear' if something happened to deallocate the affected pages between the error and the checkDB.
If it reoccurs, start a new thread and post the message from the dump.
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
August 4, 2015 at 8:17 am
Hi,
When it comes to this message, it doesn't necessarily mean a problem with an object or index.
Please check the following articles:
https://support.microsoft.com/en-us/kb/2451688
https://support.microsoft.com/en-us/kb/2878968
Event though there is not a direct solution, those articles provide light over a very annoying error, and you can verify the "Symptoms" and "Cause" sections, looking for the scenario that applies to your case.
Hope this could help.
Regards,
W.-
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply