Abnormal high "query" count in customer tkprof output

Question

We have a performance problem with one of our customer.
A query is made on a 12K rows table, and there is no full scan, the index is used.
If we run the query on our test database, which is identical, and examine the tkprof output, things appears normal:
Fetch=80, cpu=0.0, disk=0, query=15738,rows=782
But the same query, on and identical table, same index at our customer:
Fetch=831, cpu=4.75, disk=141, query=550564, rows=830
I dont unerstand what is the "query" parameter, the number of cache buffers read in memory ?
It is unbeleivebly high, further more, hard to understand high number of rows in the execution plan:
Ours
1570 TABLE ACCESS BY INDEX ROWID MY_SECRET_TABLE_NAME
1570 INDEX RANGE SCAN MY_PRIMARY_KEY_INDEX
Customers:
88413 TABLE ACCESS BY INDEX ROWID MY_SECRET_TABLE_NAME
92917 INDEX RANGE SCAN MY_PRIMARY_KEY_INDEX
We dont understand such high numbers. On theory, from our former DBA, was that our indexes where not create properly. A unique key index was create, then a primary constraint with the same name, was added to the table. Apparently we should have created only the constraint, and not the second index.
Any help appreciated.

Answer 1

Hi Guy,
Query = db block gets + consistent gets.
Consistent gets are the block reads you need to reconstruct a read-consistent image of the data.
If you can't fetch all records at a time, you will get multiple fetches. At each fetch Oracle will issue consistent gets, as it needs to provide to you the data in the state when you started the query.
Looking at your statistics, it is quite clear what happened.
Fetch=80, cpu=0.0, disk=0, query=15738,rows=782
782 rows in 80 fetches. Roughly 10 rows per fetch.
But the same query, on an identical table, same index at our customer:
Fetch=831, cpu=4.75, disk=141, query=550564, rows=830
830 rows in 830 fetches (the last fetch is to check there is no more data), which means 1 row per fetch.
In both cases: consistent gets at every fetch.
Somehow your client has made sure, by means of a setting, he will fetch only 1 row at a time. And that is killing him.
Nothing wrong with any index.
Hth
Sybrand Bakker
Senior Oracle DBA