From: esquel@sommarskog.se   
      
   mat (mat@notarealdotcom.adr) writes:   
   > One thing I recall is that the production version of this database was   
   > in recovery mode a couple of weeks ago. My copy is a restored backup of   
   > that. The production db was damaged by someone at the data center   
   > pulling out the wrong network cable.   
   >   
   > I wonder if the restore my db went into might be related? If a db is   
   > damaged and recovered, can it remain unstable?   
      
   Yes. More precisely, if a database is victim to a hardware crash, it is very   
   likely there is some degree of corruption, and this can certainly cause   
   trouble later on.   
      
   > I eventually gave up on allowing the recovery to complete so I stopped   
   > the sql server instance, renamed the two mdf and ldf, and restored a   
   > fresh backup. The restore took much much longer than it used to, and it   
   > did the previous time also. I wonder if the restore took so long because   
   > of the damaged db/recovery from a couple of weeks ago? Is that possible?   
      
   It is conceivable. In any case, you should run DBCC CHECKDB on the   
   database when you have restored it. Furthermore, you should run in   
   on the production database as well. If you have corruption in there,   
   you may be up for trouble in production as well.   
      
      
   --   
   Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se   
      
   Links for SQL Server Books Online:   
   SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx   
   SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)