Hi To begin with, the guidelines for database setup is something similiar to:
a) 8-12 primary database volumes (since you're on 5.x you can still use TSM mirroring). Each volume should be in it's own filesystem, preferably on their own spindles (harddrives). If possible, make sure that your storage group assigns you 8-12 volumes from different arrays within the Vmax if possible, or at least as many arrays as possible. If they assign you 8 volumes from the same array, performance will be horrible. b) Log should reside on it's own volume(s). Since the log is sequential, raid-10 is the optimal setup. c) Using DB mirroring in parallell mode will increase performance d) Using LOG mirroring in normal mode will aswell increase performance e) Max sure you have enough bufferpool >From your description, it sounds like a) is the place to start, I wouldnt be >surprised if your db volumes are located (some of them or all of them) within >the same array. What operating system are you using? If you're on AIX, try checking I/O statistics during expiration to see if your queues are getting full (as in 100% utilization of the disks using iostat). If so, try increasing the queues, and go to your storage guys and have them look at the underlying Vmax to determine if there are any configuration issues there. Performance issues with expiration and database backups usually relates to the fact that the read-performance of the underlying array is limited. Best Regards Daniel Sparrman Daniel Sparrman Exist i Stockholm AB Växel: 08-754 98 00 Fax: 08-754 97 30 [email protected] http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -----"ADSM: Dist Stor Manager" <[email protected]> skrev: ----- Till: [email protected] Från: "Loon, EJ van - SPLXO" Sänt av: "ADSM: Dist Stor Manager" Datum: 02/16/2012 15:02 Ärende: Expiration performance TSM 5.5 (request) Hi TSM-ers! I'm struggling with the performance of our expiration process. I can't get it any faster than 100 object/second max. We tried everything, like using more or less database volumes, multiple volumes per filesystem, mirroring, unmirroring, but nothing seems to have any positive effect. We are using SAN attached enterprise class storage (EMC Vmax) with the fastest disks available. I have seen other users with similar (or larger) databases with much higher figures, like more than 1000 objects/sec, so there must be something I can do to achieve this. In 2007 at the Oxford TSM Symposium (http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Dave%20Canan%20-%20Disk% 20Tuning%20and%20TSM.pdf page 25) IBM also stated that 1000 object/sec is possible. I would really like to know from other TSM 5.5 users how their expiration is performing. Could you please let me know by sending me the output from the following two SQL queries, along with the platform you are using: select activity, cast((end_time) as date) as "Date", (examined/cast((end_time-start_time) seconds as decimal(18,13))*3600) "Objects Examined/Hr" from summary where activity='EXPIRATION' and days(end_time)-days(start_time)=0 select capacity_mb as "Capacity MB", pct_utilized as "Percentage in use", cast(capacity_mb*pct_utilized/100 as integer) as "Used MB" from db Thank you VERY much for your help in advance!!!! Kind regards, Eric van Loon KLM Royal Dutch Airlines </pre>********************************************************<br>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.<br><br>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.<br>Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 <br>********************************************************<pre>
