ca.portal.admin

Re: Tune Index

Discussion created by ca.portal.admin on Jan 15, 2007
Hello Mike:

The performance improvement would be almost impossible to calculate
because of the way the index is used, insertions, deletions, index
sizing, displacement and page reserve, there are just to many
variables.

My experience with ""tune index"" is that if you attempt to run it in
Central Version mode it will execute a lot longer than a normal
""rebuild from index""
in local mode. I would assume that this is due to journal activity and
orphan adoption? During orphan adoption the calls to IDMS skyrocketed?

Also you will not see a large decrease in the number of SR8 records or
an increase in the space available percentage with tune index.

I tried ""tune index"" on a very large index with a very large number of
orphans and it ran for over 12 hours before I canceled the job.

Over the weekend I ran a normal ""rebuild from index"" and it executed in
approximately four hours.

I can't say if you will have a similar experience but my experience with
""tune index"" on very large indexes with a large number of orphans was
not that good.

Bill Allen

In a message dated 1/15/2007 9:08:43 P.M. Eastern Standard Time,
mikebaker345@HOTMAIL.COM writes:

Hi all,

What is the best way to estimate the performance improvement resulting
from running the ""TUNE INDEX"" utility?

Does anyone actually do this, or do you just run ""Tune Index"", knowing
that whatever orphans are adopted will improve the database
performance.
Whether the performance improvement be 1.o% or 5.0% who really cares?

After running ""Print Index"" on one particular Index, Level 0 has about
100,000 orphans within 431 SR8s.

It would be nice to measure the performance gain if its not too
difficult.

Thank you.

Mike.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Print Index - report output
"See manual: CA-IDMS Database Administration - Structure of Indexes

This is the short version:
ODBK=Owner DBKey - The dbkey of the Owner record before this entry you
should have Owner=ownerrecordtype
The Two SR8 entries are the low and high symbolic keys in the SR8.
NUME= number of entries in SR8
N= Next SR8
P= Prior SR8
U= Up Pointer (I believe) (Owning SR8)
Cush= Cushion
SYM TKL = Has me stumped, but appears to be cushion - 9 (SYMbolic Total
Key Length ???)

Tommy Petersen
110 Cokesbury Rd
Room 542H
Lebanon, NJ 08833

Phone:
Internal 200 - 3699
External (908) 236-3699
Fax: (908) 236-3692




Mike Baker
<mikebaker345@HOT
MAIL.COM> To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion cc
Forum
<IDMS-L@LISTSERV. Subject
IUASSN.COM> Print Index - report output


01/14/2007 11:59
PM


Please respond to
IDMS Public
Discussion Forum
<IDMS-L@LISTSERV.
IUASSN.COM>






Hi all,

I have some questions about how to interpret the output of the ""PRINT
INDEX"" command. I've looked inside the manuals, and its still not very
clear. See sample display below of the first output line:

ODBK=EC4FAA01 SR8 NEC5AF206 SR8 PEC72CC07 ASC CUSH=50 SYM TKL=41 UNCM

Q1: What does ODBK mean? Something database key?
Q2: What is ""NEC5AF206"", and ""PEC72CC07""? They refer to the SR8.
Q3: What is CUSH=50?
Q4: What is SYM TKL=41?

ASC means ascending. UNCM means uncompressed.

See sample display below of the second output line:

L4 EC5AF206 NUME=5 U=FFFFFFFF N=EC50B106 P=EC4FAA01
RECL=2332 SPA=4772

L4 means it is an SR8 at the fourth level.
EC5AF206 is presumably the Key of this SR8?

Q5: What does NUME=5 mean?
Q6: What is ""U=FFFFFFFF"", ""N=EC50B106"", and ""P=EC4FAA01""?
Q7: What is SPA=4772?


Thanks very much.

Mike.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Tune Index
"Mike,

I agree with Bill that it is almost impossible to gauge the benefit of a
TUNE INDEX unless you have some type of retrieval only job that is using
the index and you run it before and after. I also agree that it is not
to be used for large indexes with a large number of orphans.

The advantage of TUNE IDNEX is that you can run it in CV mode with
minimal impact to production. However, I have run into some issues
where it will lock out online processes. The other caveat is that, if
you have severely fragmented indexes, it can fill your lock table and
hang CV if storage pool 255 fills and overflows to pool zero.

I recommend that you test this process on your test environment and set
the COMMIT count as low as you can. Use performance monitor to monitor
your storage pools and if the pool starts to approach the max, kill the
process with OPER. This process will kick out a lot of journals. But
with the number of SR8's you mention and the number of orphans, there is
a high likelihood that you have severe fragmentation and will have to do
a REBUILD.

Hope this helps.

Regards,

Jim Criscuolo

Outcomes