SQL Query Tuning issue

Question

A query run by the 'tom' user who searches on (xyz crieteria) takes less than 5 seconds.
However, when the user 'greg' ruuns the same query, it take > 14 minutes to execute for same xyz crieteria.
Note:both are application users and internally use DOCD database user.Both are using same SQL Explain plan but diffrence is disk read in case of long running query.
my question is if both queries are same and using same explain plan and returning same rows why there is disk read???? and such huge diffrence in execution time...Below is the tkprof output for both the queries.
QUICK QUERY
===========
SELECT E_NAME, E_CURVER_NUM, E_CURVER_CKO, E_PROTECTED, E_INA01, E_INA26,
E_INA47, V_FILE_NAME, E_ICON_TITLE, E_INA41, E_INA11, E_INA16, E_INA40,
E_INA15, E_INA35, E_ORG_FILENAME, E_COMMENT, E_INA28, E_INA27,
E_CREATE_DATE, E_OWNER, E_LAST_DATE, V_CHECKED_OUT, V_CHECKIN_USER, V_NAME,
V_E_NAME, V_AVAIL_STAT, V_RECLAIM, V_PERMANENT, V_CSI_STATUS, V_CD, E_INA01,
V_INA03, V_INA02, V_INA04, E_INA02, V_INA01, V_CREATE_DATE, E_INA03
FROM
ELEMENT, VERSION WHERE (NLS_UPPER(E_INA01) LIKE NLS_UPPER(:V001) AND
NLS_UPPER(E_INA26) = NLS_UPPER(:V002) AND E_INA02 IS NULL AND (E_INA03 IS
NULL OR E_INA03 = :V003) AND V_BRANCH_CURVER = :V004) AND ELEMENT.E_NAME =
VERSION.V_E_NAME ORDER BY 12, 10 DESC, 1, 26, 25
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 167 0.18 0.18 0 29466 0 1002
total 169 0.20 0.19 0 29466 0 1002
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 41
Rows Row Source Operation
1002 SORT ORDER BY (cr=29466 r=0 w=0 time=179192 us)
8847 NESTED LOOPS (cr=29466 r=0 w=0 time=146638 us)
14191 TABLE ACCESS FULL VERSION (cr=1082 r=0 w=0 time=25337 us)
8847 TABLE ACCESS BY INDEX ROWID ELEMENT (cr=28384 r=0 w=0 time=97209 us)
14191 INDEX UNIQUE SCAN UI256 (cr=14193 r=0 w=0 time=30388 us)(object id 29956)
SLOW QUERY
==========
SELECT E_NAME, E_CURVER_NUM, E_CURVER_CKO, E_PROTECTED, E_INA01, E_INA26,
E_INA47, V_FILE_NAME, E_ICON_TITLE, E_INA41, E_INA11, E_INA16, E_INA40,
E_INA15, E_INA35, E_ORG_FILENAME, E_COMMENT, E_INA28, E_INA27,
E_CREATE_DATE, E_OWNER, E_LAST_DATE, V_CHECKED_OUT, V_CHECKIN_USER, V_NAME,
V_E_NAME, V_AVAIL_STAT, V_RECLAIM, V_PERMANENT, V_CSI_STATUS, V_CD, E_INA01,
V_INA03, V_INA02, V_INA04, E_INA02, V_INA01, V_CREATE_DATE, E_INA03
FROM
ELEMENT, VERSION WHERE (NLS_UPPER(E_INA01) LIKE NLS_UPPER(:V001) AND
NLS_UPPER(E_INA26) = NLS_UPPER(:V002) AND E_INA02 IS NULL AND (E_INA03 IS
NULL OR E_INA03 = :V003) AND V_BRANCH_CURVER = :V004) AND ELEMENT.E_NAME =
VERSION.V_E_NAME ORDER BY 12, 10 DESC, 1, 26, 25
call count cpu elapsed disk query current rows
Parse 1 0.01 0.02 2 2 0 0
Execute 1 0.01 0.00 0 0 0 0
Fetch 167 0.29 1.18 2389 29466 0 1002
total 169 0.32 1.21 2391 29468 0 1002
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 41
Rows Row Source Operation
1002 SORT ORDER BY (cr=29466 r=2389 w=0 time=1180072 us)
8847 NESTED LOOPS (cr=29466 r=2389 w=0 time=1144811 us)
14191 TABLE ACCESS FULL VERSION (cr=1082 r=1078 w=0 time=134164 us)
8847 TABLE ACCESS BY INDEX ROWID ELEMENT (cr=28384 r=1311 w=0 time=984455 us)
14191 INDEX UNIQUE SCAN UI256 (cr=14193 r=137 w=0 time=127843 us)(object id 29956)

Answer 1

Anuj,
In the future, when posting items to the forum where spacing is critical to proper understanding, please use the { code } tags (without spaces) to retain the spacing.
It appears that there is more to the story than what has been reported. It is good that you used tkprof, as it shows that there is more to the story. Taking a look at the two executions, the tkprof output shows that the first (quick) execution completed in 0.19 seconds, while the second (slow) execution completed in 1.21 seconds, even with th 2,391 blocks read from disk. My first question, if I were in the same situation, would be what would cause the first execution time to jump from 0.19 seconds to 5 seconds, and the second execution to jump from 1.21 seconds to 840 seconds (14 minutes)?
In both cases, there is a library cache miss on both the parse and the execute calls - there may be some significance to this.
In both cases, there were 167 fetch calls to return 1,002 rows, meaning that on average 6 rows were returned on each fetch.
Let's assume that 'tom', whose query executed quickly, was connected to the database over a T1 connection with a 20ms (0.02 second) ping time. For siimplicity in calculation, assume that there were 170 round trips between the server and the client. The network communication between the client and the server would require at least 3.4 seconds, for a total time to send the query and retrieve the results of about 3.6 seconds. This is a little short of 5 seconds which you reported.
Let's assume that 'greg', whose query executed slowly, was connected to the database over a satellite connection with a 2000ms (2 second) ping time. With the same number of round trips, the network communication would require about 340 seconds, for a total time to send the query and retrieve the results of about 341.21 seconds (5.7 minutes), about 8 minutes short of the target 14 minutes.
Was this the only query executed by the clients, or were there multiple queries?
Were the client computers on the same network segment?
Did you gather a 10046 trace at level 8 or 12 for the sessions? If so, manually review the wait events in the trace files to see if it is possible to determine what was happening during the 14 minutes. Guessing can be fun, but sometimes you come up 8 minutes short by guessing alone.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.