I would stay away from database reorganization as a treatment, as that's a
risky, time-consuming operation with a long service outage and likely
short-lived benefits.
Your buffer pool cache hit percentage may look fine, but if the pool is
oversized, paging might be happening to support it, which will be a drag on the
system. (Technote 1405086)
In the classic TSM database, load distribution among the database volumes was
problematic, where a lot of activity may be concentrated on one or a few
volumes.
For comparative numbers, you might want to see what the rate is on a Delete
Filespace relative to Expire Inventory, to possibly point out Expire Inventory
as having issues specific to it, rather than your overall system configuration.
I would imagine that you are allowing Expire Inventory to run to completion
each time it runs. A cancel may cause TSM to start over compiling a list of
expiration candidates, which is added overhead. Whereas expiration involves
database updates, and thus locking, it may run into lock conflicts with other
processes operating in the same area. The expiration of System Objects used to
involve a huge, grouped transaction, but was changed to do that work in clumps.
The situation may be one you won't find an answer for, unfortunately.
Richard Sims
|