>As a "relatively" experienced ADSM/TSM user, I entirely agree with what
>you said, but, as told in my mail, I doubt that any of my client has
>begun sending more files than usually, because following query "select
>sum(num_files) from occupancy" returns a relatively constant value. From
>my perception, if I suddenly had more versions of the same files, this
>field should increase, or I am wrong and it does only count 1 unit for
>each filename, without considering the number of versions TSM keeps in
>its DB ? (5 versions of the same file will be counted as 1 ?)

Hi, Arnaud -

Realize that what shows up in Occupancy does not necessarily correlate with what
goes into the database...  Occupancy may superficially seem like it should
reflect everything, but it does not necessarily.  Occupancy reflects the number
of filespace files and the space they consume when stored in storage pools.
Depending upon client type and file system object types, the backed up objects
may be stored directly in the database as they need no storage pool space,
examples being Unix directories and empty files.  All this is to emphasize that
the number of files you see in the Occupancy table DOES NOT tell you the number
of files stored on the server for that filespace and storage pool.

The "Number of Files" value from Query OCCupancy reflect all instances of file
objects: if you perform an Incremental backup, and then update the timestamp on
one file and perform the backup again, the Number of Files count will go up by
one, meaning that the count reflects versions.

What the Occupancy table cannot tell you is things like Aggregate size:
transaction size, as influenced from either the client or server, can change the
size of an Aggregate, and smaller Aggregates mean higher database utilization.
In topic "Database consumption factors" in ADSM QuickFacts, I summarize what we
commonly know about what eats database space.

I stress accounting log reporting because it is the very best, detailed handle
on what your clients are throwing at the server, and that is the greatest impact
on TSM db space.  It's vital to see such information to spot the source of
surges and other anomalies.  It greatly frustrates me to see sites disregard
that administrative gold and try to figure out what has happened without
exploiting that resource.

It may very well be that your clients are not directly contributing to the
database inflation...which may be the result of some kind of constipation.
But problem resolution involves problem isolation, which requires being able to
eliminate factors based upon solid information, and thus we need thorough usage
tracking over time.

I think I'm over my typing quota now,   Richard Sims