ADSM-L

Help with corrupted data --> "DSMSERV AUDITDB INVENTORY FIX=YES"

2002-08-05 14:20:05
Subject: Help with corrupted data --> "DSMSERV AUDITDB INVENTORY FIX=YES"
From: John C Dury <jdury AT DQE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 5 Aug 2002 14:21:01 -0400
The scenario:
     Recently I was trying to upgrade to TSM server v5.1.1.2 from v4.2.2.7
on AIX on our production database. The server failed to start after the
upgrade and according to IBM, it's due to a corrupt DB. They informed me
that we need to run a "DSMSERV AUDITDB INVENTORY FIX=YES" on our database
which must be done with the system down. I started it on a Friday and let
it run all weekend ubt it still hadn't finished by monday morning.
Unfortunately we use TSM to backup our Oracle transaction logs and without
that, we tend to run out of space on the AIX servers that have Oracle.
Leaving our production TSM system down for several days is just not
possible. IBM has given me a workaround for upgrading to v5.1.1.2 but it
would still mean a corrupt database.
     Obviously I'd like to fix things but here are my concerns. We ran into
a problem long ago that given a certain setup scenario, a normal backup
from a client to the TSM server could corrupt the database. Granted this
was when our TSM (ADSM then) server was on MVS, but how do I know that
after fixing the DB, there isn't a client out there somehow corrupting the
database again? Leaving our production system down for a long period of
time just seems idiotic and also quite probably, impossible. What have
others done? Our DB is about 25000 meg but only 79% full.
 Is there anything I can do to speed up the process?
Is there anyway to tell  what client object #1996898 is referencing when
the output from the "auditdb inventory" looks like:

ANR4306I AUDITDB: Processed 1996898 database entries (cumulative).

The output appears to be in sequence (for the most part) and I was thinking
I could just delete the backup data for that client in hopes of removing
the corrupt entries.

I hope someone has a suggestion/idea because leaving a production system
down for many days is just ridiculous and not feasible really.

John

<Prev in Thread] Current Thread [Next in Thread>