InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 20 Jun 2013 01:37:42 GMT20http://www.sqlservercentral.com/Forums/Topic1081039-266-1.aspx[quote][b]zavhrye (5/17/2012)[/b][hr]This is because of the db being a subscriber any intelligent answer would be appreciated. Thanks.[/quote]No, it's not because the database is a subscriber, it's because your database is fatally corrupt. Restoring a backup or reinitialising the subscriber is your only option here.Thu, 17 May 2012 10:03:49 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1081039-266-1.aspxexact same thing happened to me, I'm having problems turning the db back online and we have NO BACKUP. Tried using DBCC CHECKDB (Reporting,REPAIR_ALLOW_DATA_LOSS) but it failed and encountered this error:"DBCC CHECKDB Msg 8930, Level 16, State 11, Line 1Database error: Database 12 has inconsistent metadata. This error cannot be repaired and prevents further DBCC processing. Please restore from a backup.Msg 8921, Level 16, State 1, Line 1Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors." This is because of the db being a subscriber any intelligent answer would be appreciated. Thanks.Thu, 17 May 2012 09:57:29 GMTzavhryehttp://www.sqlservercentral.com/Forums/Topic1081039-266-1.aspxThanks Gail,We will look deeper in the error logs,and get back to you :-)Thnks Again.YKSun, 20 Mar 2011 15:56:36 GMTImage IThttp://www.sqlservercentral.com/Forums/Topic1081039-266-1.aspx[quote][b]Image IT (3/20/2011)[/b][hr]Which I/O subsystems you mean? [/quote]The one that the suspect database is stored on.[quote]Can it be because of the replication configuration? [/quote]Highly unlikely.Suspect means SQL encountered data or log file damage during crash recovery or during a rollback[quote]Because its a replicated sever, what u think will be easiest:1. to try and recover the suspect DB2. to reinitialize the replication all over again (off course after try and find out the reason of the "suspect" situation)?[/quote]Without seeing the messages in the error log that explained why SQL marked the DB as suspect I would rather not theorise on an optimal recovery.Sun, 20 Mar 2011 15:50:41 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1081039-266-1.aspxThanks Gail,I have more questions:Which I/O subsystems you mean? (our server or the server holds the distribution & subscriber DB)Can it be because of the replication configuration? Because its a replicated sever, what u think will be easiest:1. to try and recover the suspect DB2. to reinitialize the replication all over again (off course after try and find out the reason of the "suspect" situation)?Thanks in advance.YKSun, 20 Mar 2011 15:47:11 GMTImage IThttp://www.sqlservercentral.com/Forums/Topic1081039-266-1.aspxLook in the SQL error log. There will be messages detailing why SQL marked the DB suspect.Most common - data corruption caused by IO subsystem problems.Sun, 20 Mar 2011 15:28:15 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1081039-266-1.aspxHI,We are running a transactional replication between 2 servers (push subscriber). both the distribution and subscriber DB rely on the same server.for some reason the distribution DB became "Suspect" and cannot be reached, stoping the subscriber from being update.What could be the reasons of the situation?The Distribution server, is under low-level usage (few users use it),we did not find anything weird in the sql server error logs, or the windows error log.WE didnt find any HW failure, or corrupted disk file.Any help…??Thnks,YKSun, 20 Mar 2011 15:17:11 GMTImage IT