ADSM 3.1.2.20 Server Startup Error
Kelly Lipp
TBUNDO012 Error. This manifests itself as follows: restore the db, start
the server, everything fine. Halt the server and try to restart it, and I
get these errors.
The good news is it's consistent. Everytime I do this, it does it! I guess
that's the bad news too. Any ideas are appreciated.
Thanks,
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80919
(719)531-5926
Fax: (719)260-5991
www.storsol.com
li...@storsol.com
Steven P Roder
> I'm getting an ANR9999D tbundo.c (256): Error 20 followed by an ANR7837S
> TBUNDO012 Error. This manifests itself as follows: restore the db, start
> the server, everything fine. Halt the server and try to restart it, and I
> get these errors.
Mine happened on 3.1.2.42, and after the restore db, and can restart the
server Ok. However, the error returned on one of the two servers that I
got this on. I have since run auditdb fix=yes detail=yes on both, as they
are small DB's. In one case, the audit fixed a problem, in the other, it
did not report any trouble. The one that audit "fixed" was the one that
died twice.
Steve Roder, University at Buffalo
VM Systems Programmer
UNIX Systems Administrator (Solaris and AIX)
ADSM Administrator
(tkss...@buffalo.edu | (716)645-3564 | http://ubvm.cc.buffalo.edu/~tkssteve)
Kelly Lipp
I ran auditdb fix=yes but that did not seem to help. Same problem. I
restored to an earlier db backup and had the same problem. A little more
detail this time: apparently it is having trouble deleting a row in the
activity log.
If I set the actlogretention down, when and how does that stuff get purged?
Is there anyway to delete the activity log? Looks like something in there
is corrupted. What about a dump and a load? Might that help?
Thanks,
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80919
(719)531-5926
Fax: (719)260-5991
www.storsol.com
li...@storsol.com
Joshua S. Bassi
The only way I know of to delete activity log entries is using the
"set actlogretention days" command (as of course I'm sure you know).
But of course that has to be done online with the server operational.
--
Joshua S. Bassi
Senior Technical Consultant
Symatrix Technology, Inc.
jba...@gloryworks.com
Kelly Lipp
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. There
were 27 million objects in the database. Interesting and fun to know facts,
I guess.
I'm awaiting word from support as to why it got into this bind in the first
place. If I learn anything of interest there, I'll post it. I did get a
bunch of trace information during the crashes and hangs so they should be
able to figure out what happened. It looked like the activity.log table
somehow got hosed.
So, for now, you can call me the dumbdb guru. BTW, that isn't that fun a
process I'm here to tell you. Especially on a weekend when all of you guys
are tucked safely away at home. I hate not having help!
Richard Sims
>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
sal Salak Juraj
I require better speed on recovery actions
and better LOADDB - without automatical DB grow,
but I also feel it is fair to say that the
current *SM recovery possibilities are designed in
extremly secure and partially in flexible manner.
Colleague here shortly had to restore db of
a different database based backup
system - only because its DB became full
and there was no way to expand it on line (!),
and it was not a job one could really
perform without manufacturers support.
I saw at this time major advantage for *SM recovery,
which I already had to go through twice -
so I must be club member as well :)
regards
Juraj salak
-----Ursprüngliche Nachricht-----
Von: Richard Sims [mailto:r...@BU.EDU]
Gesendet am: Montag, 20. März 2000 14:52
An: ADS...@VM.MARIST.EDU
Betreff: Re: ADSM 3.1.2.20 Server Startup Error