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@VM.MARIST.EDU] On Behalf Of Loon, EJ van - SPLXO Sent: Wednesday, June 27, 2012 8:23 AM To: ADSM-L@VM.MARIST.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.
