how to troubleshoot slow running queries? [message #616089] |
Thu, 12 June 2014 04:25  |
 |
kiranrathodkr916
Messages: 36 Registered: March 2014 Location: India
|
Member |
|
|
The following SQL statement has been identified to perform poorly. It currently takes up to 16 mins to execute, but it's supposed to take a second at most.
SQL>
SELECT Object_Class,
2 Object_Sub_Class,
3 Object_Category,
4 Object_Key,
5 Object_ID,
6 Object_Name,
7 IsHidden,
8 Sharing_Key,
9 Ownership_Key,
10 PictureSheet_Key,
11 HasPictureBlob
12 FROM Objects
13 WHERE Deletion_Flag <> 'Y' AND (Sharing_Key IN (0, 3375705, 1199264));
42345 rows selected.
Elapsed: 00:16:29.08
Execution Plan
----------------------------------------------------------
Plan hash value: 970566107
-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 38712 | 3629K| 634 (2)| 00:00:08 |
|* 1 | TABLE ACCESS FULL| OBJECTS | 38712 | 3629K| 634 (2)| 00:00:08 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(("SHARING_KEY"=0 OR "SHARING_KEY"=1199264 OR
"SHARING_KEY"=3375705) AND "DELETION_FLAG"<>'Y')
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
5140 consistent gets
0 physical reads
0 redo size
2920666 bytes sent via SQL*Net to client
20001 bytes received via SQL*Net from client
2824 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
42345 rows processed
db version 11.2
unique index on column Object_Key
I'm looking forward for suggestions how to improve the performance of this statement.
|
|
|
Re: how to troubleshoot slow running queries? [message #616090 is a reply to message #616089] |
Thu, 12 June 2014 04:30   |
John Watson
Messages: 8966 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Sixteen minutes for 5140 consistent gets? You have a problem that is not related to the SQL: something is blocking your session. To begin the diagnosis, while it is executing run this from a another session a few times:
select event,seconds_in_wait from v$session where wait_class<>'Idle';
|
|
|
|
Re: how to troubleshoot slow running queries? [message #616112 is a reply to message #616110] |
Thu, 12 June 2014 06:05   |
John Watson
Messages: 8966 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
None of those wait events are to do with the session being blocked, so I have no idea why a query that reads only 5000 blocks would take so long. Sorry.
You'll have to do a proper analysis. I would start by using dbms_monitor to trace the session, with wait events. tkprof the trace file (with sys=no aggregate=no) and perhaps it will become clearer.
|
|
|
|
|
|
|
|
|
|
Re: how to troubleshoot slow running queries? [message #616242 is a reply to message #616120] |
Sat, 14 June 2014 02:04  |
John Watson
Messages: 8966 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
BlackSwan wrote on Thu, 12 June 2014 14:02is query launched from DB Server?
is query launched from from remote client?
>2920666 bytes sent via SQL*Net to client
>2824 SQL*Net roundtrips to/from client
it appears to me that it just took a while to push the results across the wire back to the client
about 15 records per each round trip. 15 is the default arraysize for SQL*Plus. To test,
SET ARRAYSIZE 5000
and run again. This will reduce the round-trips to bout 10, and is the maximum size SQL*Plus permits.
|
|
|