InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comFri, 24 May 2013 07:03:43 GMT20http://www.sqlservercentral.com/Forums/Topic727037-266-1.aspx[quote][b]Holger Degroot (6/2/2009)[/b][hr]Hi Paul,yes it was the first and only error.[/quote]If that's the case, I would suggest two things before you try a fix.1) Evaluate your IO subsystem - check for errors in event logs or RAID error logs2) Get that database onto different disks or a different IO system completely.If you've got new corruptions appearing then there's a serious problem here.Wed, 03 Jun 2009 00:45:29 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxHi Paul,yes it was the first and only error.I will try to use the English MMS console to post English messages (sorry for that)i will start to rebuild and repair the other errors and then give a feedback.holger degrootTue, 02 Jun 2009 22:18:44 GMTHolger Degroothttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxIf that was the only error in the original CHECKDB output, then no, they weren't masked - as the catalog checks that produce that error are run after the checks that produced the second set of errors.Holger - was the 8992 error the *only* error in the first set of CHECKDB results? if so, these are new corruptions.Having it all in German isn't helping things either (no fault of yours Holger!).Tue, 02 Jun 2009 17:29:25 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxPaul, could the previous error have been hiding these, or do you think they're new corruptions?Tue, 02 Jun 2009 17:20:44 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxThese are all record corruptions in nonclustered index ID 4. My guess is your IO subsystem is causing corruption, which was what corrupted the system table too.You should be able to offline rebuild the index to fix this, otherwise you're looking at drop/create or repair to rebuild it. If these are the only corruptions, there's no point restoring from your backups the nonclustered index is redundant data anyway.You also need to find out what's causing these corruptions so you can fix it so they don't happen again to something more critical that can't be repaired.Tue, 02 Jun 2009 17:16:43 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspx[quote][b]Holger Degroot (6/2/2009)[/b][hr]hi Gail,this worked out. Thankx a LOT!!!![/quote]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.Tue, 02 Jun 2009 17:00:15 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxhi 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 1Tabellenfehler: 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 1Objekt-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 1Tabellenfehler: 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 1Tabellenfehler: 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 1Tabellenfehler: 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:-)Tue, 02 Jun 2009 10:43:19 GMTHolger Degroothttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxHi Gail,yes, hopefully DBCC CHECKDB works now.The Statement delivers one entry: table and the field-/value/entryDROP STATISTICS gwdatastruct._WA_Sys_DataFormat_523AD7D5 works alsoand now checking the Database again.Will inform you in about 15 minutes.Thanks for now.Kind regardsHolger DegrootTue, 02 Jun 2009 09:56:09 GMTHolger Degroothttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxHey Gail - I keep forgetting that trick you used last time too - cool if that works.Tue, 02 Jun 2009 09:37:25 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxHolger, 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.[code]select object_name(object_id), name, stats_id from sys.stats where object_id = 1379588053 and stats_id = 3[/code]Tue, 02 Jun 2009 09:02:03 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxWhat 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 occured2) extract out the data into a new database, or just live with DBCC CHECKDB always raising this error3) 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.Tue, 02 Jun 2009 08:38:40 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspx>>>>>>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 thenit says it will loose the access to the table gWDataStructThanks for your help.Kind regards Holger DegrootTue, 02 Jun 2009 00:13:07 GMTHolger Degroothttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxDid there used to be another index? Was it dropped properly?Mon, 01 Jun 2009 23:45:38 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxHi, the object id identifies a table named: gwDataStruct.select Object_name(1379588053) brings gwdataStructUnfortunately there are only 2 indexes and non of them has id 3Can you help what lob_data_space_id=4194304means because i cannot find this in the databaseselect object_name(4194304) results NULLis Lob_data_space_id important?Thanks for your helpHolger DegrootMon, 01 Jun 2009 23:35:43 GMTHolger Degroothttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspx@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 [url=http://www.sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-13-Difference-between-database-version-and-database-compatibility-level.aspx]Search Engine Q&A #13: Difference between database version and database compatibility level[/url]Mon, 01 Jun 2009 18:18:05 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxPaul, 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.Mon, 01 Jun 2009 18:09:25 GMTRobert L Millerhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxCompatibility 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.ThanksMon, 01 Jun 2009 17:24:16 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxHi, 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 DegrootMon, 01 Jun 2009 16:44:05 GMTHolger Degroothttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxIs 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?ThanksMon, 01 Jun 2009 16:05:40 GMTPaul Randalhttp://www.sqlservercentral.com/Forums/Topic727037-266-1.aspxHi 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 myapplication and then run a dbcc checkdb, that prompted the following problem:[b]Meldung 8992, Ebene 16, Status 1, Zeile 1Meldung 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.[/b]What does the error mean?Searching some phrases in forums, at Microsoft or google - I cannot find anything helpful.Running the statementselect * from sysindexes gives me back rows from the databaserunning the statementdbcc checktable(SYSINDEXES) says that the table is not available or existent (is this normal?)Even changing the database to single_user_mode and runningDBCC CHECKDB (mydatabase, Repair_Rebuild)brings the same error.I´ve starte recovering my backups since the last 4 weeks and now I am running outof 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 Degrootcom:con solutions GmbHcallto://holgerdegroot(skype: holgerdegroot)Mon, 01 Jun 2009 15:55:35 GMTHolger Degroot