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?
