I recently extracted four TSM DB's to upgrade to 6.2.  The DBs were from about 
120GB to 230GB.
The longest extract was 3:22 and that DB was about 150GB.

I extracted from a cloned copy of the 5.4 DB.  The DB was on 20GB disks, these 
were RAW volumes in AIX.  To speed things up I pinned these disks to SSD in the 
VMax.  About a 20% reduction in time.
The output was to a single volume with a file device class defined to it.  
Nothing special.

The hardware that did the extract is a P6.  Nothing special.

My DBs are not as old, only been around since 2002, but they have never been 
reloaded except when needed to upgrade TSM.

In a VMax SSD is only a big gain if the IO is heavy random read, when 
extracting I found I was about 90% random read.
For the target device, the type of disk is not important because the VMax will 
soak up the sequential writes without an issue.  My target was a thin device 
managed by FAST VP, so it had a large amount of SATA.

I also saw that the process appeared single threaded.  The CPUs I have at 4.x 
GHz.  Not sure about AIX, but in the Windows world cycles matter when it is a 
single thread.

I am also 8Gb FC dual attached active/active to the VMax.  On the VMax make 
sure you are using diverse ports.  10Ea and 10Eb for example use a single CPU.

Perhaps you will find something in my ramblings that helps.

Andy Huebner

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Loon, EJ van - SPLXO
Sent: Wednesday, June 27, 2012 8:23 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] DBUnload, need for speed

Hi TSM-ers!
My TSM databases are running for quite a while (since 4.1) and they are
becoming rather fragmented, one of them more that 25%! It becomes
noticeable too, expiration is running longer and longer.
Our TSM servers are all running in AIX 5.3 on a P-series 570, SAN
attached to a VMAX (OS, DB and LOG) and VNX (diskpool) storage subsystem
and two EMC DL4106 DiskLibraries (VTS without physical tapes).
Unloading the smallest (95 Gb) database takes about 7 hours, loading it
takes about 3.5 hours. These tests are perform with a live database copy
on our test environment. Overall it takes too long to do this on our
live environment.
I tried several scenarios: multiple filesystems, RAW lv's, cio/dio
mounted filesystems, multiple database volumes on multiple filesystems,
everything you can think of, but there's only a small gain in using
multiple volumes on dio mounted filesystems, the rest is marginal or
even worse.
The first part of the unload is running very fast (4 or even 5 million
entries per minute, but at a given point performance drops dramatically.
It's always at the same point (around 80%), so my guess is that that's
the most heavily fragmented part.
The only thing I can think of to speed up the process is to use a
storage device with a very low latency, like SSD, but unfortunately
that's not supported on the P5 series...
Does anybody have some additional tips I can try?
Thanks for your reply in advance!
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
********************************************************
For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286
********************************************************

This e-mail (including any attachments) is confidential and may be legally 
privileged. If you are not an intended recipient or an authorized 
representative of an intended recipient, you are prohibited from using, copying 
or distributing the information in this e-mail or its attachments. If you have 
received this e-mail in error, please notify the sender immediately by return 
e-mail and delete all copies of this message and any attachments.

Thank you.