ADSM-L

Re: ADSM Database tools (?)

1998-07-20 11:28:33
Subject: Re: ADSM Database tools (?)
From: "Kauffman, Tom" <KauffmanT AT NIBCO DOT COM>
Date: Mon, 20 Jul 1998 10:28:33 -0500
Ouch!

In our case, the restore to a 'good' database wouldn't be an option. This
was an off-site archive tape, 21 day retention with a three-day reuse delay.
We didn't know there was a problem until it was back on site, checked in,
and we tried to change the access mode. By that time, we did not have a
database backup prior to the creation of the tape - nor would I have been
really willing to use it.

I'm hoping IBM will come out with some genuine DBA-type tools.

TomK

> ----------
> From:         David Hendrix[SMTP:dmhendri AT FEDEX DOT COM]
> Sent:         Monday, July 20, 1998 9:36 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: ADSM Database tools (?)
>
> Tom,
>
> None that I know of.  I agree that it is frustrating.  We have various
> sized ADSM DBs with anywhere from 60MB to 10GB.  A recent auditdb
> fix=yes done on a 370MB database (residing in 2GB worth of disk) took
> over 24 hours and FAILED!  Ouch!  Even sybase DBCC's work faster than
> the auditdb (the solution in that instance was to restore a previous
> good db backup and run audit vols on the disk pools - not a pretty
> picture and we lost some backups).
>
> Perhaps there are some undocumented "SQL" update commands allowing us to
> fix the relational integrity of the internal tables....
>
> David
> dmhendri AT fedex DOT com
>
>
> Kauffman, Tom wrote:
> >
> > I've just had the 'opportunity' to run an auditdb with fix=yes to
> correct an
> > internal inconsistency (I had an off-site volume got to 'pending' but
> > couldn't change access from 'of' to anything else, because there were
> still
> > references to it). The process took 11 hours. This is about the longes
> > outage I can afford, and I can do it at most once a week.
> >
> > What other tools are available for ADSM database maintenance? We're
> about to
> > add significantly to the size of the database, and I don't feel
> comfortable
> > going forward with an un-maintainable database.
> >
> > TIA
> >
> > Tom Kauffman
> > Sr. Technical Analyst
> > NIBCO, Inc
>
<Prev in Thread] Current Thread [Next in Thread>