I have a client who is experiencing some problems with SELECTs on a very
large file with two B-tree indices.

This baby has around 28 million items in it, and when we try to select
them based on the client code (which is indexed), we come up with too
few items. The indices were rebuilt just a couple of weeks ago, and I'd
rather not have to go through that again (big file, takes a while). So I
thought I'd check with the group to see if there are any known problem
with huge files and indexed selects.

I'm running a VERIFY-INDEX at present, but I'm not sure that the damned
thing works all that well.

Any thoughts?

Cheers,
Luke

try
set-runaway-limit MoreThanYouHave

Luke,

Is this D3/NT?

If the index is JUST on the client code, there are some limits IIRC
(64,000 duplicates?)

As per previous suggestions in this thread, assuming a unique
(sequential) key to the transaction file, if the client code were in,
say, <3>, then creating the index on

A3:"*:":A0

With a corresponding dict item you can then get effective use of the
index with something like INDEXDICT = "custcode*]" from TCL, and
likewise from basic with a simple KEY loop

ALSO, historically I've been "suspicious" of indices on D3/NT with
files out in the FSI (which is where this puppy would live, I'm sure)
as we have had "funny" index issues for years, and at some sites an
INDEXER phantom job every weekend is useful

hth

Early versions of D3/Linux had a problem with losing leaves in the index
under certain conditions.

It seemed that the verify-index help fix the problem but could also cause
too many item being selected after the verify-index. This problem was
corrected at or before 7.2.1.

Regards,

Dale

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote

Hi Luke,

We've never found indexes on D3/NT to be reliable. Gave up using them.
Maybe they've improved in more recent versions.

---
Kevin Powick

Kevin Powick wrote:
They certainly have. Index corruptions were commonplace a couple of
major releases ago, but things have settled down a lot now. However,
this time I think I'm in trouble again. The VERIFY-INDEX process hung at
PX_RESUME:000, showing "2:8713000". I imagine that means it's badly
corrupted in some way.

Luke

Luke Webber wrote:

What do TData have to say?

GVP wrote:
I'm not sure what that would achieve, but I do know that I don't want to
try it. <g>

Thanks anyway.

Luke

Ross Ferris wrote:
There are? I'm pretty certain that it's not as low as 64K, if there is one.

Can anybody confirm or deny that there is a limit to the number on
non-unique keys in a b-tree index?

We had major problems with older releases, but have found indices to be
almot rock solid for a couple of years now. I'll rebuild the indices on
this file as soon as I get the chance and see what happens then.

Cheers,
Luke

If there's a difference on D3 between rebuilding and deleting/recreating, do
the latter. In Universe, sometimes merely rebuilding an index with a
corrupted map record will produce the same corruption in the indexes as
before the rebuild. I suppose it could happen in D3 and may explain why your
recent rebuild didn't last very long.

Ed

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote