ca.portal.admin

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 =
records
into a structure which is heavily indexed. The resulting physical =
structure
shows that the indexes are a classic mess with thousands of orphans at =
every
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 =
and
naturally we experience quite a high number of I/Os in the index areas =
plus
a lot of orphan adoption and a certain number of deadlocks pretty much
exclusively attributable to SR8 contention.
=20
I thought I would try and improve the situation by running IDMSTUNE =
after
the big load to rebalance and resequence the indexes with the goal of =
both
reducing daily I/O and bringing the number of deadlocks down. I ran it =
the
first time last night. The IDMSTUNE runs very well and we end up with a =
much
smaller set of index structures with all the orphans adopted. On paper =
that
looks really good.
=20
The statistics today show that the I/O in the index areas has been =
massively
reduced although the run time for the transactions is only marginally
quicker. Each transaction is only adding one record so it was pretty =
much
instant before the tune. The thing the users didn't like was the =
incidence
of deadlocks.=20
=20
However I now have 10 times as many deadlocks as before. The tidy =
structure
is actually worse in end user terms than the mangled mess we had before.
=20
I had to try it to see what would happen. It was a good try but in this =
case
IDMSTUNE is not a great help. All I have done is to reduce the number of =
SR8
records and concentrated the update activity making the situation worse.
=20
I think I need an IDMSDETUNE utility.=20
=20
______________________________________________________________
=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
www.juliusbaer.com <http://www.juliusbaer.com/>=20
=20
______________________________________________________________
=20
*****JuliusBaer Disclaimer***** This e-mail is for the intended =
recipient
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 =
inform
any other person of its contents. If you send us messages by e-mail, we =
take
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 =
to
receive any further e-mail correspondence please let us know. E-mail
transmission cannot be guaranteed to be secure or error-free as =
information
could be intercepted, amended, corrupted, lost, destroyed, arrive late =
or
incomplete, or contain viruses. Neither the Julius Baer Group nor the =
sender
accept liability for any errors or omissions in the content of this =
message
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 =
monitored.
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
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
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

Outcomes