>        I talked to a guy at IBM several months back and his suggestions
>were that you should analyze the number of concurrent sessions that you
>have going at anyone one time and create an equal number of DB volumes.
>I usual have about 20 concurrent backup sessions going during my various
>backup windows so I am in the process of breaking my DB volumes into
>smaller ones.  He told me that this was a thread issue with how TSM
>talks to the DB volumes (hope I got that part right).  As for the log
>volumes, I was told this is like a paging file, make one large one.

Michael - You got some good advice...

If you do a SHow THReads, you will see as many LvmDiskServer threads as there
are DB and Recovery Log volumes, which gives you that parallelism.
You get the most benefit if, ideally, each each volume were a physical disk,
so that each would have its own arm, not having to reposition the arm for other
things.  With today's more abstracted disk technology, that's elusive.
With large physical volumes, you partition to make volumes.  There is obviously
no arm advantage here, but the basic advantage of partitioning pertain: it
isolates the effects of a surface fault, which then affects only that partition
instead of the whole disk, if it were unpartitioned. This makes it far less
painful and time-consuming to swap that LV out of a mirrored set and swap in one
of those nice replacement LVs you have set aside.

It's sad that the TSM Performance Tuning Guide fails to make any mention of all
this.

  Richard Sims, BU