Ian - It sounds like you're cursed with a high-churn environment...

You seem to have clients whose file population is greatly changing
over time, making for a lot of work for the TSM server. You can look
at Occupancy for your number of files in the TSM server, but that's
not going to tell you much, as time is passing and files are aging
and moving toward expiration as you analyze.

Instead, you may want to run EXPire Inventory with Quiet=No and get
some sense of what's contributing the most. You can probably get an
equivalent sense by analyzing your client session recordings of
number of files being sent, per the Activity Log or accounting
records, where some of them will stand out numerically. Then you can
talk to the client administrators and determine what's going on. Or
it may be that the expirations you're seeing now were from some
client transition event in the distant past, depending upon your
retention policies. It might also be the case that your Expirations
had fallen behind at some point, and are now catching up.

Keep in mind that Expiration runs, not against your server files
inventory, but against the internal server table called
Expiring.Objects, which is populated during client-induced object
expirations and time-based expirations in the server (presumably
through one of its ongoing housekeeping threads). It's a bucket which
gets refilled, and so another expiration run will get more work from
that.

So do the investigation, assure that your TSM db is configured for
best performance, and spread client activity and server maintenance
processes over time to the extent possible to mitigate contention.

    Richard Sims

On Feb 13, 2006, at 5:03 AM, Smith, I (Ian) wrote:

Hi

I have been having database performance issues possibly related to
unexpired objects in the database. The problem manifests itself
with all
the client sessions during the backup window grinding to a halt. There
are 7 pages of locks on the database and nothing is moving. After
running expiration, which expired 60% of the objects that is analysed,
the problems goes away.

Can anyone tell me how to work out the actual number of objects in the
database? Also, once the expiration process complete- I ran it again,
immediately and it found another few hundred thousand objects to
expire-
why?

Has anyone else seen this type of problem? If so is there a statement
that can be written to analyse the number of unexpired objects that
currently reside in the database? As light weight as possible, as a
heavy weight global lock enforced by a big statement probably wont
complete when the system is under this massive load!