>Just a heads-up: at a client I ran into a situation where missing index tags caused extreme slowness.
>
>In my case a table (in a DBC) with just under a million rows has a CDX file which was supposed to have 8 tags: one on the primary key plus 7 others. Somehow, the 7 non-PK index tags were no longer present, only the PK tag remained.
>
>With the "bad" CDX a test report took 22 minutes to run.
>
>When replaced with a "good" one and reindexed, it took 5 seconds to run (250x faster).
>
>Over the years I've encountered a number of corrupted CDX scenarios. However they've always been such that the app won't start at all or crashes quickly with an obvious index problem. This is the first time I've run into tags that just silently went missing, without causing any functionality problems with the app (other than slowness).
There was some sense in Rushmore :)
That's strange.
So I have some questions.
Is the CDX just with one tag? Then, how can a CDX be changed so that it is not corrupted (i.o.w working) other then by DELETE TAG? So to do the question the other way around what is causing DELETE TAG in you app?
Is the size of it something like the size of a new created CDX with just the PK?
Does seek return meaningfull results. IOW depending on your design, is iot possible to copy - rename an other CDX? My approach would work, sort of at least. The PK seems to be related to record by coincidence (incrementing number - RECNO() )
But this might fail for records not in the
wrong file. A run comparing seek with the result?
Lutz
Are the
missing tags there but with other expressions? Since rushmore does not look at the tag but on the expression, what is changing the expression?
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord
Weeks of programming can save you hours of planning.
OffThere is no place like [::1]