June 1, 2009 at 3:55 pm
Hi to everyone,
i have a serious problem.
I am running an MS SQL Server 2005 with SP3 (4035). Today I have experienced some problems with my
application and then run a dbcc checkdb, that prompted the following problem:
Meldung 8992, Ebene 16, Status 1, Zeile 1
Meldung 3855 zum Prüfen des Katalogs, Status 1: Das Attribut (lob_data_space_id=4194304) ist ohne eine Zeile (object_id=1379588053,index_id=3) in sys.indexes vorhanden.
What does the error mean?
Searching some phrases in forums, at Microsoft or google - I cannot find anything helpful.
Running the statement
select * from sysindexes
gives me back rows from the database
running the statement
dbcc checktable(SYSINDEXES)
says that the table is not available or existent (is this normal?)
Even changing the database to single_user_mode and running
DBCC CHECKDB (mydatabase, Repair_Rebuild)
brings the same error.
I´ve starte recovering my backups since the last 4 weeks and now I am running out
of opportunities :angry:
Does anyone have a clue where to check or if this error is repairable?
Thanks in Advance for help and hints.
Kind regards
Holger Degroot
com:con solutions GmbH
callto://holgerdegroot
(skype: holgerdegroot)
June 1, 2009 at 4:05 pm
Is this the first time you've run DBCC CHECKDB since upgrading to 2005? I'm guessing your answer is going to be no, as I believe this is a post-upgrade corruption. It's saying that the metadata for the referenced object is corrupt.
Google this error goes straight to the Books Online entry for it: http://msdn.microsoft.com/en-us/library/aa337359.aspx (but maybe not Googling in German). This error cannot be repaired by DBCC.
Sys.indexes is not a table in 2005. It's a view, which combines some hidden system tables, and some internal code to output what used to be sysindexes.
You have some choices for recovery, as the BOL entry says: restore or extract out. At a push you might be able to repair this manually, but I don't recommend doing that. As the very first thing to try, I would either rebuild or drop/create that nonclustered index.
You then have to figure out what happened. First off, was this the first DBCC CHECKDB after upgrading from 2000?
Thanks
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
June 1, 2009 at 4:44 pm
Hi,
no it wasnt the first time. but i´ve noticed that the database was running in compatibilty mode (sql 8 2000) and then i have changed it to native (sql 2005) mode. I changed it back several times and then running dbcc checkdb, but it didn´t work my way.
What table/index should I rebuild/drop/re-create?
I think I now what happened. The database is part of a German CRM system which uses own replication algorythm. on friday there were some suspicious error messages i think which will have caused the desaster now. The main system and main database has the errors, the replication partner which uses a full replication (fyi: no MS SQL replication!) has no errors running dbcc checkdb.
What is very strange is that I used backup files and restored the database from over the last two weeks and now they fail, too - thats what I don´t understand.
Perhaps you can tell me what my possibilities to recreate or rebuild the indexes.
Thank you.
Holger Degroot
June 1, 2009 at 5:24 pm
Compatibility mode has nothing to do with the database version, just a few bits of query behavior.
Rebuild index 3 of table 1379588053. You can get the names using OBJECT_ID and INDEX_ID.
Not a repl expert but I don't believe it would cause this, and the application simply can't cause it.
Thanks
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
June 1, 2009 at 6:09 pm
Paul,
Would there not be some issues caused by the OP's attempt to bounce the database version from 2000 to 2005 and then back to 2000?
Then again, this might just be pure hardware issue.
June 1, 2009 at 6:18 pm
@rlm - no, because OP didn't do that. He (from the name) changed the compatibility level of the database. You can't change the version of the database. They are not the same.
See Search Engine Q&A #13: Difference between database version and database compatibility level
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
June 1, 2009 at 11:35 pm
Hi,
the object id identifies a table named: gwDataStruct.
select Object_name(1379588053) brings gwdataStruct
Unfortunately there are only 2 indexes and non of them has id 3
Can you help what
lob_data_space_id=4194304
means because i cannot find this in the database
select object_name(4194304) results NULL
is Lob_data_space_id important?
Thanks for your help
Holger Degroot
June 1, 2009 at 11:45 pm
Did there used to be another index? Was it dropped properly?
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
June 2, 2009 at 12:13 am
>>>>>>Did there used to be another index?
No, comparing to the other system it looks the same.
there are only two indexes for the table gwDataStruct
>>>>>>Was it dropped properly?
I did not drop the two existing indexes, because then
it says it will loose the access to the table gWDataStruct
Thanks for your help.
Kind regards
Holger Degroot
June 2, 2009 at 8:38 am
What were the suspicious error messages you spoke of previously?
You've got a few, equally unpleasant choices:
1) restore back to a backup from before the corruption occured
2) extract out the data into a new database, or just live with DBCC CHECKDB always raising this error
3) manually hack the underlying system tables to remove the broken data.
I recommend #1 or #2. #3 is possible (I demo it at conferences) but I don't know which table you'd need to change to fix this particular problem.
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
June 2, 2009 at 9:02 am
Holger, does this query return anything? If so, try a drop statistics with the name returned and see if that fixes the problem. Absolutely no promises.
select object_name(object_id), name, stats_id from sys.stats where object_id = 1379588053 and stats_id = 3
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
June 2, 2009 at 9:37 am
Hey Gail - I keep forgetting that trick you used last time too - cool if that works.
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
June 2, 2009 at 9:56 am
Hi Gail,
yes, hopefully DBCC CHECKDB works now.
The Statement delivers one entry: table and the field-/value/entry
DROP STATISTICS gwdatastruct._WA_Sys_DataFormat_523AD7D5 works also
and now checking the Database again.
Will inform you in about 15 minutes.
Thanks for now.
Kind regards
Holger Degroot
June 2, 2009 at 10:43 am
hi Gail,
this worked out. Thankx a LOT!!!!
now the followin errors appear:
I will treat them the same way and report later on.
DBCC-Ergebnis für 'SysSrvAccess'.
Es sind 2725 Zeilen auf 49 Seiten für das "SysSrvAccess"-Objekt vorhanden.
DBCC-Ergebnis für 'GWSYSMessages'.
Meldung 8978, Ebene 16, Status 1, Zeile 1
Tabellenfehler: Objekt-ID 1870017793, Index-ID 4, Partitions-ID 72057594130071552, Zuordnungseinheits-ID 72057594165723136 (In-row data-Typ). Für Seite (1:102) fehlt ein Verweis der Vorgängerseite (1:215041). Möglicherweise liegt ein Kettenverknüpfungsproblem vor.
Meldung 8928, Ebene 16, Status 1, Zeile 1
Objekt-ID 1870017793, Index-ID 4, Partitions-ID 72057594130071552, Zuordnungseinheits-ID 72057594165723136 (In-row data-Typ): Seite (1:215041) konnte nicht verarbeitet werden. Einzelheiten finden Sie in anderen Fehlermeldungen.
Meldung 8976, Ebene 16, Status 1, Zeile 1
Tabellenfehler: Objekt-ID 1870017793, Index-ID 4, Partitions-ID 72057594130071552, Zuordnungseinheits-ID 72057594165723136 (In-row data-Typ). Seite (1:215041) wurde im Scan nicht betrachtet, obwohl das übergeordnete Element (1:427259) und der Vorgänger (1:175) darauf verweisen. Überprüfen Sie ggf. alle vorherigen Fehler.
Meldung 8944, Ebene 16, Status 16, Zeile 1
Tabellenfehler: Objekt-ID 1870017793, Index-ID 4, Partitions-ID 72057594130071552, Zuordnungseinheits-ID 72057594165723136 (In-row data-Typ), Seite (1:215041), Zeile 46. Fehler bei Test (VarColOffsets + (int)(sizeof (class VarColOffset) * nVarCols) <= (nextRec - pRec)). Die Werte sind 58387 und 35.
Meldung 8944, Ebene 16, Status 16, Zeile 1
Tabellenfehler: Objekt-ID 1870017793, Index-ID 4, Partitions-ID 72057594130071552, Zuordnungseinheits-ID 72057594165723136 (In-row data-Typ), Seite (1:215041), Zeile 46. Fehler bei Test (VarColOffsets + (int)(sizeof (class VarColOffset) * nVarCols) <= (nextRec - pRec)). Die Werte sind 58387 und 35.
Es sind 36967 Zeilen auf 2454 Seiten für das "GWSYSMessages"-Objekt vorhanden.
Von CHECKDB wurden 0 Zuordnungsfehler und 5 Konsistenzfehler in der 'GWSYSMessages'-Tabelle (Objekt-ID 1870017793) gefunden.
DBCC-Ergebnis für 'DOCUMENTTEMPLORel'.
Es sind 165 Zeilen auf 6 Seiten für das "DOCUMENTTEMPLORel"-Objekt vorhanden.
Thanks for the moment.
Holger Degroot
🙂
June 2, 2009 at 5:00 pm
Holger Degroot (6/2/2009)
hi Gail,this worked out. Thankx a LOT!!!!
Excellent. I'm glad to hear that.
I don't understand the errors (sorry, don't speak or read German) so I can't advice you on them.
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
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply