We had a similar situation, for us the WIn SysObjs were killing us. Being that
the Win SysObj change on almost a daily basis and there's quite a few per Win
Server, we created a Mngt class just for Windows sysobj and put a specific
retention of 10 Versions. We also do a Server side Client Opt file so we were
able to force the following incexl option to all the windows boxes using the
new mngt class. We saw a 50% reduction in the TSM DB and significant reduction
in the expiration process.
Option: INCLEXCL
Sequence number: 2
Override: Yes
Option Value: INCLUDE.SYSTEMOBJECT ALL SYSTEM_OBJECTS
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Jones, Eric J
Sent: Tuesday, February 01, 2005 6:04 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Expiration
Good Morning.
I have a question about expiration.
I have a 90 day policy for data on the servers(Versions Data Exists - Nolimit,
Version Data Deleted - Nolimit, retain Extra Versions 90 and Retain Only
Version 90). My question is how can I tell if data is being expired and how
many files on a particular machine? What I checked is a machine that is
backing up everynight with about 2000 files(SYSETM OBJECT) but the file count
keeps growing. It's been 95 days since the 1st backup so I would have thought
the file count would be leveling off. I see when expiration runs that the
server is listed for each of it's filespaces but I have no idea how many files
if any it expired.
The TSM servers is AIX 5.2 with TSM 5.2.2 and the client is Win2K with TSM 5.2.2
I want to make sure that the old files are expiring so we do not keep growing
in size. It's one of many machines so the final count for how many files
expired in expiration does not tell me which machine it came from.
Have a Great Day,
Eric
