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
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE
-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
Till: ADSM-L AT VM.MARIST DOT EDU
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>
|
