What kind of disk is your DB on and how are those disk configured?

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: John C Dury [mailto:jdury AT DQE DOT COM]
Sent: Monday, August 05, 2002 2:21 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Help with corrupted data --> "DSMSERV AUDITDB INVENTORY FIX=YES"


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