RE: V5Rx Nuances

[jpcarr@xxxxxxxxxxxx]

Vern

You are semicorrect.
It the locking.   With the 1TB access path, the locking is at a much lower
level on the Radix Binary Tree.

So instead of locking the entire main Branch, it locks at way down at a
much smaller branch. The result is that many fewer rows are actually
locked.  This was very true when inserting Keys (ie New Records) into the
file.

Bottom Line.
Much Better,  No Pain,  Make it the default, recreate older files to the
new 1TB size when possible.


(also,  EVI's I believe perform much better now.  They are very valuable to
the Optimizer to decide which way to process the file for a Where Request.)

John Carr

-------------------------------
Mark, there's no necessary relationship between any of these things. I just
created an EVI, and the ACCPTHSIZ attribute is not even in the description.
EVIs, however, _can_ help make selection (WHERE clauses) work faster, if
used for the bitmap access method. Their maintenance has been rather
expensive in the past - I don't remember if this has improved in V5R2.

The help for ACCPTHSIZ says that high contention on an index can be helped
with the 1TB access path size. Associated with this, I believe, is the
locking behavior - the lock is at the record level, rather than at the
memory page level. something about, if you lock a record in an index, all
the other records in the including page are also locked in the 4GB type.

Someone help me here, I could be way off.

I did just see that access paths of a 1TB size cannot share those of a 4GB
size. That could have adverse affects on performance.

I also just saw a reference to a FRCRBDAP parameter that defaults to *NO -
there could be a lot of _delayed_ rebuilding going on, even when you change
to the larger size.

Search on "accpthsiz site:ibm.com" on google.

Regards

Vern