From: mat@notarealdotcom.adr   
      
   In article , esquel@sommarskog.se   
   says...   
   >   
   > mat (mat@notarealdotcom.adr) writes:   
   > > This AM a database on my dev box is listed as being in recovery. I   
   > > checked the sql server log (in SSMS Management/SQL Server Logs) and all   
   > > it says is that there was a serious error. This db was not used for a   
   > > couple of days and the machine didn't crash or anything like that so I'm   
   > > disturbed that 'somehow' it became broken and I'd like to explore why.   
   >   
   > So there is a stack dump in the log? The stack dump is not entirely   
   > easy to read, but usually there is some indication of the statement   
   > that was issued. Also, the date and time for the accident may give   
   > some indication.   
   >   
   > Maybe you have a maintenance job set up and something went wrong during   
   > this job. Why something would go wrong all of a sudden? Bad hardware is   
   > a common reason.   
      
   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?   
      
   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?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)