Query's Execution time VS Cost.
hello,
I have tuned a query for speed of execution. The result is the query executed in less than 1 sec whereas the older one took more than 50Sec.
But the problem is the new query is very much costly (Cast as taken from executio plan is 54K).
Please tell me, is this 54k a very high value? Is it taxing on the server resources when nearly 1000 users run the same query at the same time?
Thanks,
Aswin.
Edited by: ice_cold_aswin on Sep 9, 2008 4:26 PM
Execution plan #1:
Time: 52 Sec
Plan:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 68192 | 4661K| | 4863 (2)|
| 1 | TABLE ACCESS BY INDEX ROWID| TABLE_LOC | 1 | 38 | | 4 (0)|
| 2 | INDEX RANGE SCAN | PK_LOCS | 1 | | | 3 (0)|
| 3 | SORT AGGREGATE | | 1 | 14 | | |
| 4 | TABLE ACCESS FULL | TABLE_PAT | 10 | 140 | | 1815 (3)|
| 5 | SORT AGGREGATE | | 1 | 14 | | |
| 6 | TABLE ACCESS FULL | TABLE_PAT | 18 | 252 | | 1815 (3)|
| 7 | SORT UNIQUE | | 68192 | 4661K| 10M| 3729 (2)|
| 8 | HASH JOIN | | 68192 | 4661K| | 2596 (3)|
| 9 | TABLE ACCESS FULL | TABLE_PHC | 1628 | 26048 | | 9 (0)|
| 10 | HASH JOIN | | 68192 | 3596K| 2072K| 2585 (3)|
| 11 | TABLE ACCESS FULL | TABLE_PAT | 68192 | 1265K| | 1818 (3)|
| 12 | TABLE ACCESS FULL | TABLE_LOC | 103K| 3547K| | 430 (1)|
--------------------------------------------------------------------------------------------Execution Plan #2
Time taken to exec: 0.8 Sec
Plan:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 3990K| 799M| | 5678K (1)|
| 1 | SORT ORDER BY | | 3990K| 799M| 1685M| 5678K (1)|
| 2 | HASH JOIN RIGHT OUTER | | 3990K| 799M| | 5495K (1)|
| 3 | TABLE ACCESS FULL | TABLE_PHC | 1628 | 37444 | | 9 (0)|
| 4 | HASH JOIN OUTER | | 3990K| 711M| | 5495K (1)|
| 5 | TABLE ACCESS FULL | TABLE_LOC | 17299 | 641K| | 434 (2)|
| 6 | VIEW | | 23M| 3402M| | 5495K (1)|
| 7 | SORT UNIQUE | | 23M| 17G| 40G| 5495K (51)|
| 8 | UNION-ALL | | | | | |
| 9 | HASH JOIN OUTER | | 11M| 9178M| 13M| 6166 (5)|
| 10 | VIEW | | 34599 | 13M| | 2337 (3)|
| 11 | HASH JOIN RIGHT OUTER| | 34599 | 2905K| | 2337 (3)|
| 12 | VIEW | | 11789 | 552K| | 1902 (3)|
| 13 | HASH GROUP BY | | 11789 | 276K| 936K| 1902 (3)|
| 14 | TABLE ACCESS FULL | TABLE_PAT | 11789 | 276K| | 1816 (3)|
| 15 | TABLE ACCESS FULL | TABLE_LOC | 34599 | 1283K| | 434 (2)|
| 16 | VIEW | | 34599 | 13M| | 2300 (3)|
| 17 | HASH JOIN RIGHT OUTER| | 34599 | 2905K| | 2300 (3)|
| 18 | VIEW | | 6430 | 301K| | 1865 (3)|
| 19 | HASH GROUP BY | | 6430 | 150K| 520K| 1865 (3)|
| 20 | TABLE ACCESS FULL | TABLE_PAT | 6430 | 150K| | 1815 (3)|
| 21 | TABLE ACCESS FULL | TABLE_LOC | 34599 | 1283K| | 434 (2)|
| 22 | HASH JOIN OUTER | | 11M| 9178M| 13M| 6166 (5)|
| 23 | VIEW | | 34599 | 13M| | 2300 (3)|
| 24 | HASH JOIN RIGHT OUTER| | 34599 | 2905K| | 2300 (3)|
| 25 | VIEW | | 6430 | 301K| | 1865 (3)|
| 26 | HASH GROUP BY | | 6430 | 150K| 520K| 1865 (3)|
| 27 | TABLE ACCESS FULL | TABLE_PAT | 6430 | 150K| | 1815 (3)|
| 28 | TABLE ACCESS FULL | TABLE_LOC | 34599 | 1283K| | 434 (2)|
| 29 | VIEW | | 34599 | 13M| | 2337 (3)|
| 30 | HASH JOIN RIGHT OUTER| | 34599 | 2905K| | 2337 (3)|
| 31 | VIEW | | 11789 | 552K| | 1902 (3)|
| 32 | HASH GROUP BY | | 11789 | 276K| 936K| 1902 (3)|
| 33 | TABLE ACCESS FULL | TABLE_PAT | 11789 | 276K| | 1816 (3)|
| 34 | TABLE ACCESS FULL | TABLE_LOC | 34599 | 1283K| | 434 (2)|
----------------------------------------------------------------------------------------------Thanks in Advance,
Aswin.
Edited by: ice_cold_aswin on Sep 9, 2008 4:32 PM
Similar Messages
-
How to learn sql query's execution time?
Hello All,
I am trying to find out the execution times of deterministic and non-deterministic function. Hence I have run following script and want to compare their execution times etc. Should I use v$sql? If so, which coloumns? Because I couln't find.
{code}
create table my_table
as
select mod(level,10)*10 col from dual connect by level <= 100 order by 1;
create or replace function my_det(giris number)
return number deterministic
is
num number;
begin
num :=giris*10;
return num;
end;
create or replace function my_func(giris number)
return number
is
num number;
begin
num :=giris*10;
return num;
end;
select my_det(col) from my_table; --First I want to run this query
select my_func(col) from my_table; --Then this query
{code}
What should I do in order to compare these two in terms of execution, fetch times, etc.?
Thanks in advance.Hello NightWig
As you're on 11g, if you have queries that take more than a few seconds I'd definitely recommend looking at the real-time SQL monitor (assuming you're appropriately licensed). As the name suggests, it shows the progress of an SQL statement in real-time, breaking down how long each operation has taken with details of rows fetched so far. It also keeps details of recently executed queries for a short while so can see how your changes affect a statement.
Oracle SQL Monitoring documentation:http://docs.oracle.com/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF94543
Thank you -
SQL Query + long execution time.
Dear Gurus/masters/All,
I request you all to help me in tuning the SQL query which is taking more time. DB Version : 10.2.0.4
SQL Query WHERE condition:
select column1, column2, .........
FROM
SIEBEL.S_ORG_EXT T1,
SIEBEL.S_PROD_INT T2,
SIEBEL.S_VOD T3,
SIEBEL.S_ORG_EXT T4,
SIEBEL.S_ORG_EXT T5,
SIEBEL.S_ORG_EXT_X T6,
SIEBEL.S_PROD_LN T7,
SIEBEL.S_ASSET_OM T8,
SIEBEL.S_VOD_VER T9,
SIEBEL.S_CTLG_CAT T10,
SIEBEL.S_CONTACT T11,
SIEBEL.S_PARTY T12,
SIEBEL.S_PARTY T13,
SIEBEL.S_PROD_INT T14,
SIEBEL.S_ASSET_BU T15,
SIEBEL.S_CTLG_CAT T16,
SIEBEL.S_ORG_EXT T17,
SIEBEL.S_ORG_EXT T18,
SIEBEL.S_ASSET T19,
SIEBEL.S_ADDR_PER T20,
SIEBEL.S_ORG_EXT T21,
SIEBEL.S_ASSET_X T22,
SIEBEL.S_ASSET T23
WHERE
T16.PAR_CAT_ID = T10.ROW_ID (+) AND
T14.CG_PR_CTLG_CAT_ID = T16.ROW_ID (+) AND
T3.ROW_ID = T9.VOD_ID AND
T14.CFG_MODEL_ID = T3.OBJECT_NUM AND
T23.OWNER_CON_ID = T11.ROW_ID (+) AND
T23.OWNER_ACCNT_ID = T6.PAR_ROW_ID (+) AND
T23.PER_ADDR_ID = T20.ROW_ID (+) AND
T23.PROD_ID = T14.ROW_ID AND
T23.OWNER_ACCNT_ID = T21.PAR_ROW_ID (+) AND
T14.PR_PROD_LN_ID = T7.ROW_ID (+) AND
T23.ROOT_ASSET_ID = T19.ROW_ID (+) AND
T19.PROD_ID = T2.ROW_ID (+) AND
T23.BILL_ACCNT_ID = T18.PAR_ROW_ID (+) AND
T23.RTNG_DLR_ID = T1.PAR_ROW_ID (+) AND
T23.PREF_SRV_DLR_ID = T17.PAR_ROW_ID (+) AND
T23.DLR_ID = T4.PAR_ROW_ID (+) AND
T23.ROW_ID = T22.PAR_ROW_ID (+) AND
T23.ROW_ID = T8.PAR_ROW_ID (+) AND
T23.PR_CON_ID = T12.ROW_ID (+) AND
T23.BU_ID = T15.BU_ID (+) AND T23.ROW_ID = T15.ASSET_ID (+) AND
T15.BU_ID = T13.ROW_ID (+) AND
T15.BU_ID = T5.PAR_ROW_ID (+) AND
((T23.SERIAL_NUM IS NOT NULL AND T23.PAR_ASSET_ID IS NULL OR T23.X_PHONE_NUMBER IS NOT NULL AND T23.PAR_ASSET_ID IS NOT NULL) AND
(T9.VER_NUM = :1));Query Exection Plan:
PLAN_TABLE_OUTPUT
Plan hash value: 967177145
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 54117 | 92M| 4435K (1)| 01:58:43 |
| 1 | NESTED LOOPS OUTER | | 54117 | 92M| 4435K (1)| 01:58:43 |
| 2 | NESTED LOOPS OUTER | | 54117 | 87M| 4261K (1)| 01:54:04 |
| 3 | NESTED LOOPS OUTER | | 54117 | 86M| 4154K (1)| 01:51:13 |
| 4 | NESTED LOOPS OUTER | | 54117 | 85M| 4111K (1)| 01:50:03 |
| 5 | NESTED LOOPS OUTER | | 54117 | 84M| 3980K (1)| 01:46:33 |
| 6 | NESTED LOOPS OUTER | | 54117 | 83M| 3937K (1)| 01:45:24 |
| 7 | NESTED LOOPS OUTER | | 54117 | 81M| 3763K (1)| 01:40:44 |
| 8 | NESTED LOOPS OUTER | | 54117 | 81M| 3751K (1)| 01:40:25 |
| 9 | NESTED LOOPS OUTER | | 54117 | 80M| 3621K (1)| 01:36:57 |
| 10 | NESTED LOOPS OUTER | | 54117 | 73M| 3515K (1)| 01:34:07 |
| 11 | NESTED LOOPS OUTER | | 54117 | 71M| 3410K (1)| 01:31:18 |
| 12 | NESTED LOOPS OUTER | | 54117 | 69M| 3410K (1)| 01:31:18 |
| 13 | NESTED LOOPS OUTER | | 54117 | 67M| 3410K (1)| 01:31:18 |
| 14 | NESTED LOOPS OUTER | | 54117 | 66M| 3410K (1)| 01:31:18 |
| 15 | NESTED LOOPS OUTER | | 54117 | 64M| 3324K (1)| 01:28:59 |
| 16 | NESTED LOOPS OUTER | | 54117 | 62M| 3237K (1)| 01:26:40 |
| 17 | NESTED LOOPS | | 54117 | 57M| 3106K (1)| 01:23:10 |
| 18 | NESTED LOOPS OUTER | | 71 | 43665 | 381 (2)| 00:00:01 |
| 19 | NESTED LOOPS OUTER | | 71 | 42316 | 323 (2)| 00:00:01 |
| 20 | NESTED LOOPS OUTER | | 71 | 41322 | 322 (2)| 00:00:01 |
| 21 | NESTED LOOPS | | 71 | 24708 | 265 (3)| 00:00:01 |
| 22 | NESTED LOOPS | | 77 | 2772 | 141 (4)| 00:00:01 |
|* 23 | TABLE ACCESS FULL | S_VOD_VER | 75 | 1350 | 72 (7)| 00:00:01 |
| 24 | TABLE ACCESS BY INDEX ROWID| S_VOD | 1 | 18 | 1 (0)| 00:00:01 |
|* 25 | INDEX UNIQUE SCAN | S_VOD_P1 | 1 | | 1 (0)| 00:00:01 |
| 26 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 312 | 2 (0)| 00:00:01 |
|* 27 | INDEX RANGE SCAN | S_PROD_INT_F9 | 1 | | 1 (0)| 00:00:01 |
| 28 | TABLE ACCESS BY INDEX ROWID | S_PROD_LN | 1 | 234 | 1 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | S_PROD_LN_P1 | 1 | | 1 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 1 | 14 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 1 | | 1 (0)| 00:00:01 |
| 32 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 1 | 19 | 1 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 1 | | 1 (0)| 00:00:01 |
|* 34 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 760 | 375K| 43753 (1)| 00:01:11 |
|* 35 | INDEX RANGE SCAN | S_ASSET_U2 | 55873 | | 312 (3)| 00:00:01 |
| 36 | TABLE ACCESS BY INDEX ROWID | S_ASSET_OM | 1 | 94 | 2 (0)| 00:00:01 |
|* 37 | INDEX RANGE SCAN | S_ASSET_OM_U1 | 1 | | 2 (0)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 | 39 | 2 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 29 | 2 (0)| 00:00:01 |
|* 41 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | 1 (0)| 00:00:01 |
| 42 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | 1 (0)| 00:00:01 |
|* 43 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 44 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | 1 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 46 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | 1 (0)| 00:00:01 |
|* 47 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 48 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 36 | 2 (0)| 00:00:01 |
|* 49 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 50 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 139 | 2 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 1 | 16 | 2 (0)| 00:00:01 |
|* 53 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 1 | | 2 (0)| 00:00:01 |
|* 54 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | 12 | 1 (0)| 00:00:01 |
| 55 | TABLE ACCESS BY INDEX ROWID | S_ASSET_BU | 1 | 34 | 3 (0)| 00:00:01 |
|* 56 | INDEX RANGE SCAN | S_ASSET_BU_U1 | 1 | | 2 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | 12 | 1 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 1 | 37 | 2 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | S_ASSET_P1 | 1 | | 2 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 16 | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_ASSET_X | 1 | 93 | 3 (0)| 00:00:01 |
|* 65 | INDEX RANGE SCAN | S_ASSET_X_U1 | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
23 - filter("T9"."VER_NUM"=TO_NUMBER(:1))
25 - access("T3"."ROW_ID"="T9"."VOD_ID")
27 - access("T14"."CFG_MODEL_ID"="T3"."OBJECT_NUM")
29 - access("T14"."PR_PROD_LN_ID"="T7"."ROW_ID"(+))
31 - access("T14"."CG_PR_CTLG_CAT_ID"="T16"."ROW_ID"(+))
33 - access("T16"."PAR_CAT_ID"="T10"."ROW_ID"(+))
34 - filter("T23"."PAR_ASSET_ID" IS NULL AND "T23"."SERIAL_NUM" IS NOT NULL OR "T23"."X_PHONE_NUMBER" IS
NOT NULL AND "T23"."PAR_ASSET_ID" IS NOT NULL)
35 - access("T23"."PROD_ID"="T14"."ROW_ID")
37 - access("T23"."ROW_ID"="T8"."PAR_ROW_ID"(+))
39 - access("T23"."OWNER_CON_ID"="T11"."ROW_ID"(+))
41 - access("T23"."PER_ADDR_ID"="T20"."ROW_ID"(+))
43 - access("T23"."RTNG_DLR_ID"="T1"."PAR_ROW_ID"(+))
45 - access("T23"."DLR_ID"="T4"."PAR_ROW_ID"(+))
47 - access("T23"."PREF_SRV_DLR_ID"="T17"."PAR_ROW_ID"(+))
49 - access("T23"."BILL_ACCNT_ID"="T18"."PAR_ROW_ID"(+))
51 - access("T23"."OWNER_ACCNT_ID"="T21"."PAR_ROW_ID"(+))
53 - access("T23"."OWNER_ACCNT_ID"="T6"."PAR_ROW_ID"(+))
54 - access("T23"."PR_CON_ID"="T12"."ROW_ID"(+))
56 - access("T23"."ROW_ID"="T15"."ASSET_ID"(+) AND "T23"."BU_ID"="T15"."BU_ID"(+))
57 - access("T15"."BU_ID"="T13"."ROW_ID"(+))
59 - access("T23"."ROOT_ASSET_ID"="T19"."ROW_ID"(+))
61 - access("T19"."PROD_ID"="T2"."ROW_ID"(+))
63 - access("T15"."BU_ID"="T5"."PAR_ROW_ID"(+))
65 - access("T23"."ROW_ID"="T22"."PAR_ROW_ID"(+))
Note
- dynamic sampling used for this statement
105 rows selected.out put of dbms_xplan.display_cursor :
SQL> select * from table(dbms_xplan.display_cursor('xxxxxxxxxxxxxx',NULL,'iostats last'));
PLAN_TABLE_OUTPUT
SQL_ID xxxxxxxxxxxxxx, child number 0
SELECT T23.CONFLICT_ID, T23.LAST_UPD, T23.CREATED, T23.LAST_UPD_BY, T23.CREATED_BY,
T23.MODIFICATION_NUM, T23.ROW_ID, T23.ASSET_NUM, T21.LOC, T21.NAME, T23.INSTALL_DT,
T23.INVLOC_ID, T23.NAME, T23.OU_ADDR_ID, T23.OWNER_ACCNT_ID, T23.PAR_ASSET_ID, T23.PER_ADDR_ID,
T20.STATE, T23.PR_CON_ID, T23.PR_EMP_ID, T14.DESC_TEXT, T23.PROD_ID, T14.NAME,
T21.INTEGRATION_ID, T23.COST_LST_ID, T14.SERIALIZED_FLG, T23.REGISTERED_DT, T23.SERIAL_NUM,
T23.VERSION, T23.STATUS_CD, T14.PR_PROD_LN_ID, T7.NAME, T23.QTY, T23.ASSET_COND_CD,
T23.PR_ACCNT_ID, T23.OWNERSHIP_TYPE_CD, T23.XA_CLASS_ID, T23.OPER_STATUS_CD, T23.SP_NUM,
T23.BILL_ACCNT_ID, T23.SERV_ACCT_ID, T9.RELEASED_FLG, T23.CFG_TYPE_CD, T9.VER_NUM, T23.END_DT,
T23.ASSEMBLY_PORT_ID,
Plan hash value: xxxxxxxxxxxxxx
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
| 1 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.99 | 1236K| 460K|
| 2 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.99 | 1236K| 460K|
| 3 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.85 | 1236K| 460K|
| 4 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.69 | 1236K| 460K|
| 5 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.69 | 1236K| 460K|
| 6 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.69 | 1236K| 460K|
| 7 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.47 | 1236K| 460K|
| 8 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.47 | 1236K| 460K|
| 9 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.37 | 1236K| 460K|
| 10 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.22 | 1236K| 460K|
| 11 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.16 | 1236K| 460K|
| 12 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.16 | 1236K| 460K|
| 13 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.16 | 1236K| 460K|
| 14 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.16 | 1236K| 460K|
| 15 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.09 | 1236K| 460K|
| 16 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:57.99 | 1236K| 460K|
| 17 | NESTED LOOPS | | 1 | 11 | 10 |00:23:57.98 | 1236K| 460K|
| 18 | NESTED LOOPS OUTER | | 1 | 1 | 57 |00:00:00.02 | 828 | 0 |
| 19 | NESTED LOOPS OUTER | | 1 | 2 | 57 |00:00:00.02 | 828 | 0 |
| 20 | NESTED LOOPS OUTER | | 1 | 2 | 57 |00:00:00.02 | 828 | 0 |
| 21 | NESTED LOOPS | | 1 | 2 | 57 |00:00:00.01 | 786 | 0 |
| 22 | NESTED LOOPS | | 1 | 2 | 232 |00:00:00.01 | 493 | 0 |
|* 23 | TABLE ACCESS FULL | S_VOD_VER | 1 | 75 | 246 |00:00:00.01 | 12 | 0 |
| 24 | TABLE ACCESS BY INDEX ROWID| S_VOD | 246 | 1 | 232 |00:00:00.01 | 481 | 0 |
|* 25 | INDEX UNIQUE SCAN | S_VOD_P1 | 246 | 1 | 232 |00:00:00.01 | 249 | 0 |
| 26 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 232 | 1 | 57 |00:00:00.01 | 293 | 0 |
|* 27 | INDEX RANGE SCAN | S_PROD_INT_F9 | 232 | 1 | 57 |00:00:00.01 | 236 | 0 |
| 28 | TABLE ACCESS BY INDEX ROWID | S_PROD_LN | 57 | 1 | 39 |00:00:00.01 | 42 | 0 |
|* 29 | INDEX UNIQUE SCAN | S_PROD_LN_P1 | 57 | 1 | 39 |00:00:00.01 | 3 | 0 |
| 30 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 31 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 32 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 33 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 34 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 57 | 10 | 10 |00:23:57.97 | 1235K| 460K|
|* 35 | INDEX RANGE SCAN | S_ASSET_U2 | 57 | 734 | 627K|00:00:01.34 | 4295 | 2032 |
| 36 | TABLE ACCESS BY INDEX ROWID | S_ASSET_OM | 10 | 1 | 0 |00:00:00.01 | 26 | 2 |
|* 37 | INDEX RANGE SCAN | S_ASSET_OM_U1 | 10 | 1 | 0 |00:00:00.01 | 26 | 2 |
| 38 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 10 | 1 | 10 |00:00:00.11 | 36 | 12 |
|* 39 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 10 | 1 | 10 |00:00:00.06 | 26 | 6 |
| 40 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 10 | 1 | 10 |00:00:00.07 | 36 | 18 |
|* 41 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 10 | 1 | 10 |00:00:00.04 | 26 | 8 |
| 42 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 43 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 44 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 45 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 46 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 47 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 48 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.05 | 46 | 12 |
|* 49 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.03 | 26 | 6 |
| 50 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.15 | 55 | 23 |
|* 51 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.04 | 26 | 6 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 10 | 1 | 10 |00:00:00.10 | 40 | 12 |
|* 53 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 10 | 1 | 10 |00:00:00.05 | 30 | 6 |
|* 54 | INDEX UNIQUE SCAN | S_PARTY_P1 | 10 | 1 | 0 |00:00:00.01 | 5 | 0 |
| 55 | TABLE ACCESS BY INDEX ROWID | S_ASSET_BU | 10 | 1 | 10 |00:00:00.22 | 50 | 29 |
|* 56 | INDEX RANGE SCAN | S_ASSET_BU_U1 | 10 | 1 | 10 |00:00:00.15 | 40 | 19 |
| 57 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.01 | 36 | 0 |
|* 58 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
|* 59 | INDEX UNIQUE SCAN | S_PARTY_P1 | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_ASSET_X | 10 | 1 | 10 |00:00:00.16 | 50 | 20 |
|* 61 | INDEX RANGE SCAN | S_ASSET_X_U1 | 10 | 1 | 10 |00:00:00.09 | 40 | 10 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 10 | 1 | 10 |00:00:00.14 | 46 | 19 |
|* 63 | INDEX UNIQUE SCAN | S_ASSET_P1 | 10 | 1 | 10 |00:00:00.04 | 36 | 9 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
|* 65 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 10 | 1 | 10 |00:00:00.01 | 16 | 0 |
Predicate Information (identified by operation id):
23 - filter("T9"."VER_NUM"=:1)
25 - access("T3"."ROW_ID"="T9"."VOD_ID")
27 - access("T14"."CFG_MODEL_ID"="T3"."OBJECT_NUM")
29 - access("T14"."PR_PROD_LN_ID"="T7"."ROW_ID")
31 - access("T14"."CG_PR_CTLG_CAT_ID"="T16"."ROW_ID")
33 - access("T16"."PAR_CAT_ID"="T10"."ROW_ID")
34 - filter((("T23"."PAR_ASSET_ID" IS NULL AND "T23"."SERIAL_NUM" IS NOT NULL) OR ("T23"."X_PHONE_NUMBER" IS NOT NULL AND
"T23"."PAR_ASSET_ID" IS NOT NULL)))
35 - access("T23"."PROD_ID"="T14"."ROW_ID")
37 - access("T23"."ROW_ID"="T8"."PAR_ROW_ID")
39 - access("T23"."OWNER_CON_ID"="T11"."ROW_ID")
41 - access("T23"."PER_ADDR_ID"="T20"."ROW_ID")
43 - access("T23"."RTNG_DLR_ID"="T1"."PAR_ROW_ID")
45 - access("T23"."DLR_ID"="T4"."PAR_ROW_ID")
47 - access("T23"."PREF_SRV_DLR_ID"="T17"."PAR_ROW_ID")
49 - access("T23"."BILL_ACCNT_ID"="T18"."PAR_ROW_ID")
51 - access("T23"."OWNER_ACCNT_ID"="T21"."PAR_ROW_ID")
53 - access("T23"."OWNER_ACCNT_ID"="T6"."PAR_ROW_ID")
54 - access("T23"."PR_CON_ID"="T12"."ROW_ID")
56 - access("T23"."ROW_ID"="T15"."ASSET_ID" AND "T23"."BU_ID"="T15"."BU_ID")
58 - access("T15"."BU_ID"="T5"."PAR_ROW_ID")
59 - access("T15"."BU_ID"="T13"."ROW_ID")
61 - access("T23"."ROW_ID"="T22"."PAR_ROW_ID")
63 - access("T23"."ROOT_ASSET_ID"="T19"."ROW_ID")
65 - access("T19"."PROD_ID"="T2"."ROW_ID")
SQL_ID xxxxxxxxxxxxxx, child number 1
SELECT T23.CONFLICT_ID, T23.LAST_UPD, T23.CREATED, T23.LAST_UPD_BY, T23.CREATED_BY,
T23.MODIFICATION_NUM, T23.ROW_ID, T23.ASSET_NUM, T21.LOC, T21.NAME, T23.INSTALL_DT,
T23.INVLOC_ID, T23.NAME, T23.OU_ADDR_ID, T23.OWNER_ACCNT_ID, T23.PAR_ASSET_ID, T23.PER_ADDR_ID,
T20.STATE, T23.PR_CON_ID, T23.PR_EMP_ID, T14.DESC_TEXT, T23.PROD_ID, T14.NAME,
T21.INTEGRATION_ID, T23.COST_LST_ID, T14.SERIALIZED_FLG, T23.REGISTERED_DT, T23.SERIAL_NUM,
T23.VERSION, T23.STATUS_CD, T14.PR_PROD_LN_ID, T7.NAME, T23.QTY, T23.ASSET_COND_CD,
T23.PR_ACCNT_ID, T23.OWNERSHIP_TYPE_CD, T23.XA_CLASS_ID, T23.OPER_STATUS_CD, T23.SP_NUM,
T23.BILL_ACCNT_ID, T23.SERV_ACCT_ID, T9.RELEASED_FLG, T23.CFG_TYPE_CD, T9.VER_NUM, T23.END_DT,
T23.ASSEMBLY_PORT_ID,
Plan hash value: xxxxxxxxxxxxxx
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
| 1 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:15.04 | 1237K| 512K|
| 2 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:15.04 | 1237K| 512K|
| 3 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:14.92 | 1237K| 512K|
| 4 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:14.82 | 1237K| 512K|
| 5 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:14.82 | 1237K| 512K|
| 6 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:14.82 | 1237K| 512K|
| 7 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.64 | 1237K| 512K|
| 8 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.63 | 1237K| 512K|
| 9 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.51 | 1237K| 512K|
| 10 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.42 | 1237K| 512K|
| 11 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.33 | 1236K| 512K|
| 12 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.33 | 1236K| 512K|
| 13 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.33 | 1236K| 512K|
| 14 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.33 | 1236K| 512K|
| 15 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.23 | 1236K| 512K|
| 16 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.12 | 1236K| 512K|
| 17 | NESTED LOOPS | | 1 | 11 | 10 |00:28:14.12 | 1236K| 512K|
| 18 | NESTED LOOPS OUTER | | 1 | 1 | 57 |00:00:00.02 | 828 | 0 |
| 19 | NESTED LOOPS OUTER | | 1 | 1 | 57 |00:00:00.02 | 828 | 0 |
| 20 | NESTED LOOPS OUTER | | 1 | 1 | 57 |00:00:00.01 | 828 | 0 |
| 21 | NESTED LOOPS | | 1 | 1 | 57 |00:00:00.01 | 786 | 0 |
| 22 | NESTED LOOPS | | 1 | 2 | 232 |00:00:00.01 | 493 | 0 |
|* 23 | TABLE ACCESS FULL | S_VOD_VER | 1 | 74 | 246 |00:00:00.01 | 12 | 0 |
| 24 | TABLE ACCESS BY INDEX ROWID| S_VOD | 246 | 1 | 232 |00:00:00.01 | 481 | 0 |
|* 25 | INDEX UNIQUE SCAN | S_VOD_P1 | 246 | 1 | 232 |00:00:00.01 | 249 | 0 |
| 26 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 232 | 1 | 57 |00:00:00.01 | 293 | 0 |
|* 27 | INDEX RANGE SCAN | S_PROD_INT_F9 | 232 | 1 | 57 |00:00:00.01 | 236 | 0 |
| 28 | TABLE ACCESS BY INDEX ROWID | S_PROD_LN | 57 | 1 | 39 |00:00:00.01 | 42 | 0 |
|* 29 | INDEX UNIQUE SCAN | S_PROD_LN_P1 | 57 | 1 | 39 |00:00:00.01 | 3 | 0 |
| 30 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 31 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 32 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 33 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 34 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 57 | 10 | 10 |00:28:14.10 | 1236K| 512K|
|* 35 | INDEX RANGE SCAN | S_ASSET_U2 | 57 | 734 | 627K|00:00:01.26 | 4299 | 3327 |
| 36 | TABLE ACCESS BY INDEX ROWID | S_ASSET_OM | 10 | 1 | 0 |00:00:00.01 | 26 | 2 |
|* 37 | INDEX RANGE SCAN | S_ASSET_OM_U1 | 10 | 1 | 0 |00:00:00.01 | 26 | 2 |
| 38 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 10 | 1 | 10 |00:00:00.10 | 36 | 18 |
|* 39 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 10 | 1 | 10 |00:00:00.04 | 26 | 9 |
| 40 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 10 | 1 | 10 |00:00:00.11 | 36 | 20 |
|* 41 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 10 | 1 | 10 |00:00:00.04 | 26 | 10 |
| 42 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 43 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 44 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 45 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 46 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 47 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 48 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.09 | 46 | 18 |
|* 49 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.05 | 26 | 9 |
| 50 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.09 | 55 | 32 |
|* 51 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.02 | 26 | 8 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 10 | 1 | 10 |00:00:00.13 | 40 | 18 |
|* 53 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 10 | 1 | 10 |00:00:00.06 | 30 | 9 |
|* 54 | INDEX UNIQUE SCAN | S_PARTY_P1 | 10 | 1 | 0 |00:00:00.01 | 5 | 0 |
| 55 | TABLE ACCESS BY INDEX ROWID | S_ASSET_BU | 10 | 1 | 10 |00:00:00.18 | 50 | 29 |
|* 56 | INDEX RANGE SCAN | S_ASSET_BU_U1 | 10 | 1 | 10 |00:00:00.11 | 40 | 19 |
| 57 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.01 | 36 | 0 |
|* 58 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
|* 59 | INDEX UNIQUE SCAN | S_PARTY_P1 | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_ASSET_X | 10 | 1 | 10 |00:00:00.10 | 50 | 20 |
|* 61 | INDEX RANGE SCAN | S_ASSET_X_U1 | 10 | 1 | 10 |00:00:00.03 | 40 | 10 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 10 | 1 | 10 |00:00:00.12 | 46 | 20 |
|* 63 | INDEX UNIQUE SCAN | S_ASSET_P1 | 10 | 1 | 10 |00:00:00.06 | 36 | 10 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
|* 65 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 10 | 1 | 10 |00:00:00.01 | 16 | 0 |
Predicate Information (identified by operation id):
23 - filter("T9"."VER_NUM"=:1)
25 - access("T3"."ROW_ID"="T9"."VOD_ID")
27 - access("T14"."CFG_MODEL_ID"="T3"."OBJECT_NUM")
29 - access("T14"."PR_PROD_LN_ID"="T7"."ROW_ID")
31 - access("T14"."CG_PR_CTLG_CAT_ID"="T16"."ROW_ID")
33 - access("T16"."PAR_CAT_ID"="T10"."ROW_ID")
34 - filter((("T23"."PAR_ASSET_ID" IS NULL AND "T23"."SERIAL_NUM" IS NOT NULL) OR ("T23"."X_PHONE_NUMBER" IS NOT NULL AND
"T23"."PAR_ASSET_ID" IS NOT NULL)))
35 - access("T23"."PROD_ID"="T14"."ROW_ID")
37 - access("T23"."ROW_ID"="T8"."PAR_ROW_ID")
39 - access("T23"."OWNER_CON_ID"="T11"."ROW_ID")
41 - access("T23"."PER_ADDR_ID"="T20"."ROW_ID")
43 - access("T23"."RTNG_DLR_ID"="T1"."PAR_ROW_ID")
45 - access("T23"."DLR_ID"="T4"."PAR_ROW_ID")
47 - access("T23"."PREF_SRV_DLR_ID"="T17"."PAR_ROW_ID")
49 - access("T23"."BILL_ACCNT_ID"="T18"."PAR_ROW_ID")
51 - access("T23"."OWNER_ACCNT_ID"="T21"."PAR_ROW_ID")
53 - access("T23"."OWNER_ACCNT_ID"="T6"."PAR_ROW_ID")
54 - access("T23"."PR_CON_ID"="T12"."ROW_ID")
56 - access("T23"."ROW_ID"="T15"."ASSET_ID" AND "T23"."BU_ID"="T15"."BU_ID")
58 - access("T15"."BU_ID"="T5"."PAR_ROW_ID")
59 - access("T15"."BU_ID"="T13"."ROW_ID")
61 - access("T23"."ROW_ID"="T22"."PAR_ROW_ID")
63 - access("T23"."ROOT_ASSET_ID"="T19"."ROW_ID")
65 - access("T19"."PROD_ID"="T2"."ROW_ID")
226 rows selected.
SQL > -
Execution time, elapsed time of an sql query
Can you please tell me how to get the execution time, elapsed time of an sql query
user8680248 wrote:
I am running query in the database
I would like to know how long the query take the time to completeWhy? That answer can be totally meaningless as the VERY SAME query on the VERY SAME data on the VERY SAME database in the VERY SAME Oracle session can and will show DIFFERENT execution times.
So why do you want to know a specific query's execution time? What do you expect that to tell you?
If you mean that you want to know how long an existing query being executed is still going to take - that's usually quite difficult to determine. Oracle does provide a view on so-called long operations. However, only certain factors of a query's execution will trigger that this query is a long operation - and only for those specific queries will there be long operation stats that provide an estimated completion time.
If your slow and long running query does not show in long operation, then Oracle does not consider it a long operation - it fails to meet the specific criteria and factors required as a long operation. This is not a bug or an error. Simply that your query does not meet the basic requirements to be viewed as a long operation.
Oracle however provides the developer with the means to create long operations (using PL/SQL). You need to know and do the following:
a) need to know how many units of work to do (e.g. how many fetches/loop iterations/rows your code will process)
b) need to know how many units of work thus far done
c) use the DBMS_APPLICATION_INFO package to create a long operation and continually update the operation with the number of work units thus far done
It is pretty easy to implement this in PL/SQL processing code (assuming requirements a and b can be met) - and provide long operation stats and estimated completion time for the DBA/operators/users of the database, waiting on your process to complete. -
How query cost and execution time are releated ?
hi experts,
i am curious to know, how the query cost and execution time is related?
Query taking less time ,query cost is 65%, but query taking more time but query cost is 0%.
how to connect both and improve query performance.
Thanksi think you are refering to cost (relative to the batch) execution 65%, where there are more that one statement, it may compare the cost of each statement with in the batch
i assume it mainly take subtree cost and IO stat as cost, but in some cases i may wrong when there is multi line function and many other facter influence the cost, and i would say it depends on the query
cost is unit-less
The reason these costs exist is because of the query optimization SQL Server does: it does cost-based optimization, which means that the optimizer formulates a lot of different ways to execute the query, assigns a cost to each of these alternatives, and
chooses the one with the least cost. The cost tagged on each alternative is heurestically calculated, and is supposed to roughly reflect the amount of processing and I/O this alternative is going to take.
refer :
http://blogs.msdn.com/b/sqlqueryprocessing/archive/2006/10/11/what-is-this-cost.aspx
Thanks
Saravana kumar C -
Execution time of query on different indexes
Hello,
I have a query on the table, the execution time has hugh difference using different indexes on the table. The table has about 200,000 rows. Any explaination on it?
Thanks,
create table TB_test
( A1 number(9),
A2 number(9)
select count(*) from TB_test
where A1=123 and A2=456;
A. With index IDX_test on column A1:
Create index IDX_test on TB_test(A1);
Explain plan:
SELECT STATEMENT
Cost: 3,100
SORT AGGREGATE
Bytes: 38 Cardinality: 1
TABLE ACCESS BY INDEX ROWID TABLE TB_test
Cost: 3,100 Bytes: 36 Cardinality: 1
INDEX RANGE SCAN INDEX IDX_test
Cost: 40 Cardinality: 21,271
Execution time is : 5 Minutes
B. With index IDX_test on column A1 and A2:
Create index IDX_test on TB_test(A1, A2);
Explain plan:
SELECT STATMENT
Cost: 3 Bytes: 37 Cardinality: 1
SORT AGGREGATE
Bytes: 37 Cardinality: 1
INDEX RANGE SCAN INDEZ IDX_test
Cost: 3 Bytes 37 Cardinality:1
Execution time is: 1.5 SecondsAdditional you should check how many values you have in your table for the specific column values.
The following select might be helful for that.
select count(*) "total_count"
,count(case when A1=123 then 1 end) "A1_count"
,count(case when A1=123 and A2=456 then 1 end) "A1andA2_count"
from TB_test;Share your output of this.
I expect the value for A1_count still to be high. But the value for A1+A2_count relatively low.
However 5 minutes is far to long for such a small table. Even if you run it on a laptop.
There must be a reason why it is that slow.
First thing to consider would be to update your statistics for the table and the index.
Second thing could be that the table is very sparsly fillled. Meaning, if you frequently delete records from this table and load new data using APPEND hint, then the table will grow, because the free space from the deletes is never reused. Any table access in the execution plan, will be slower then needed.
A similar thing can happen, if many updates on previously empty columns are made on a table (row chaining problem).
So if you explain a little, how this table is filled and used, we could recognize a typical pattern that leads to performance issues.
Edited by: Sven W. on Nov 28, 2012 5:54 PM -
Reduce the execution time for the below query
Hi,
Please help me to reduce the execution time on the following query .. if any tuning is possible.
I have a table A with the columns :
ID , ORG_LINEAGE , INCLUDE_IND ( -- the org lineage is a string of ID's. If ID 5 reports to 4 and 4 to 1 .. the lineage for 5 will be stored as the string -1-4-5)
Below is the query ..
select ID
from A a
where INCLUDE_IND = '1' and
exists (
select 1
from A b
where b.ID = '5'
and b.ORG_LINEAGE like '%-'||a.ID||'-%'
order by ORG_LINEAGE;
The only constraint on the table A is the primary key on the ID column.
Following will be the execution plan :
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=406 Card=379 Bytes=2
653)
1 0 SORT (ORDER BY) (Cost=27 Card=379 Bytes=2653)
2 1 FILTER
3 2 TABLE ACCESS (FULL) OF 'A' (Cost=24 Card
=379 Bytes=2653)
4 2 TABLE ACCESS (BY INDEX ROWID) OF 'A' (Co
st=1 Card=1 Bytes=6)
5 4 INDEX (RANGE SCAN) OF 'ORG_LINEAGE'
(NON-UNIQUE)I order it by the org_lineage to get the first person. So it is a result problem? The order by doesn't give you the first person, it gives you a sorted result set (of which there may be zero, one, or thousands).
If you only want one row from that, then you're spending a lot of time tuning the wrong query.
How do you know which ORG_LINEAGE row you want?
Maybe it would help if you posted some sample data. -
Query Database: reduce execution time
Hi to all,
I have Oracle 11g R2.
I want reduce to max the execution time of this my select:
SELECT a.ID, a.FULLNAME, a.L_AXON, a.R_AXON, a.L_LAXON, a.R_LAXON, a.L_F_F_ADD, a.R_F_F_ADD, a.L_T_F_ADD, a.R_T_F_ADD, a.L_PC, a.R_PC FROM ITALIA_GC a WHERE SDO_WITHIN_DISTANCE(a.GEOMETRY, MDSYS.SDO_GEOMETRY(2001, 8307, MDSYS.SDO_POINT_TYPE(13.8268523, 41.491619, NULL) ,NULL, NULL), 'DISTANCE=100 UNIT=M') = 'TRUE' AND ROWNUM=1;
This query returns the name, city, postal code and address of a street of Italy. These datas are in ITALIA_GC table.
I already created an spatial index on GEOMETRY field of this table:
CREATE INDEX ITALIA_GC_IDX ON ITALIA_GC(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
How can I see the execution time (i need to know the execution time in milliseconds) of this query and how can I reduce to max it?
thank you very much in advance.
CrystalThank you.
I used explain plan and SQL*Trace/tkprof method.
What I would like to know is if the execution time are misured in seconds or milliseconds (I wish to know misure in millisecond).
The result of SQL*Trace/tkprof method is:
TKPROF: Release 11.2.0.1.0 - Development on Tue Jul 27 15:33:28 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: dbuir_ora_29053.trc
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SQL ID: 1bf1x0q79c1rm
Plan Hash: 2374671442
SELECT a.ID, a.FULLNAME, a.L_AXON, a.R_AXON, a.L_LAXON, a.R_LAXON,
a.L_F_F_ADD, a.R_F_F_ADD, a.L_T_F_ADD, a.R_T_F_ADD, a.L_PC, a.R_PC
FROM
ITALIA_GC a WHERE SDO_WITHIN_DISTANCE(a.GEOMETRY, MDSYS.SDO_GEOMETRY(2001,
8307, MDSYS.SDO_POINT_TYPE(13.8268523, 41.491619, NULL) ,NULL, NULL),
'DISTANCE=100 UNIT=M') = 'TRUE' AND ROWNUM=1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.02 0 30 2 0
Fetch 2 0.00 0.00 0 14 0 1
total 4 0.00 0.02 0 44 2 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 85
Rows Row Source Operation
1 COUNT STOPKEY (cr=110 pr=0 pw=0 time=0 us)
1 TABLE ACCESS BY INDEX ROWID ITALIA_GC (cr=110 pr=0 pw=0 time=0 us cost=0 size=4142 card=1)
1 DOMAIN INDEX ITALIA_GC_IDX (cr=109 pr=0 pw=0 time=0 us cost=0 size=0 card=0)
SQL ID: 20y2xs9zmrbc5
Plan Hash: 4105568395
SELECT a."GEOMETRY"
FROM
"SPATIAL".ITALIA_GC a where a.rowid=:rid
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 20 0.00 0.00 0 0 0 0
Fetch 20 0.00 0.00 0 20 0 20
total 41 0.00 0.00 0 20 0 20
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 85 (recursive depth: 1)
Rows Row Source Operation
1 TABLE ACCESS BY USER ROWID ITALIA_GC (cr=1 pr=0 pw=0 time=0 us cost=1 size=3831 card=1)
SQL ID: 9pxc8jgf3tj20
Plan Hash: 1946957531
SELECT diminfo, nvl(srid,-1)
FROM
ALL_SDO_GEOM_METADATA WHERE OWNER = :own AND TABLE_NAME = NLS_UPPER(:tab)
AND '"'||COLUMN_NAME||'"' = :col
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 9 0 1
total 3 0.00 0.00 0 9 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 85 (recursive depth: 1)
Rows Row Source Operation
1 VIEW ALL_SDO_GEOM_METADATA (cr=9 pr=0 pw=0 time=0 us cost=25 size=654 card=2)
1 UNION-ALL (cr=9 pr=0 pw=0 time=0 us)
1 MERGE JOIN CARTESIAN (cr=9 pr=0 pw=0 time=0 us cost=6 size=81 card=1)
1 VIEW ALL_OBJECTS (cr=7 pr=0 pw=0 time=0 us cost=5 size=45 card=1)
1 FILTER (cr=7 pr=0 pw=0 time=0 us)
1 FILTER (cr=7 pr=0 pw=0 time=0 us)
1 NESTED LOOPS (cr=7 pr=0 pw=0 time=0 us cost=5 size=124 card=1)
1 NESTED LOOPS (cr=6 pr=0 pw=0 time=0 us cost=4 size=102 card=1)
1 TABLE ACCESS BY INDEX ROWID USER$ (cr=2 pr=0 pw=0 time=0 us cost=1 size=18 card=1)
1 INDEX UNIQUE SCAN I_USER1 (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 46)
1 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=4 pr=0 pw=0 time=0 us cost=3 size=84 card=1)
1 INDEX RANGE SCAN I_OBJ5 (cr=3 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 40)
1 INDEX RANGE SCAN I_USER2 (cr=1 pr=0 pw=0 time=0 us cost=1 size=22 card=1)(object id 47)
0 TABLE ACCESS BY INDEX ROWID IND$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)
0 INDEX UNIQUE SCAN I_IND1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 41)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=3 size=24 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=11 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=48 card=2)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=11 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=2)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=3 size=24 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=11 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=7 size=78 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=5 size=68 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=4 size=57 card=1)
0 MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=3 size=53 card=1)
0 INDEX RANGE SCAN I_OBJ5 (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=1)(object id 40)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)(object id 62)
0 INDEX RANGE SCAN I_DEPENDENCY1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=3)(object id 106)
0 TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=10 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=72 card=2)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=23 card=1)
0 TABLE ACCESS BY INDEX ROWID TRIGGER$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=12 card=1)
0 INDEX UNIQUE SCAN I_TRIGGER2 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 162)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=2)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=7 size=78 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=5 size=68 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=4 size=57 card=1)
0 MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=3 size=53 card=1)
0 INDEX RANGE SCAN I_OBJ5 (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=1)(object id 40)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)(object id 62)
0 INDEX RANGE SCAN I_DEPENDENCY1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=3)(object id 106)
0 TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=10 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 VIEW (cr=0 pr=0 pw=0 time=0 us cost=2 size=13 card=1)
0 FAST DUAL (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=21 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=21 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 VIEW (cr=0 pr=0 pw=0 time=0 us cost=1 size=16 card=1)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=1 size=86 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=86 card=1)
0 MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=0 size=78 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=0 size=65 card=1)
0 INDEX UNIQUE SCAN I_OLAP_CUBES$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 940)
0 TABLE ACCESS BY INDEX ROWID OLAP_DIMENSIONALITY$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=52 card=1)
0 INDEX RANGE SCAN I_OLAP_DIMENSIONALITY$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 944)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
0 INDEX FULL SCAN I_OLAP_CUBE_DIMENSIONS$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 928)
0 INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=8 card=1)(object id 36)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=29 card=1)
0 INDEX FULL SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)(object id 47)
0 INDEX RANGE SCAN I_OBJ4 (cr=0 pr=0 pw=0 time=0 us cost=1 size=9 card=1)(object id 39)
1 BUFFER SORT (cr=2 pr=0 pw=0 time=0 us cost=6 size=36 card=1)
1 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE (cr=2 pr=0 pw=0 time=0 us cost=1 size=36 card=1)
1 INDEX RANGE SCAN SDO_GEOM_IDX (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 62259)
0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=19 size=293 card=1)
0 MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=18 size=238 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=18 size=225 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=17 size=221 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=16 size=213 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=15 size=209 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=14 size=201 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=13 size=196 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=12 size=185 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=11 size=181 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=9 size=172 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=8 size=144 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=7 size=123 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=6 size=120 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=5 size=90 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=54 card=1)
0 TABLE ACCESS BY INDEX ROWID USER$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=18 card=1)
0 INDEX UNIQUE SCAN I_USER1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 46)
0 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=36 card=1)
0 INDEX RANGE SCAN SDO_GEOM_IDX (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 62259)
0 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us cost=3 size=36 card=1)
0 INDEX RANGE SCAN I_OBJ2 (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 37)
0 TABLE ACCESS CLUSTER TAB$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=30 card=1)
0 INDEX UNIQUE SCAN I_OBJ# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 3)
0 TABLE ACCESS CLUSTER TS$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=3 card=1)
0 INDEX UNIQUE SCAN I_TS# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 7)
0 TABLE ACCESS CLUSTER COL$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=21 card=1)
0 TABLE ACCESS CLUSTER COLTYPE$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=28 card=1)
0 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=9 card=1)
0 INDEX RANGE SCAN I_OBJ3 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 38)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 TABLE ACCESS CLUSTER SEG$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 9)
0 INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=5 card=1)(object id 36)
0 INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=8 card=1)(object id 36)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=8 card=1)(object id 36)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=17 size=1300 card=100)
0 FIXED TABLE FULL X$KSPPCV (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KSPPI (cr=0 pr=0 pw=0 time=0 us cost=0 size=55 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=21 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
********************************************************************************The result of Explain plan method is:
PLAN_TABLE_OUTPUT
Plan hash value: 2374671442
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 1 | 4142 | 0 (0) | 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| ITALIA_GC | 49989 | 197M| 0 (0)| 00:00:01 |
|* 3 | DOMAIN INDEX | ITALIA_GC_IDX | | | 0 (0) | 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
1 - filter(ROWNUM=1)
3 - access("MDSYS"."SDO_WITHIN_DISTANCE"("A"."GEOMETRY","MDSYS"."SDO_GEOMETRY"(2001
PLAN_TABLE_OUTPUT
,8307,"MDSYS"."SDO_POINT_TYPE"(13.8268523,41.491619,NULL),NULL,NULL),'DISTANCE=100 UNIT=M')='TRUE')
Note
- dynamic sampling used for this statement (level=2)
22 rows selected.thank you very much. -
Query execution time estimation....
Hi All,
Is it possible to estimate query execution time using explain plan?
Thanks in advance,
Santosh.The cost estimated by the cost based optimizer is actually representing the time it takes to process the statement expressed in units of the single block read-time. Which means if you know the estimated time a single block read request requires you can translate this into an actual time.
Starting with Oracle 9i this information (the time to perform single block/multi block read requests) is actually available if you gather system statistics.
And this is what 10g actually does, as it shows an estimated TIME in the explain plan output based on these assumptions. Note that 10g by default uses system statistics, even if they are not explicitly gathered. In this case Oracle 10g uses the NOWORKLOAD statistics generated on the fly at instance startup.
Of course the time estimates shown by Oracle 10g may not even be close to the actual execution time as it is only an estimate based on a model and input values (statistics) and therefore might be way off due to several reasons, the same applies in principle to the cost shown.
Regards,
Randolf
Oracle related stuff:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
How to get the query execution time
Hi,
I am new to oracle and I am trying to get the execution time of a query.I tried the command set timing on and executed the query.But,the time it gives me is including the display of results.In my case,I ran a query against 50 million records and it is taking around 5 hours to display all the results.I like to know,how much time it take just to execute the query?Please help.
Thanks
Ravi.Maybe this way ?
TEST@db102 SQL> set timing on
TEST@db102 SQL> set autotrace traceonly
TEST@db102 SQL> select * from foo;
332944 rows selected.
Elapsed: 00:00:29.04
Execution Plan
Plan hash value: 1245013993
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 274K| 46M| 1071 (5)| 00:00:13 |
| 1 | TABLE ACCESS FULL| FOO | 274K| 46M| 1071 (5)| 00:00:13 |
Note
- dynamic sampling used for this statement
Statistics
288 recursive calls
0 db block gets
26570 consistent gets
4975 physical reads
0 redo size
35834383 bytes sent via SQL*Net to client
244537 bytes received via SQL*Net from client
22198 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
332944 rows processed
TEST@db102 SQL> -
How to know query execution time in sql plus
HI
I want to know the query execution time in sql plus along with statistics
I say set time on ;
set autotrace on ;
select * from view where usr_id='abcd';
if the result is 300 rows it scrolls till all the rows are retrieved and finally gives me execution time as 40 seconds or 1 minute.. (this is after all the records are scrolled )
but when i execute it in toad it gives 350 milli seconds..
i want to see the execution time in sql how to do this
database server 11g and client is 10g
regards
rajwhat is the difference between .. the
statistics gathered in sql plus something like this and the one that i get from plan_table in toad?
how to format the execution plan I got in sqlplus in a proper understanding way?
statistics in sqlplus
tatistics
0 recursive calls
0 db block gets
164 consistent gets
0 physical reads
0 redo size
29805 bytes sent via SQL*Net to client
838 bytes received via SQL*Net from client
25 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
352 rows processedexecution plan in sqlplus... how to format this
xecution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=21 Card=1 Bytes=10
03)
1 0 HASH (UNIQUE) (Cost=21 Card=1 Bytes=1003)
2 1 MERGE JOIN (CARTESIAN) (Cost=20 Card=1 Bytes=1003)
3 2 NESTED LOOPS
4 3 NESTED LOOPS (Cost=18 Card=1 Bytes=976)
5 4 NESTED LOOPS (Cost=17 Card=1 Bytes=797)
6 5 NESTED LOOPS (OUTER) (Cost=16 Card=1 Bytes=685)
7 6 NESTED LOOPS (OUTER) (Cost=15 Card=1 Bytes=556
8 7 NESTED LOOPS (Cost=14 Card=1 Bytes=427)
9 8 NESTED LOOPS (Cost=5 Card=1 Bytes=284)
10 9 TABLE ACCESS (BY INDEX ROWID) OF 'USR_XR
EF' (TABLE) (Cost=4 Card=1 Bytes=67)
11 10 INDEX (RANGE SCAN) OF 'USR_XREF_PK' (I
NDEX (UNIQUE)) (Cost=2 Card=1)
12 9 TABLE ACCESS (BY INDEX ROWID) OF 'USR_DI
M' (TABLE) (Cost=1 Card=1 Bytes=217)
13 12 INDEX (UNIQUE SCAN) OF 'USR_DIM_PK' (I
NDEX (UNIQUE)) (Cost=0 Card=1)
14 8 TABLE ACCESS (BY INDEX ROWID) OF 'HDS_FCT'
(TABLE) (Cost=9 Card=1 Bytes=143)
15 14 INDEX (RANGE SCAN) OF 'HDS_FCT_IX2' (IND
EX) (Cost=1 Card=338)
16 7 TABLE ACCESS (BY INDEX ROWID) OF 'USR_MEDIA_
COMM' (TABLE) (Cost=1 Card=1 Bytes=129)
17 16 INDEX (UNIQUE SCAN) OF 'USR_MEDIA_COMM_PK'
(INDEX (UNIQUE)) (Cost=0 Card=1)
18 6 TABLE ACCESS (BY INDEX ROWID) OF 'USR_MEDIA_CO
MM' (TABLE) (Cost=1 Card=1 Bytes=129)
19 18 INDEX (UNIQUE SCAN) OF 'USR_MEDIA_COMM_PK' (
INDEX (UNIQUE)) (Cost=0 Card=1)
20 5 TABLE ACCESS (BY INDEX ROWID) OF 'PROD_DIM' (TAB
LE) (Cost=1 Card=1 Bytes=112)
21 20 INDEX (UNIQUE SCAN) OF 'PROD_DIM_PK' (INDEX (U
NIQUE)) (Cost=0 Card=1)
22 4 INDEX (UNIQUE SCAN) OF 'CUST_DIM_PK' (INDEX (UNIQU
E)) (Cost=0 Card=1)
23 3 TABLE ACCESS (BY INDEX ROWID) OF 'CUST_DIM' (TABLE)
(Cost=1 Card=1 Bytes=179)
24 2 BUFFER (SORT) (Cost=19 Card=22 Bytes=594)
25 24 INDEX (FAST FULL SCAN) OF 'PROD_DIM_AK1' (INDEX (UNI
QUE)) (Cost=2 Card=22 Bytes=594) -
Query Without Index Hint
Cost is 11 and the execution time of the Query is 5 secs
Query With Index Hint
Cost is 3453 and the execution time for the query is 560 msecs.
Can anyone tell me which one I should be using the one with minimal cost or with minimal execution time?
Thanks> Without Hint
The query uses Index I2 Excecution time 5 secs
With Hint
560msecs
And that explains the so-called CBO cost anomaly between the two.
When you add a hint to a query, you're forcing the CBO to change the "expense" of I/O paths and rate, for example, the forced (hinted) index as a cheaper path than the default index - as the CBO needs to "push" that hinted index up the chain as a cheaper path.
Costs are internally adjusted due to that hint in order to satisfy that hint (or at least try to). The resulting cost determined by the CBO is for all intends and purposes a random number when used as a comparison with the costs of same query without a hint or with a different hint. -
Dear SCN,
I am new to BOBJ Environment. I have created a webi report on top of bex query by using BISC connection. Bex query is build for Vendor Ageing Analysis. My bex query will take very less time to execute the report (max 1 min). But in case of webi is takeing around 5 min when i click on refresh. I have not used any conditions,filters,restrictions are done at webi level all are done at bex level only.
Please let me know techniques to optimize the query execution time in webi. Currently we are in BO 4.0.
Regards,
PRKHi Praveen
Go through this document for performance optimization using BICS connection
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0e3c552-e419-3010-1298-b32e6210b58d?QuickLink=index&… -
Execution time of query with high variance
I have an Oracle Database 11.2 R2 which is set up just for testing purposes, so there is no other activity except mine. Now I have a query which I ran 10 times in a row. Between the executions I always flushed BUFFER_CACHE and SHARED_POOL. The strange thing is, that the execution time of the query is strongly varying from 13 seconds up to 207 seconds. From the 10 executions I have 4 times <25 seconds and 4 times > 120 seconds.
What could be the reason for this? As I've said, there is no other activity on the database and it is always the same query with the same parameters running on the same set of data.
The background to this is that I would like to compare the execution time of exactly the same query with different database settings. So I thought I could just run the query ten times and use the average but I didn't expect such a high variance.
Kind regards
PeterHi,
for each execution, look at:
1) plan hash value
2) total logical I/O
3) physical I/O
That should give you some clues as to what's going on.
Best regards,
Nikolay -
Hi,
I am trying to find the execution time of a SQL query.
How to do it?
Regards.
Ashish>I am trying to find the execution time of a SQL query.
How to do it?
Psuedo code:
time = SystemTime() -- get the current system time
RunSQL() -- run the SQL statement
print( SystemTime()-time ) -- displays the difference in time
Needless to say that this is utterly useless most of the time. The first time a query is run it may be subjected to a hard parse. The second time not. So the exact same SQL will show different execution times. This execution time measurement is useless as it does not tell you anything - except that there was a difference in time.
The first time a query runs it make do a lot of physical I/O to read the data from disk. The second time around, with the data in the db buffer cache, it makes use of logical I/O. There is a significant difference in the execution of the exact same SQL. Again, the measurement of execution is meaningless. It does not tell you anything. One number versus another number. Nothing meaningful to compare.
Fact. The very same SQL will have different execution times.
So what do you hope to gain from measuring it?
Maybe you are looking for
-
SSRS filter a dataset if parameter is "Yes"
hello i have a report as below with date Parameters this all works fine! date from date too 01/01/2011 21/02/2013 name amount date test1 100 01/01/2012 test2 200 01/02/2013 but what i wa
-
Multiple MACTHES with OR gives error
Hi, i'm new to oracle database. I have problem with matches when i use OR but with AND it works fine. SELECT DISTINCT members.email , authors.IDq FROM authors, titles, members, queries WHERE (queries.type = 'AND' AND queries.IDq = authors.IDq AND que
-
Unable to determine the install root path for the LabVIEW Runtime Engine
Hi, i have an issue with using a LabVIEW interop assembly in a .NET application. I get an exception "Unable to determine the install root path for the LabVIEW Runtime Engine" when calling the assembly. The little test program is attached below. It's
-
Print jobs slow to leave Mac print queue
Mac laptops running 10.5.6. IP printers added, using LPD with queue of lp. There is a Xerox WCP232, HP Laserjet Series 4/5 and another print queue on the systems. Several presets created as laptops are shared, each preset is configured for a secure p
-
Facebook won't let me select iPhoto pic's to upload
Facebook won't let me select iPhoto pic's to upload (see below), the option to select iPhoto is grayed out. Is there a way of doing this? Thanks for your help