Error: 8941 , Severity: 22, State:102
-
Hi :(,
when i run the following query from Q.A. :
Select distinct myfield1 from mytable (NoLock) Where myfield2 ='something'
I got the following error message :
Table Corrupt: Object ID 3862467, index ID 1, page (21:1722489215). Test (offset + len < PAGESIZE) failed. Slot 165, offset 0x1d63 is invalid.
I check this table with the following dbcc command and got no error (I checked its integrity but it didn't show me any table corruption)
DBCC CHECKTABLE ('mytable').
this table is one of our production db in our organization and i am so worry about it .Any help or suggestions will be appriciated.
SaNaZ
-
Sure you checked the correct object? I'd try DBCC CheckDB as well. Any recent hardware issues? I'd make sure you have a good backup (dont let your maint plan delete it or make sure its on tape, one prior to the problem if possible) and I'd try to get another backup, just in case.
Andy
-
I'd also bcp or DTS out the entire table to a text file to be sure you have it.
Then do a backup.
Then try rebuilding the clustered index (or creating one). Be sure you drop the existing one.
If you can't do this or have errors, call PSS. This is probably something they can help you with.
Steve Jones
-
As mentioned run "DBCC CHECKDB" on the database first of all and see what it recommends. Hopefully it says you should run the command again with the parameter "REPAIR_FAST" or "REPAIR_REBUILD". If it says that your only option is "REPAIR_ALLOW_DATA_LOSS" then you might be in more trouble. But even if it reports that you should still try and:
1. Run DBCC CHECKDB with the REPAIR_REBUILD
2. If it doesn't help drop and recreate any clustered and not clustered indexes on the table and run DBCC CHECKDB again.
3. If that doesn't help try and export the data to a file or temporary table and see if all data is ok.
If none of those work, find your latest full backup where your data is consistent (DBCC CHECKDB reports no errors). Once found restore that full backup on a test system. Then restore all transaction log backups you have, skipping any full backups made between (might only work in SQL 2000, not sure). Rerunning the transactions this way on a healthy system has helpt me once when the original system had hardware problems with the disk array.
Before bringing a backup back in to production, make sure to check that no hardware errors or similair exists.
And whenever in doubt, giving Microsoft PSS a call is usually a good idea 🙂
/Magnus
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply