Craig -

You need to perform analysis to identify problem cause, where the TSM
Problem Determination Guide and Performance Tuning Guide will help.

Log pinning is due to prolonged transactions, and is aggravated by
sluggish networking and sluggish TSM servicing of transactions (often
due to underlying disk/tape issues).

You can quickly see if your TSM server is "behind" in its rate of
servicing incoming client data by inspecting the TCP receive queue
packets backlog.  In AIX that can be done via the command:
  netstat | head -2 ; netstat | grep -vi dns | grep tcp
If the various entries show a large receive queue value, then it is
likely that your networking is good, but that TSM is not keeping up
with the incoming, as may be caused by the underlying disk, tape, and
I/O path technology that it is using.

If your clients have recently started backing up very large files
(digital movies is a stereotypical case), then that would certainly
contribute to what you're seeing.  A quick look at TSM accounting
data or ANE Activity Log messages would give a sense of that, and
Query CONTent with a negative Count value on the collocated tape
volumes that the clients are doing will show biggies.  Query SESSion
during client activity will also help identify consumptive sessions.

Before you gave TSM the new LTO 3 and SATA hardware, I would hope
that you benchmarked it first, to assure that it was providing the
performance you would need in production, and thus uncover any issues
with it beforehand.  A bad RAID choice in disk implementation will
also slow throughput.  Old microcode may have performance-impairing
defects.  A mismatched device driver can cause operational delays.

Don't waste your time or jeopardize your server in doing a TSM db
unload/reload.

You may want to confer with your operating system people to have them
help narrow down the problem area, where they are familiar with all
the specifics of your environment.

   Richard Sims