Question _indexstat With No Corresponding _index?

ron

Member
OE 10.1C0407 on Solaris. (Soon migrating to OE 11.6.)

I am new to this site. I wrote this short piece of code to show me info about _IndexStat:

DEF VAR naym AS CHAR.
DEF VAR i AS INT.
DEF STREAM xx.
OUTPUT STREAM xx TO /tmp/ronz.

FOR EACH _indexstat NO-LOCK
BY _indexstat-id:
FIND _index no-lock WHERE _idx-num = _indexstat-id NO-ERROR.
IF AVAIL(_index) THEN ASSIGN naym = _index-name.
ELSE ASSIGN naym = "** UNKNOWN **".
ASSIGN i = i + 1.
DISPLAY STREAM xx
i _indexstat-id FORMAT ">>>>>>9" LABEL "Number"
naym FORMAT "x(20)" LABEL "Name".
END.


I was surprised to find that quite a few _IndexStat records had no corresponding _Index record - as shown below. I have displayed the top and bottom of the list - and in the middle only the ones where there is a mismatch.

I'm curious as to why this has happened. Could it be that the value of -indexrangesize is not large enough?

(BTW - there is a similar problem where some _TableStat records do not have corresponding _File records.)

Ron.

i Number Name
---------- ------- --------------------
1 8 k-accmgrhd
2 9 k-manf-dest
3 10 k-manf-orig
4 11 k-probill-dest
5 12 k-probill-orig
6 13 k-accmgrhd
7 14 k-primary
8 15 k-aemvtln
9 16 k-adjust
10 17 k-aemvtlnid
11 18 k-reference
12 19 k-aemvthdid
13 20 k-busref2
14 21 k-busref3
15 22 k-mnfseq
16 23 k-mnftripleg
17 24 k-ref2
18 25 ** UNKNOWN **
19 26 ** UNKNOWN **
20 27 ** UNKNOWN **
21 28 ** UNKNOWN **
22 29 ** UNKNOWN **
23 30 ** UNKNOWN **
24 31 ** UNKNOWN **
25 32 k-reconid
26 33 k-aevact
27 34 k-ref
28 35 k-reference
29 36 k-refcode
30 37 k-spcode
================================
92 99 ** UNKNOWN **
289 296 ** UNKNOWN **
290 297 ** UNKNOWN **
291 298 ** UNKNOWN **
292 299 ** UNKNOWN **
293 300 ** UNKNOWN **
294 301 ** UNKNOWN **
295 302 ** UNKNOWN **
296 303 ** UNKNOWN **
297 304 ** UNKNOWN **
298 305 ** UNKNOWN **
304 311 ** UNKNOWN **
367 374 ** UNKNOWN **
406 413 ** UNKNOWN **
418 425 ** UNKNOWN **
================================
638 645 cmm-ix
639 646 pronumb-ix
640 647 date-ix
641 648 k-id
642 649 k-bu-ref
643 650 k-created
644 651 k-ref
645 652 k-blobid
646 653 k-created
647 654 k-modified
648 655 k-ref
649 656 k-key
650 657 k-blobid
651 658 k-created
652 659 k-modified
653 660 k-processed
654 661 k-storageid
655 662 k-systemid
656 663 k-type
657 664 k-inv-ref
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
That's interesting. It appears you have started your DB with -baseindex 8 rather than the default. Not that that's important, i just means you won't have stats for system indexes 1 through 7. This can be interesting information.

It is possible for application index numbers, and table numbers, to be non-contiguous due to schema changes. If you have freshly created a database from a .df then the numbers will probably be contiguous, but it depends on the .df contents. Sometimes a schema change will involve the Data Dictionary code creating temporary indexes and then deleting them, so index numbers in particular can show gaps after a while. So the lesson for writing robust VST code is don't assume that every _tablestat-id or _indexstat-id corresponds to an object. You have to check against the meta-schema, as you have done.

At a minimum (assuming -basetable and -baseindex are at their default values of 1), you want -tablerangesize to be greater than or equal to your highest application table number and -indexrangesize to be greater than or equal to your highest application index number. Given that these values can only be increased with a DB restart, I always set them a fair bit higher than the minimums so that if I apply online schema changes that add new tables or indexes, I will have immediate access to CRUD stats for those objects.

You can find your minimums like this:
Code:
find last dictdb._file no-lock where _file._tbl-type = 't' use-index _file-number.
find last dictdb._index no-lock where not _index._index-name begins "_" use-index _index-number.
display _file._file-number _index._idx-num
 
Top