I am curious how many folks use TSM to mirror their databases?   Do you
use "parallel write"?

As I experiment with my new server (see previous email about testing
expiration), I wonder if the DB mirroring and parallel writing on my
production servers is causing such a large difference in EXPIRE INVENTORY
processing.

On my big, 194GB production Linux server, an EXPIRE INVENTORY runs 40-48
hours.  Granted, the server is very busy performing other tasks such as
client backups, stgbackups and such.  The DB buffers and such are
configured identically to the production server.

On my first test expire run on my new test server (to which I reloaded the
194GB production DB), the expire ran in 10-hours - 1/4 of the usual time.

Besides the obviously idle server, I am wondering what else effects the
expiration run time.

In this stage of the test configuration,  I configured a single 194GB DB
volume vs the production server which has had it's DB grow in increments
and therefore is comprised of 10+ volumes.

The test system is not mirroring the database (this will be in the second
test).

So, what else could be causing a major impact on the expire inventory
process?

The old "performance and tuning" guides used to recommend multiple DB
volumes (concurrent I/O?) as well as mirroring.  Are these still good
ideas for todays Linux servers, especially since I can't put each DB
volume onto separate spindles/disks.  If all I have is one, internal,
physically mirrored (RAID 0/1) HD for the DB primary volumes, are multiple
volumes causing lots of head-contention/movement?

Your thoughts on this?