We have a 4.2.1.9 TSM server running under OS/390. The database has been
getting bigger and performance has been getting worse. We decided to run
a test to see how long it would take to dump and reload the database. We
ran a 'prepare' command to create a recovery plan based on our onsite
database backup. We modified the output to use a different set of
dataset names and volumes for recreating the server. We also modified
the server options in the recovery plan to use a different TCP/IP stack
and to remove the volume deletion exit. We needed to use a different
stack because we wanted to run the recovery jobs under a different
OS/390 image. This eliminated most resource contention between the
recreated server and the production server. It also enable us to rule
out some nerve-wracking scenarios involving attempts to use the same
devices. We executed 'vary' commands to prevent the recreated server
from getting access to the tape drives used by the production server
and the disks containing production storage pool volumes. Once we
recreated the server, we ran a full backup of the database. We then
ran dumpdb, loadformat, and loaddb jobs modeled after the samples in
the back of the "Administrator's Reference". We specified a 384
megabyte region size rather than the 128 megabytes in the samples.
I attended an IBM presentation on TSM performance a couple of years
ago. The speaker indicated that dumpdb would run at about 6 gigabytes
per hour and that loaddb would be somewhat slower. The dumpdb job
actually did better than the prediction, dumping 15 gigabytes in just
under two hours. The loadformat job took about 15 minutes. The loaddb
job ran for 17 hours, reporting progress at a rate that extrapolated
to finishing in about 4 days. To me, the phrase "somewhat slower" does
not suggest a factor of 50 increase in running time. Is there something
we could have done to get the loaddb performance more nearly comparable
to the dumpdb performance?