-----Jeff White wrote: -----

>I have a query regarding expiration
>
>Recently implemented new retention policies new reduce the amount of
>version of windows files we have in TSM storage. Before implementing,
>i ran this script to get the total number of files in storage at that
>time:
>
>SELECT SUM(NUM_FILES), NODE_NAME FROM OCCUPANCY GROUP BY NODE_NAME
>order >by 1 desc
>
>This told me i had 125,171,962 files in storage
>
>I run expiry every day, capture and record from the activity log the
>number of backup objects deleted every day. Over the first 10 days,
>this totalled 6,652,218 files.
>
>I then re-ran the above script and the total number of files was
>113,796,651, a difference of 11,375,311.
>
>Was i wrong to expect number of expired files to match the actual
>difference?

Are you using copy storage pools? If so, expiring one object will
typically reduce the sum of the occupancy counts by two, because
both the count for the relevant primary storage pool and the
count for the associated copy storage pool will decrease.

Note that there are some objects that TSM can recreate from data in
the TSM database without needing to put anything in storage pools.
Zero length files, Unix directories, and Unix special files can
usually be handled this way. Expiring such objects will have no
effect on the occupancy counts.