Nick,
Thank's for all your hints - it worked really fine.
After running the db2adutl.exe the versions were set to inactive and after the
expire inventory process, the space was freed up und there were many 3590E-tapes
emptied.
Now a last question according to this -
The query occupancy shows us correct, that we have now the versions we wanted to
have.
The Show Versions shows the same.
But the query filespace shows us in the Capacity and the PCT-Util Field the same
value as yesterday, when all the versions were active (look below)
Does this matter to me ? (I don't think so, because the most important thing
was, that TSM emptied the Tapes)
Or do I have to do a kind of "compress" to this filespace ?
Node Name: ATEDV0SA
Filespace Name: /EDVRTEST
Platform: OS/2
Filespace Type: API:DB2/2
Capacity (MB): 139.1
Pct Util: 100.0
(This filespace is only a "Test", so its size is only 139 MB)
Gerhard Wolkerstorfer
([EMAIL PROTECTED])
[EMAIL PROTECTED] (Nicholas Cassimatis) am 06.02.2001 14:49:35
Bitte antworten an [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
Kopie: (Blindkopie: Gerhard Wolkerstorfer/DEBIS/EDVG/AT)
Thema: Re: Antwort: Re: DB2/2 Backup and Policy
Gerhard (I couldn't send direct to your address, so sending via the list)
Yes, the db2adutl.exe command is the one he needs to run. There are
parameters to determine how many versions to keep active. Once a backup is
marked inactive, and Expire Inventory is run, you'll get the space back. I
had a similar situation, and when we fixed it, we emptied over 150 3590B
tapes! If I can come across the command, I'll forward it to you, but the
DB2 DBA's should be able to find it in their documentation.
All of the SHOW commands are undocumented. If you search back through the
archive of the list at www.adsm.org, there was a posting of all the
commands and what they did. They are meant for TSM support to use to help
diagnose problems, but most of them have good uses to us users, too.
And yes, the SHOW VERSIONS output you have shows the backups bound to the
right management class, so your DBA has that part right. If EXPIRE
INVENTORY has run, you may see the inactive version disappear (It may take
until tomorrow, as your Retain Last value is set to 1, I believe).
Nick Cassimatis
[EMAIL PROTECTED]
"I'm one cookie away from happy." - Snoopy (Charles Schulz)
[EMAIL PROTECTED] (Gerhard Wolkerstorfer) on 02/06/2001
03:28:17 AM
To: Nicholas Cassimatis/Raleigh/IBM@IBMUS
cc:
Subject: Antwort: Re: DB2/2 Backup and Policy
Hello Nick,
Thanks for your advices.
First - Indeed, our DB2 Admin isn't running a DELETE Command. Please, could
you
send me the syntax of the command, he will have to run
or did you mean, that he needs to run the programm DB2ADUTL.EXE ? (After
hours
of search we found and did run it and TSM marked the specified version as
INACTIVE ! YES ... he did it.!!)
Second - Is the "show versions" Command undocumented ? I didn't find
anything in
der TSM Books (for OS/390!)
Third - The "show versions" Command shows us =
/EDVRTEST : NODE FULL_BACKUP.20010125094902.1 (MC: DB2)
Active, Inserted 2001-01-25 09:45:02
ObjId: 0.71406338
/EDVRTEST : NODE FULL_BACKUP.20010125120404.1 (MC: DB2)
Active, Inserted 2001-01-25 12:00:06
ObjId: 0.71406339
and so on
so all our Versions are really Active - AND they are bound to the
requested
MC (DB2!)
After using the programm DB2ADUTL.EXE one version was marked as inactive as
described before.
So I think the db2adutl.exe is the answer, do you think so too ?
-- Gerhard --
[EMAIL PROTECTED] (Nicholas Cassimatis) am 05.02.2001 20:09:40
Bitte antworten an [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
Kopie: (Blindkopie: Gerhard Wolkerstorfer/DEBIS/EDVG/AT)
Thema:Re: DB2/2 Backup and Policy
Two things, the first one being the biggie - the DB2 Admin HAS to run the
commands to have the backups expire - otherwise they stay active forever.
If you do a "show versions NODENAME /DATABASENAME" you can see all the
versions of the backups. If they all show Active, then the DBA isn't
running the delete command. The second thing is, in the "show versions"
output, you will see the management class it's defined to (MC:name). If
it's not the one you want to use, there's another problem. On my DB2
systems (running on AIX, but it should work the same), I have a statement
in my include/exclude statement like this:
include /DATABASENAME DB2
That binds the database backups to the specified management class. This
way I don't have to depend on the DBA, should they make any changes to
their configuration.
Nick Cassimatis
[EMAIL PROTECTED]
"I'm one cookie away from happy." - Snoopy (Charles Schulz)
