ADSM-L

Re: [ADSM-L] Expiration performance TSM 5.5 (request)

2012-02-16 15:52:23
Subject: Re: [ADSM-L] Expiration performance TSM 5.5 (request)
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 16 Feb 2012 15:45:46 -0500
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