IDMSTUNE - Interesting effect

Discussion created by ca.portal.admin on Jun 16, 2010
Latest reply on Jun 16, 2010 by ca.portal.admin
I have a section of the DB which suffers from a nightly load of many =
into a structure which is heavily indexed. The resulting physical =
shows that the indexes are a classic mess with thousands of orphans at =
level and excessive levels and SR8s hopelessly randomised over the area.
During the day there are a few more records added by the online system =
naturally we experience quite a high number of I/Os in the index areas =
a lot of orphan adoption and a certain number of deadlocks pretty much
exclusively attributable to SR8 contention.
I thought I would try and improve the situation by running IDMSTUNE =
the big load to rebalance and resequence the indexes with the goal of =
reducing daily I/O and bringing the number of deadlocks down. I ran it =
first time last night. The IDMSTUNE runs very well and we end up with a =
smaller set of index structures with all the orphans adopted. On paper =
looks really good.
The statistics today show that the I/O in the index areas has been =
reduced although the run time for the transactions is only marginally
quicker. Each transaction is only adding one record so it was pretty =
instant before the tune. The thing the users didn't like was the =
of deadlocks.=20
However I now have 10 times as many deadlocks as before. The tidy =
is actually worse in end user terms than the mangled mess we had before.
I had to try it to see what would happen. It was a good try but in this =
IDMSTUNE is not a great help. All I have done is to reduce the number of =
records and concentrated the update activity making the situation worse.
I think I need an IDMSDETUNE utility.=20
Chris Trayler, IXD
Bank Julius Baer & Co. Ltd.
P. O. Box, CH-8010 Z=FCrich, Switzerland
Telephone +41 (0)58 887 4332, Fax +41 (0)58 887 4969 <>=20
*****JuliusBaer Disclaimer***** This e-mail is for the intended =
only and may contain confidential or privileged information. If you have
received this e-mail by mistake, please contact us immediately and
completely delete it (and any attachments) and do not forward it or =
any other person of its contents. If you send us messages by e-mail, we =
this as your authorization to correspond with you by e-mail, however, we
will not accept the electronic transmission of orders/instructions =
without a
specific agreement being in place to govern the same. If you do not wish =
receive any further e-mail correspondence please let us know. E-mail
transmission cannot be guaranteed to be secure or error-free as =
could be intercepted, amended, corrupted, lost, destroyed, arrive late =
incomplete, or contain viruses. Neither the Julius Baer Group nor the =
accept liability for any errors or omissions in the content of this =
which arise as a result of its e-mail transmission. Please note that all
e-mail communications to and from the Julius Baer Group may be =
This communication is for informational purposes only. It is not =
intended as
an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction.
IDMS 3rd-party providers forum


Re: IDMSTUNE - Interesting effect
"I'm just starting to look at this utility. I needed to put a few APARs on,
most notably non-zero page group support.

Did you ""tune"" your index with putting free space into it (IBC change, page
reserve)? That might help with your deadlock issue. Packing a heavy update
index tightly is usually a bad idea. They need room to expand naturally.

Also, this utility says it doesn't work on unlinked indexes. We've been
unlinking everything we can to eliminate orphans. I think we are out luck
using this to rebalance these guys.

How was your run time? We expect this thing to be slow on large indexes.
Our fear is it won't finish overnight. Do you have zIIP or MT active? Does
this utility take advantage of either?

Mark Grindstaff