>I ended up doing a dumpdb and loaddb and auditdb to get this pig back.  The
>only good news is it was a relatively small database so that process (once I
>figured out that's what I should do) only took about 10 hours total.

Kelly - The hazing we have to endure to join the *SM DB Recovery Club...
        I'll never forget the weekend I spent having to recover my database in
the same way a few years ago.  It's brutal, and needlessly so due to the
recovery commands being so neglected that they perform as poorly as they do.
It's a shocking revelation to go to recover your *SM database, thinking that
it will be a smooth, quick operation, and then to discover the awful reality.

I've submitted my requirement for performance improvement through ADSM-R, and
I encourage anyone else who has been through the pain to do the same, as that
seems to be the only way this situation will get corrected.  Remember, it's
not just our inconvenience: when the *SM server is down (perhaps for days),
your company's operations are jeopardized.  If a key business data store fails
soon after your *SM server becomes unusable, your enterprise is in dire
straits, for inability to recover.  I deem this an unacceptable situation, and
I should think that all the managers in the companies who bought into *SM on
the premise of their business data being secure and recoverable, should
likewise deem the situation unacceptable.

Let's get this situation fixed.

     Richard Sims, Boston University OIT