ADSM-L

Re: [ADSM-L] Database audit performance

2010-11-29 05:02:04
Subject: Re: [ADSM-L] Database audit performance
From: "Loon, EJ van - SPLXO" <Eric-van.Loon AT KLM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 29 Nov 2010 11:00:41 +0100
Hi TSM-ers!
Just to let you all know, I have found several things to speed up the
auditdb. We have turned of logical volume mirroring on the LV containing
the database volumes and I have tried the unload/load before starting
the audit.
Database audit used to take around 17 hours, turning off LV mirroring
saved us another hour and after a unload/load (thank you very much Mark
Haye from Development for the tip) the audit ran for 12 hours! Deleting
all diskpool volumes before the audit saves me another 30 minutes.
I will plan the audit in two separate steps: one downtime for the
unload/load on day one and the auditdb on day two.
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Loon, EJ van - SPLXO
Sent: Thursday, November 18, 2010 5:44 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Database audit performance

Hi TSM-ers!
We're having orphaned database entries, caused by a very old bug, fixed
some server releases ago, but only recently discovered. I'm currently
trying to find a way to speed-up the auditdb performance.
What I'm planning to do is this:
1) backup the database on our production server
2) stop the production server
3) restore the production database on our test server which already used
new disks, allocated on our new Vmax.
4) perform an audit fix=yes on this database
5) backup the fixed database and restore it on the production server
I already tested the scenario above and it works, but the audit takes
too long to finish (17 hours). Since we're backing up a lot of Oracle
databases, TSM downtime will be too long, the Oracle recovery logs will
fill up and the databases will stop.
We are running an AIX TSM server with plenty of memory and multiple HBA
to the SAN.
Restoring the database runs ok, Topas is showing around 25 Mb/sec disk
write speed. I have seen better performance on Vmax disks, but I can
live with this.
When I start the audit Topas shows a disk read and write speed average
less than 1 Mb./sec. CPU average is around 50% and vmstat shows no page
in and out.
I tried everything: mounting the filespace with cio, dio, using RAW
logical volumes, tuning read ahead through ioo, it doesn't make any
difference or even gets worse (when using RAW for instance).
I'm really out of options here. Something is holding back the audit, but
I can't find what!
Does anybody have some tips for me?
Thank you VERY much 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>
********************************************************
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
********************************************************

<Prev in Thread] Current Thread [Next in Thread>