Questions about Orphaned DB2 data in TSM

[Bob]

The db2adutl command was issued against nodes that had been defined with archdelete and backupdelete as NO. As a result of the NO setting, we are getting the following message:
----
The current delete transaction failed. You do not have

sufficient authorization. Attempting to deactivate

backup image(s) instead...



Success.
----
Past ADSM Forum questions state that the archdelete and backupdelete should be YES!
I have now changed the archdelete and backupdelete to Yes for the affected TSM Nodes. My questions are:
1) does Inventory Expiration remove the 'deactivated files' or, do those objects become Orphaned within the TSM Database when the delete command was issued?
2) for those objects that the db2adutl can no longer see, what was the suggested fix to remove those objects from the APIB2 filespaces?

TSM V5.4
AIX V5.3

Bob

 

[cheffern]

hi Bob -

I'll try to answer this...
you are right - they should be set to YES.

so what you have here is deactivation -
which means that it's just no longer an 'active' version of the file -
and hence should be cleaned up by Expire Inventory when it expires (ie, whatever you have the policy set for for this particular node setup).
they won't actually be 'orphaned' - TSM will clean them up.

but you are saying that db2adutl query won't show these anymore?
in theory, what I said above should be true -
they are inactive versions now and will be deleted when they expire -
and not before...
pls confirm if you are seeing anything at all with 'db2adutl query'

-Chef.

 

[Bob]

Chef:

I am still waiting for the results of the Expiration Processing to see the affect that deactivation had on the Filespace. Our problem is furthered by older copies of logs and Full Backups found in the Backup Copy Group. A Server would be decommissioned and then placed back in service with a new iteration (refreshed copy) of data using the Subsystem Id. My database administrators are saying that they a somewhat limited for what they can ask for unless, there is another way to 'see' the objects using db2adutl. For example, DB2 once included files like this one: adminDB.20061119080100.SAR

I am told that the db2adutl utility allows for deletion of Full Backups using the 'older than' parameter. Logs must be specified by the sequence range. Because I am not familiar enough enough with the DB2 utility, it may just be that my DBAs have not explored the full range of parameters and limit themselves to Full Backups and Logs.
The form of the log I see looks like: S0000000.LOG.20041031144543.NODE0000

Do you know of another way that the utility can 'see' what TSM is holding?

Bob

 

[cheffern]

the command to look is "db2adutl query" and it will show something like this:

server12:db2bd1 2> db2adutl query

Query for database BD1


Retrieving FULL DATABASE BACKUP information.
1 Time: 20060312121934 Oldest log: S0000002.LOG DB Partition Number: 0 Sessions: 1


Retrieving INCREMENTAL DATABASE BACKUP information.
No INCREMENTAL DATABASE BACKUP images found for BD1


Retrieving DELTA DATABASE BACKUP information.
No DELTA DATABASE BACKUP images found for BD1


Retrieving TABLESPACE BACKUP information.
No TABLESPACE BACKUP images found for BD1


Retrieving INCREMENTAL TABLESPACE BACKUP information.
No INCREMENTAL TABLESPACE BACKUP images found for BD1


Retrieving DELTA TABLESPACE BACKUP information.
No DELTA TABLESPACE BACKUP images found for BD1


Retrieving LOAD COPY information.
No LOAD COPY images found for BD1


Retrieving LOG ARCHIVE information.
Log file: S0000000.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2006-03-12-12.10.21
Log file: S0000001.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2006-03-12-12.11.08
Log file: S0000002.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2006-03-12-12.48.32
Log file: S0000002.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2006-03-12-12.51.26
Log file: S0000003.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2006-03-12-15.58.37
Log file: S0000004.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2006-03-12-17.55.02
Log file: S0000005.LOG, Chain Num: 1, DB Partition Number: 0, Taken at: 2006-03-12-19.30.10
Log file: S0000006.LOG, Chain Num: 1, DB Partition Number: 0, Taken at: 2006-03-13-06.58.27
Log file: S0000007.LOG, Chain Num: 1, DB Partition Number: 0, Taken at: 2006-03-13-07.04.49
Log file: S0000008.LOG, Chain Num: 1, DB Partition Number: 0, Taken at: 2006-03-13-07.06.59
etc...

yes - there are several ways to delete backups from there -
but you do have to be able to see them first (for the most part, anyway) -

Usage: db2adutl
QUERY
DELETE
VERFIY

there is a whole blurb on it here -
sounds like you need to pass this on to the DBA's for them to look...

http://publib.boulder.ibm.com/infoc...?topic=/com.ibm.db2.udb.doc/core/r0002077.htm

Verify can work to your advantage, possibly...
I've never played too much with it though to say for sure.
hopefully your DBA's can figure this out.

Good Luck -
-Chef.