On Dec 15, 2004, at 3:09 PM, Hart, Charles wrote:

We have two identical TSM Server (AIX 5.2 / p630 / TSM 5.2.3.5) They
were both @ TSM 5.2.3.4 then we upgraded to 5.2.3.5 on the same day.
One of the servers has been running just fine (TSM Server1).  When the
other TSM server (TSM Server2) runs Expiration it grinds to a halt
with in an hour regardless of doing a cancel expiration or just trying
to cancel the process.  This TSMServer2 Backups / Archives our Oracle
Env so when Expiration runs it brings the TSM Server instance to its
knees to the point it won't take client data.  ...

I would again caution customers to never believe that any two systems
are identical. Such a thing is physically impossible, and if believed,
will inhibit productive analysis of system performance issues.
Differences are healthy, and afford the opportunity to compare the
effects of differing ingredients.

You're saying that you're running Expiration at the same time that
client backup/archive activity is occurring. That's bad. As the TSM
Performance Tuning Guide says: "Expiration processing is very CPU and
I/O intensive.  If possible, it should be run when other TSM processes
are not occurring."  Realize that Expiration makes heavy use of the
Recovery Log where rollforward mode is in effect.  And you can run into
log pinning (see swg21054574 on the IBM site). Exhaustion of Recovery
Log space can cause a configured dbbackup trigger to activate, which
further mires processing.  In the daily life of a TSM server, loads
have to be spread out and apportioned by type to achieve realistic
performance.  I would encourage review of your TSM processing load on
the subject system, to rearrange when things are happening.  Then go
back and do analysis of remaining problem areas, using the multiple
performance guides which IBM has provided us.

   Richard Sims