>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