I did a lot of reading though DB2 manuals to find this information. And yes,
DB2 just removes the entry from the history file and doesn't remove the
physical file. You need to have some scripts that will remove the files. And
the DB2ADUTL only removes them from TSM and not the history file. So you
could ask DB2 to restore to a date known in the history file, but the data
has been expired in TSM. On my system with NUM_DB_BACKUPS set to 30, my
DB2ADUTL command is DELETE OLDER THAN 30 DAYS. Now if I don't get a full
backup that day, the script doesn't do the DB2ADUTL delete. It would be nice
is there was a sync utility like with the TDP Oracle (TDPOSYNC) so that the
history file and TSM match. Even Informix has a sync utility!

Bill Boyer
DSS, Inc.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
asr AT UFL DOT EDU
Sent: Monday, May 19, 2003 10:12 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: delete DB2 backups and logs


=> On Fri, 16 May 2003 10:31:10 -0400, Bill Boyer <bill.boyer AT VERIZON DOT 
NET>
said:


> For syncronizing the history with it that would depend on your retention
of
> the bakcups with the DB2ADUTL utility. Set the database attributes: (DB2
GET
> DB CFG FOR <database>)

>  Number of database backups to retain   (NUM_DB_BACKUPS) = 30
>  Recovery history retention (days)     (REC_HIS_RETENTN) = 60

I'm somewhat aggravated that the redbook doesn't include even a single
mention
of these arguments (or at least my PDF search didn't find them)

I am encouraged (or discouraged) to learn that there is confusion on the
DB/2
lists about this, too.


> According to one of the DB2 manuals I read through, after the completion
of
> a full backup DB2 will automatically prune the history file based on these
> parameters.

I think that this is pruning the -db2- history file, and that it does not
address any expiration/deletion on the TSM server.

To translate into files-on-disk terms:

If NUM_DB_BACKUPS is 4 and REC_HIS_RETENTN is 30,

then after completing the sixth full backup there are two database backups
still sitting around on disk, but DB/2 doesn't know that they are there any
more.  If you were to say

restore database foobar from /place/where/old/backup/lives/

it would just work, but that backup isn't recorded in DB/2's internal
recovery
data.

Ditto for the logs and fulls that were taken 45 days ago; they are not
somehow
magically deleted from the disk, but they are no longer present as far as
DB/2
is concerned.


- Allen S. Rout