EXPIRE INVENTORY internals

[tsm.report]

How do you explain examined objects and deleting objects are so close or when bigger difference happens between examined and less deleted objects? What I know expire inventory has been optimized , examined objects doesn't represent total database objects and processing a table not all database.

Our expire process is something like that for several days :

09/19/10 12:51:50 ANR0812I Inventory file expiration process 401 completed:
examined 283190 objects, deleting 281093 backup objects,
0 archive objects, 0 DB backup volumes, and 0 recovery
plan files. 0 errors were encountered. (SESSION: 79538,
PROCESS: 401)
09/20/10 13:23:17 ANR0812I Inventory file expiration process 422 completed:
examined 319155 objects, deleting 317061 backup objects,
0 archive objects, 0 DB backup volumes, and 0 recovery
plan files. 0 errors were encountered. (SESSION: 84143,
PROCESS: 422)
09/21/10 13:32:37 ANR0812I Inventory file expiration process 446 completed:
examined 397246 objects, deleting 395165 backup objects,
0 archive objects, 0 DB backup volumes, and 0 recovery
plan files. 0 errors were encountered. (SESSION: 89190,
PROCESS: 446)
09/22/10 13:49:17 ANR0812I Inventory file expiration process 472 completed:
examined 454687 objects, deleting 452611 backup objects,
0 archive objects, 0 DB backup volumes, and 0 recovery
plan files. 0 errors were encountered. (SESSION: 93808,
PROCESS: 472)

 

[ad283m]

It's indeed unusual. If I were you I would check my clients to see if there is no data being expired that should be kept.

 

[chad_small]

The difference might be due to time. TSM analyzes all files set to delete X days from the day and time it went inactive. My theory is TSM has is set to expire on that day at a certain time but expiration runs before the time of day its actually valid to be expired, so it is expired the following day....just a guess but sounds good.