ron
Member
OE 10.1C on Solaris. (Heading for 11.6 Q1 next year.)
I have collected two months of tableStat in indexStat into an Excel report to analyse. Several "interesting" things for me to chase - but one thing stands-out as being quite strange; something I haven't seen before.
The VST details are collected hourly, 24x7. During peak times one table (nm-hdr) has around 400,000 reads, 15,000 creates, nil deletes and 30,000 updates. That looks OK. The table has 7 indexes and two of them have what appears to me as being a ridiculous number of reads. Index "status-ix" has about 200,000,000 reads and index "type-ix" has about 200,000,000 reads also. They are never identical - but they are always within about 1% of each other.
To my mind there is a major problem here. Can anyone explain what Progress might be doing to cause a situation like this? Is it possible, for example, that a query is specifying keys that don't match an index - but somehow Progress is "joining" two indexes in some way?
Here is what the index definitions look like:
![upload_2016-10-27_18-5-4.png upload_2016-10-27_18-5-4.png](https://www.progresstalk.com/data/attachments/1/1215-fba112f1eb9c8caba71c8ca5f284afb9.jpg)
The fact that each index only includes one field is, of course, extremely suspicious.
Comments very much appreciated.
Ron.
I have collected two months of tableStat in indexStat into an Excel report to analyse. Several "interesting" things for me to chase - but one thing stands-out as being quite strange; something I haven't seen before.
The VST details are collected hourly, 24x7. During peak times one table (nm-hdr) has around 400,000 reads, 15,000 creates, nil deletes and 30,000 updates. That looks OK. The table has 7 indexes and two of them have what appears to me as being a ridiculous number of reads. Index "status-ix" has about 200,000,000 reads and index "type-ix" has about 200,000,000 reads also. They are never identical - but they are always within about 1% of each other.
To my mind there is a major problem here. Can anyone explain what Progress might be doing to cause a situation like this? Is it possible, for example, that a query is specifying keys that don't match an index - but somehow Progress is "joining" two indexes in some way?
Here is what the index definitions look like:
![upload_2016-10-27_18-5-4.png upload_2016-10-27_18-5-4.png](https://www.progresstalk.com/data/attachments/1/1215-fba112f1eb9c8caba71c8ca5f284afb9.jpg)
The fact that each index only includes one field is, of course, extremely suspicious.
Comments very much appreciated.
Ron.