March 20, 2011 at 3:17 pm
HI,
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,
YK
March 20, 2011 at 3:28 pm
Look 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.
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 20, 2011 at 3:47 pm
Thanks 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 DB
2. to reinitialize the replication all over again (off course after try and find out the reason of the "suspect" situation)?
Thanks in advance.
YK
March 20, 2011 at 3:50 pm
Image IT (3/20/2011)
Which I/O subsystems you mean?
The one that the suspect database is stored on.
Can it be because of the replication configuration?
Highly unlikely.
Suspect means SQL encountered data or log file damage during crash recovery or during a rollback
Because its a replicated sever, what u think will be easiest:
1. to try and recover the suspect DB
2. to reinitialize the replication all over again (off course after try and find out the reason of the "suspect" situation)?
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.
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 20, 2011 at 3:56 pm
Thanks Gail,
We will look deeper in the error logs,
and get back to you 🙂
Thnks Again.
YK
May 17, 2012 at 9:57 am
exact 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 1
Database 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 1
Check 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.
May 17, 2012 at 10:03 am
zavhrye (5/17/2012)
This is because of the db being a subscriber any intelligent answer would be appreciated. Thanks.
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.
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 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply