Cost in explain plan vs elapsed time
hi gurus,
i have two tables with identical data volume(same database/schema/tablespace) and the only difference between these two is, one partitioned on a date filed.
statistics are up to date.
same query is executed against both tables, no partition pruning involved.
select ....... from non-partitioned
execution plan cost=92
elapsed time=117612
select ... from partitioned
execution plan cost=3606
elapsed time=19559
though plan cost of query against non-partitioned is quite less than partitioned, elapsed time in v$sqlarea is higher than partitioned.
what could be the reason please?
thanks,
charles
Edited by: user570138 on May 6, 2010 6:54 AM
user570138 wrote:
if elapsed time value is very volatile(with the difference in explain plan cost) , then how can i compare the performance of the query?Note that the same query with same execution plan and same data can provide different execution times - and due to a number of factors. The primary one being that the first time the query is executed, it performs physical I/O and loads the data into the buffer cache - where the same subsequent query finds this data via cheaper and faster logical I/O in the cache.
in my case i want to compare the performance change before and after table partitioning.Then look at the actual utilisation cost of the query and not (variant) elapsed execution time. The most expensive operation on a db platform is typically I/O. The more I/O, the slower the execution time.
I/O can be decreased in a number of ways. The usual approach in the database environment is to provide better or alternative data structures, in order to create more optimal I/O paths.
So instead of using a hash table and separate PK b+tree index, using an index organised table. Instead of a single large table with indexes, a partitioned table with local indexes. Instead of joining plain tables, joining tables that have been clustered. Etc.
In most cases, when done correctly, these physical data structure changes do not even impact the application layer. The SQL and code in this layer should be blissfully unaware of the physical structure changes done to improve performance.
Likewise, changes in the logical layer (data model changes) can also improve performance. This of course does impact the application layer - and requires a proper design and implementation in the physical layer. Often proper data modeling is overlooked and flaws in it is attempted to be fixed by hacking the physical layer.
my aim is to measure the query performance improvements, if any, by partitioning an existing tableWhy not measure current I/O before an operation, and then after the operation - and use the difference to determine the amount of I/O performed by that operation?
This can be implemented in a start/stop watch fashion (instead of measuring time, measuring I/O) using the v$sesstat virtual performance view.
Similar Messages
-
Tuning : Inconsistent result between Explain plan VS Execution Time
Dear Experts,
Need your suggestions belongs to contrary result between Explain plan VS Execution Time
Environment :_
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
Red Hat Enterprise Linux 5.4
There's same query but : 1st query access Loan_Account, 2nd query access Loan_Account_Han
*1st.*
Query Access Via : Loan_account (Partition Type : Hash (5) with column Contract_Number)
Explain Plan : cost: 4,432, bytes: 716, cardinality: 2
Execution Time : 13 seconds
*2nd.*
Query Access Via : Loan_Account_Han (Partition Type : List(5) with column Loan_Status)
Explain Plan : cost:188,447 bytes: 1,661,088, cardinality: 4,719
Execution Time : 10 seconds
Note :_
all tables and all indexes belong to the table which included in query has been analyzed.
my question :
1. why it could become like this ? I even confusing with Jonathan Lewis Theory : Cost-Based Fundamental Book.
with this result, I even not believed with the result from Explain Plan anymore.
2. If analyze tables and indexes to update statistics which help CBO to choose the best path as part of Daily Performance Tuning,
is there a way that could do in enviroment 24x7 ?
Note : if original query is needed, I'll posting it here.
Any help is very appreciated and thanks very much.
Regards,
SigcleThe DBMS_XPLAN.DISPLAY_CURSOR output
Query no 1
PLAN_TABLE_OUTPUT
SQL_ID bq7avs72xvmkv, child number 0
SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id, la.contract_number, mc.customer_name,
dco.os_principal_on_schedule AS os_principal_on_schedule, f_get_param_value (la.financing_type, 'FinancingType'
) AS financing_type, CASE la.financing_type WHEN 11 -- Asset Purchase THEN NVL (tp.os_principal_cust,
la.os_principal_cust ) WHEN 12 -- JF Channelling THEN
NVL (tp.os_principal_mf, la.os_principal) END AS os_principal_actual, CASE WHEN dco.bi_collectibility_with_gp >= 3 THEN 0
ELSE CASE WHEN la.financing_type = '12' THEN NVL (ia.accrue_interest_pl, 0) + NVL (ia.accrue_interest_npl, 0)
ELSE NVL (ia.accrue_
Plan hash value: 4011856754
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem |
| 1 | TABLE ACCESS BY INDEX ROWID | COLLECTIBILITY_CODE | 3 | 1 | 3 |00:00:00.01 | 9 | 2 | | | |
|* 2 | INDEX SKIP SCAN | UNQ_COLLECTIBILITY_CODE | 3 | 1 | 3 |00:00:00.01 | 6 | 1 | | | |
| 3 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 501 | 1 | 501 |00:00:00.03 | 2004 | 796 | | | |
|* 4 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 501 | 1 | 501 |00:00:00.02 | 1503 | 377 | | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 333 | 1 | 333 |00:00:00.10 | 3220 | 1074 | | | |
|* 6 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 333 | 1 | 333 |00:00:00.09 | 2887 | 1074 | | | |
| 7 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 168 | 1 | 167 |00:00:00.05 | 1464 | 495 | | | |
|* 8 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 168 | 1 | 167 |00:00:00.05 | 1297 | 495 | | | |
| 9 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 333 | 1 | 333 |00:00:00.06 | 3167 | 0 | | | |
|* 10 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 333 | 1 | 333 |00:00:00.06 | 2834 | 0 | | | |
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 168 | 1 | 167 |00:00:00.03 | 1447 | 0 | | | |
|* 12 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 168 | 1 | 167 |00:00:00.03 | 1280 | 0 | | | |
| 13 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 333 | 1 | 333 |00:00:00.06 | 3167 | 0 | | | |
|* 14 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 333 | 1 | 333 |00:00:00.06 | 2834 | 0 | | | |
| 15 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 168 | 1 | 167 |00:00:00.03 | 1447 | 0 | | | |
|* 16 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 168 | 1 | 167 |00:00:00.03 | 1280 | 0 | | | |
| 17 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 333 | 1 | 333 |00:00:00.06 | 3167 | 0 | | | |
|* 18 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 333 | 1 | 333 |00:00:00.06 | 2834 | 0 | | | |
| 19 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 168 | 1 | 167 |00:00:00.03 | 1447 | 0 | | | |
|* 20 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 168 | 1 | 167 |00:00:00.03 | 1280 | 0 | | | |
|* 21 | TABLE ACCESS FULL | COLLECTIBILITY_CODE | 3 | 1 | 3 |00:00:00.01 | 12 | 1 | | | |
| 22 | NESTED LOOPS OUTER | | 1 | 2 | 501 |00:00:01.02 | 96112 | 20091 | | | |
| 23 | NESTED LOOPS | | 1 | 2 | 501 |00:00:00.28 | 13445 | 5358 | | | |
| 24 | NESTED LOOPS | | 1 | 2 | 501 |00:00:00.26 | 11441 | 5071 | | | |
| 25 | NESTED LOOPS OUTER | | 1 | 2 | 501 |00:00:00.24 | 9433 | 5014 | | | |
|* 26 | HASH JOIN | | 1 | 2 | 501 |00:00:00.03 | 329 | 325 | 1206K| 1206K| 341K (0)|
|* 27 | TABLE ACCESS FULL | CURRENCY | 1 | 1 | 1 |00:00:00.01 | 3 | 2 | | | |
|* 28 | HASH JOIN | | 1 | 61 | 501 |00:00:00.02 | 326 | 323 | 868K| 868K| 947K (0)|
|* 29 | HASH JOIN | | 1 | 10 | 13 |00:00:00.01 | 7 | 6 | 947K| 947K| 1030K (0)|
| 30 | TABLE ACCESS BY INDEX ROWID | MULTIFINANCE | 1 | 5 | 9 |00:00:00.01 | 2 | 2 | | | |
|* 31 | INDEX RANGE SCAN | IDX_STATUS_MF | 1 | 5 | 9 |00:00:00.01 | 1 | 1 | | | |
|* 32 | TABLE ACCESS FULL | AGREEMENT | 1 | 18 | 13 |00:00:00.01 | 5 | 4 | | | |
| 33 | VIEW | | 1 | 110 | 501 |00:00:00.02 | 319 | 317 | | | |
|* 34 | HASH JOIN RIGHT OUTER | | 1 | 110 | 501 |00:00:00.02 | 319 | 317 | 1011K| 1011K| 317K (0)|
| 35 | TABLE ACCESS BY INDEX ROWID | TENANT_PARAMETER | 1 | 1 | 1 |00:00:00.01 | 2 | 2 | | | |
|* 36 | INDEX UNIQUE SCAN | PK_TENANT_PARAMETER | 1 | 1 | 1 |00:00:00.01 | 1 | 1 | | | |
|* 37 | TABLE ACCESS BY GLOBAL INDEX ROWID| LOAN_ACCOUNT | 1 | 110 | 501 |00:00:00.02 | 317 | 315 | | | |
|* 38 | INDEX RANGE SCAN | IDX_STATUS_LA1 | 1 | 4394 | 3025 |00:00:00.01 | 15 | 14 | | | |
|* 39 | TABLE ACCESS BY INDEX ROWID | TX_PAYMENT | 501 | 1 | 0 |00:00:00.16 | 9104 | 4689 | | | |
|* 40 | INDEX RANGE SCAN | FK_TX_PAY_LOAN_ACCT | 501 | 12 | 8799 |00:00:00.02 | 1038 | 207 | | | |
| 41 | TABLE ACCESS BY INDEX ROWID | DL_CL_OUTSTANDING | 501 | 1 | 501 |00:00:00.02 | 2008 | 57 | | | |
|* 42 | INDEX RANGE SCAN | IDXLO_CNUM | 501 | 1 | 501 |00:00:00.01 | 1507 | 37 | | | |
|* 43 | TABLE ACCESS BY INDEX ROWID | MF_CUSTOMER | 501 | 1 | 501 |00:00:00.02 | 2004 | 287 | | | |
|* 44 | INDEX UNIQUE SCAN | MF_CUSTOMER_PK | 501 | 1 | 501 |00:00:00.01 | 1503 | 24 | | | |
|* 45 | TABLE ACCESS BY INDEX ROWID | TX_INTEREST_ACCRUE | 501 | 1 | 0 |00:00:00.73 | 82667 | 14733 | | | |
|* 46 | INDEX RANGE SCAN | FK_TX_INTEREST_ACCRUE_LOAN_ACC | 501 | 67 | 40581 |00:00:00.14 | 42084 | 451 | | | |
Predicate Information (identified by operation id):
2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
filter("XX"."COLLECTIBILITY_CODE"=:B1)
4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
hh24:mi:ss'),:B3))
21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
26 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
27 - filter(UPPER("CURR"."STATUS")='A')
28 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
29 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
31 - access("MF"."SYS_NC00052$"='A')
32 - filter(UPPER("A"."STATUS")='A')
34 - access("LA"."TENANT_ID"="TENANT_ID")
36 - access("TENANT_PARAMETER_ID"=23)
37 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR ("LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
UPPER("LA"."LOAN_STATUS")='CN')))
38 - access("LA"."SYS_NC00118$"='A')
39 - filter(("TP"."APPROVAL_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"=152 AND UPPER("TP"."APPROVAL_STATUS")='A'))
40 - access("TP"."LOAN_ACCOUNT_ID"="from$_subquery$_016"."LOAN_ACCOUNT_ID")
42 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
43 - filter(UPPER("MC"."STATUS")='A')
44 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")
45 - filter("IA"."ACCRUE_DATE"="XX"."PREV_DATE")
46 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID")
The DBMS_XPLAN.DISPLAY_CURSOR output after : alter system flush buffer_cache; alter system flush shared_pool;
Query no 2
PLAN_TABLE_OUTPUT
SQL_ID cxmg4jfvr9pz0, child number 0
SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id, la.contract_number, mc.customer_name,
dco.os_principal_on_schedule AS os_principal_on_schedule, f_get_param_value (la.financing_type, 'FinancingType'
) AS financing_type, CASE la.financing_type WHEN 11 -- Asset Purchase THEN NVL (tp.os_principal_cust,
la.os_principal_cust ) WHEN 12 -- JF Channelling THEN
NVL (tp.os_principal_mf, la.os_principal) END AS os_principal_actual, CASE WHEN dco.bi_collectibility_with_gp >= 3 THEN 0
ELSE CASE WHEN la.financing_type = '12' THEN NVL (ia.accrue_interest_pl, 0) + NVL (ia.accrue_interest_npl, 0)
ELSE NVL (ia.accrue_
Plan hash value: 2072372033
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 4719 | 1622K| 188K (32)| 00:37:42 | | |
| 1 | TABLE ACCESS BY INDEX ROWID | COLLECTIBILITY_CODE | 1 | 12 | 3 (0)| 00:00:01 | | |
|* 2 | INDEX SKIP SCAN | UNQ_COLLECTIBILITY_CODE | 1 | | 2 (0)| 00:00:01 | | |
| 3 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 4 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 15 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 6 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 7 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 1 | 15 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 8 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 9 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 15 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 10 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 1 | 15 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 12 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 13 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 14 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 15 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 16 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 17 | TABLE ACCESS BY GLOBAL INDEX ROWID | MF_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 18 | INDEX UNIQUE SCAN | UNQ_MF_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
| 19 | TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT | 1 | 17 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 20 | INDEX UNIQUE SCAN | UNQ_CUST_SCH_INSTALLMENT1 | 1 | | 2 (0)| 00:00:01 | | |
|* 21 | TABLE ACCESS FULL | COLLECTIBILITY_CODE | 1 | 12 | 3 (0)| 00:00:01 | | |
| 22 | NESTED LOOPS | | 4719 | 1622K| 188K (32)| 00:37:42 | | |
| 23 | NESTED LOOPS | | 4719 | 1460K| 183K (33)| 00:36:45 | | |
| 24 | NESTED LOOPS OUTER | | 4719 | 1354K| 180K (33)| 00:36:07 | | |
| 25 | NESTED LOOPS OUTER | | 4719 | 1225K| 130K (46)| 00:26:01 | | |
|* 26 | HASH JOIN | | 4719 | 1106K| 23591 (2)| 00:04:44 | | |
| 27 | TABLE ACCESS BY INDEX ROWID | MULTIFINANCE | 5 | 130 | 2 (0)| 00:00:01 | | |
|* 28 | INDEX RANGE SCAN | IDX_STATUS_MF | 5 | | 1 (0)| 00:00:01 | | |
|* 29 | HASH JOIN | | 8494 | 1775K| 23589 (2)| 00:04:44 | | |
|* 30 | TABLE ACCESS FULL | AGREEMENT | 18 | 360 | 3 (0)| 00:00:01 | | |
|* 31 | HASH JOIN | | 8494 | 1609K| 23585 (2)| 00:04:44 | | |
|* 32 | TABLE ACCESS FULL | CURRENCY | 1 | 4 | 3 (0)| 00:00:01 | | |
| 33 | VIEW | | 212K| 38M| 23579 (2)| 00:04:43 | | |
|* 34 | HASH JOIN RIGHT OUTER | | 212K| 32M| 23579 (2)| 00:04:43 | | |
| 35 | TABLE ACCESS BY INDEX ROWID| TENANT_PARAMETER | 1 | 74 | 1 (0)| 00:00:01 | | |
|* 36 | INDEX UNIQUE SCAN | PK_TENANT_PARAMETER | 1 | | 0 (0)| 00:00:01 | | |
| 37 | PARTITION LIST ALL | | 212K| 17M| 23575 (2)| 00:04:43 | 1 | 5 |
|* 38 | TABLE ACCESS FULL | LOAN_ACCOUNT_HAN | 212K| 17M| 23575 (2)| 00:04:43 | 1 | 5 |
| 39 | TABLE ACCESS BY INDEX ROWID | TX_INTEREST_ACCRUE | 1 | 26 | 130K (46)| 00:26:01 | | |
| 40 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
| 41 | BITMAP AND | | | | | | | |
| 42 | BITMAP CONVERSION FROM ROWIDS| | | | | | | |
|* 43 | INDEX RANGE SCAN | FK_TX_INTEREST_ACCRUE_LOAN_ACC | 67 | | 0 (0)| 00:00:01 | | |
| 44 | BITMAP CONVERSION FROM ROWIDS| | | | | | | |
|* 45 | INDEX RANGE SCAN | IDX_TX_INTEREST_ACCRUE | 67 | | 12 (100)| 00:00:01 | | |
|* 46 | TABLE ACCESS BY INDEX ROWID | TX_PAYMENT | 1 | 28 | 11 (0)| 00:00:01 | | |
|* 47 | INDEX RANGE SCAN | FK_TX_PAY_LOAN_ACCT | 12 | | 0 (0)| 00:00:01 | | |
| 48 | TABLE ACCESS BY INDEX ROWID | DL_CL_OUTSTANDING | 1 | 23 | 1 (0)| 00:00:01 | | |
|* 49 | INDEX RANGE SCAN | IDXLO_CNUM | 1 | | 0 (0)| 00:00:01 | | |
|* 50 | TABLE ACCESS BY INDEX ROWID | MF_CUSTOMER | 1 | 35 | 1 (0)| 00:00:01 | | |
|* 51 | INDEX UNIQUE SCAN | MF_CUSTOMER_PK | 1 | | 0 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
filter("XX"."COLLECTIBILITY_CODE"=:B1)
4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
26 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
28 - access(UPPER("STATUS")='A')
29 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
30 - filter(UPPER("A"."STATUS")='A')
31 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
32 - filter(UPPER("CURR"."STATUS")='A')
34 - access("LA"."TENANT_ID"="TENANT_ID"(+))
36 - access("TENANT_PARAMETER_ID"(+)=23)
38 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR "LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
AND UPPER("LA"."LOAN_STATUS")='CN') AND UPPER("LA"."STATUS")='A')
43 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID"(+))
45 - access("IA"."ACCRUE_DATE"(+)="XX"."PREV_DATE")
46 - filter("TP"."APPROVAL_DATE"(+)=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"(+)=152
AND UPPER("TP"."APPROVAL_STATUS"(+))='A')
47 - access("TP"."LOAN_ACCOUNT_ID"(+)="from$_subquery$_016"."LOAN_ACCOUNT_ID")
49 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
50 - filter(UPPER("MC"."STATUS")='A')
51 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")Typically both query running on 10-12 seconds (or same execution time).
And I can't provide autotrace and tkprof output cause I cannot access via sqlplus.
Thanks very much for the link HOW TO: Post a SQL statement tuning request - template posting
Regards,
Sigcle
Edited by: SigCle on Feb 25, 2013 4:22 AM -
Explain me about cost in explain plan.
Hi All,
Please explain me about cost in explain plan.
Below is my explan plans
1. first plan showing cost is more but query is returing the result very fast (564 msecs ) --- local database.
2. second plan showing less cost but result is very slow (14 secs) .
1. local database.
PLAN_TABLE_OUTPUT
| ID | Operation | NAME | ROWS | Bytes | COST |
| 0 | SELECT STATEMENT | | 17 | 2312 | 60 |
| 1 | SORT UNIQUE | | 17 | 2312 | 59 |
| 2 | COUNT STOPKEY | | | | |
| 3 | NESTED LOOPS | | 17 | 2312 | 58 |
| 4 | MAT_VIEW ACCESS BY INDEX ROWID| MV_EDECO_ESONGS | 17 | 1326 | 24 |
| 5 | INDEX RANGE SCAN | IDX_ESNG_REG_TITLE | 21 | | 3 |
| 6 | TABLE ACCESS BY INDEX ROWID | MV_EDECO_ESONGS_TERR_CTRY | 1 | 58 | 2 |
| 7 | INDEX UNIQUE SCAN | IDX_ESNG_TERR_ESNG_ID_1 | 1 | | 1 |
PLAN_TABLE_OUTPUT
| ID | Operation | NAME | ROWS | Bytes | COST |
| 0 | SELECT STATEMENT | | 9 | 1260 | 34 |
| 1 | SORT UNIQUE | | 9 | 1260 | 33 |
| 2 | COUNT STOPKEY | | | | |
| 3 | NESTED LOOPS | | 9 | 1260 | 32 |
| 4 | MAT_VIEW ACCESS BY INDEX ROWID| MV_EDECO_ESONGS | 9 | 720 | 14 |
| 5 | INDEX RANGE SCAN | IDX_ESNG_REG_TITLE | 11 | | 3 |
| 6 | MAT_VIEW ACCESS BY INDEX ROWID| MV_EDECO_ESONGS_TERR_CTRY | 1 | 60 | 2 |
| 7 | INDEX UNIQUE SCAN | PK_EDESONGSTERCTRY_ESONGID | 1 | | 1 |
------------------------------------------------------------------------------------------------Regards,
Rajasekharrajasekhar_n wrote:
Hoek, I have cross checked the results both the querys are precessing same records and returing same result *(both are using DB links).*But you said the first query was on a local database?
If you're using dblinks then it's not local is it! ?:| -
Same sqlID with different execution plan and Elapsed Time (s), Executions time
Hello All,
The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
17th Oct 18th Oct
221,808,602
21
2tc2d3u52rppt
213,170,100
72,495,618
9c8wqzz7kyf37
209,239,059
71,477,888
9c8wqzz7kyf37
139,331,777
1
7b0kzmf0pfpzn
144,813,295
1
0cqc3bxxd1yqy
102,045,818
1
8vp1ap3af0ma5
128,892,787
16,673,829
84cqfur5na6fg
89,485,065
1
5kk8nd3uzkw13
127,467,250
16,642,939
1uz87xssm312g
67,520,695
8,058,820
a9n705a9gfb71
104,490,582
12,443,376
a9n705a9gfb71
62,627,205
1
ctwjy8cs6vng2
101,677,382
15,147,771
3p8q3q0scmr2k
57,965,892
268,353
akp7vwtyfmuas
98,000,414
1
0ybdwg85v9v6m
57,519,802
53
1kn9bv63xvjtc
87,293,909
1
5kk8nd3uzkw13
52,690,398
0
9btkg0axsk114
77,786,274
74
1kn9bv63xvjtc
34,767,882
1,003
bdgma0tn8ajz9
Not only queries are different but also the number of blocks read by top 10 queries are much higher on 17th than 18th.
The other big difference is the average read time on two days
Tablespace IO Stats
17th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
947,766
59
4.24
4.86
185,084
11
2,887
6.42
UNDOTBS2
517,609
32
4.27
1.00
112,070
7
108
11.85
INDUS_MST_DATA01
288,994
18
8.63
8.38
52,541
3
23,490
7.45
INDUS_TRN_INDX01
223,581
14
11.50
2.03
59,882
4
533
4.26
TEMP
198,936
12
2.77
17.88
11,179
1
732
2.13
INDUS_LOG_DATA01
45,838
3
4.81
14.36
348
0
1
0.00
INDUS_TMP_DATA01
44,020
3
4.41
16.55
244
0
1,587
4.79
SYSAUX
19,373
1
19.81
1.05
14,489
1
0
0.00
INDUS_LOG_INDX01
17,559
1
4.75
1.96
2,837
0
2
0.00
SYSTEM
7,881
0
12.15
1.04
1,361
0
109
7.71
INDUS_TMP_INDX01
1,873
0
11.48
13.62
231
0
0
0.00
INDUS_MST_INDX01
256
0
13.09
1.04
194
0
2
10.00
UNDOTBS1
70
0
1.86
1.00
60
0
0
0.00
STG_DATA01
63
0
1.27
1.00
60
0
0
0.00
USERS
63
0
0.32
1.00
60
0
0
0.00
INDUS_LOB_DATA01
62
0
0.32
1.00
60
0
0
0.00
TS_AUDIT
62
0
0.48
1.00
60
0
0
0.00
18th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
980,283
91
1.40
4.74The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
You wrote with different execution plan, I think, you saw plans. It is very difficult, you get old plan.
I think Execution plans is not changed in different days, if you not added index or ...
What say ADDM report about this script?
As you know, It is normally, different Elapsed Time for same statement in different day.
It is depend your database workload.
It think you must use SQL Access and SQl Tuning advisor for this script.
You can get solution for slow running problem.
Regards
Mahir M. Quluzade -
Hi all,
Is the "COST" column in explain plan CPU or MEMORY usage cost? or both
ThanksI am not sure this is also documented with same detail level.
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/optimops.htm#sthref860 says:
>
The cost is an estimated value proportional to the expected resource use needed to execute the statement with a particular plan. The optimizer calculates the cost of access paths and join orders based on the estimated computer resources, which includes I/O, CPU, and memory.
>
and http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/ex_plan.htm#sthref1110 says
>
Cost of the operation as estimated by the optimizer's query approach. Cost is not determined for table access operations. The value of this column does not have any particular unit of measurement; it is merely a weighted value used to compare costs of execution plans. The value of this column is a function of the CPU_COST and IO_COST columns.
>
Edited by: P. Forstmann on 6 avr. 2011 08:38 -
Differenet Explain Plan for Same Query
DB Version : 11.2.0.3
OS Version : AIX 6
I have two Queries ( The Difference between Them Only 940 and 584 ) When I Generate Explain Plan Different Output Why ? Why CPU time is Different Each Time
First Query Statement :
INSERT INTO TempSearchResult (t_aid,
t_umidl,
t_umidh,
X_CREA_DATE_TIME_MESG)
SELECT z.aid,
z.mesg_s_umidl,
z.mesg_s_umidh,
z.mesg_crea_date_time
FROM ( SELECT m.aid,
m.mesg_s_umidl,
m.mesg_s_umidh,
m.mesg_crea_date_time
FROM RSMESG_ESIDE m
WHERE 1 = 1
AND m.mesg_crea_date_time BETWEEN TO_DATE (
'20120131 10:00:00',
'YYYYMMDD HH24:MI:SS')
AND TO_DATE (
'20120131 13:00:00',
'YYYYMMDD HH24:MI:SS')
AND m.mesg_frmt_name = 'Swift'
AND m.mesg_sender_x1 = 'SOGEFRPPXXX'
AND m.mesg_nature = 'FINANCIAL_MSG'
AND m.mesg_type LIKE '950'
ORDER BY mesg_crea_date_time) z
WHERE ROWNUM <= 5000
Explain Plan for First Query :
PLAN_TABLE_OUTPUT
Plan hash value: 3901722890
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | INSERT STATEMENT | | 2866 | 134K| 197 (3)| 00:00:03 | | |
| 1 | LOAD TABLE CONVENTIONAL | TEMPSEARCHRESULT | | | | | | |
|* 2 | COUNT STOPKEY | | | | | | | |
| 3 | VIEW | | 2866 | 134K| 197 (3)| 00:00:03 | | |
|* 4 | SORT ORDER BY STOPKEY | | 2866 | 333K| 197 (3)| 00:00:03 | | |
| 5 | NESTED LOOPS | | 2866 | 333K| 196 (2)| 00:00:03 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 1419 | 148K| 196 (2)| 00:00:03 | | |
|* 7 | HASH JOIN | | 1419 | 141K| 196 (2)| 00:00:03 | | |
| 8 | NESTED LOOPS | | 91 | 1911 | 2 (0)| 00:00:01 | | |
| 9 | TABLE ACCESS BY INDEX ROWID | SUSER | 1 | 10 | 1 (0)| 00:00:01 | | |
|* 10 | INDEX UNIQUE SCAN | IX_SUSER | 1 | | 0 (0)| 00:00:01 | | |
|* 11 | INDEX FULL SCAN | PK_SUNITUSERGROUP | 91 | 1001 | 1 (0)| 00:00:01 | | |
| 12 | PARTITION RANGE SINGLE | | 1450 | 114K| 193 (2)| 00:00:03 | 2 | 2 |
|* 13 | TABLE ACCESS BY LOCAL INDEX ROWID| RMESG | 1450 | 114K| 193 (2)| 00:00:03 | 2 | 2 |
|* 14 | INDEX SKIP SCAN | IX_RMESG | 415 | | 14 (15)| 00:00:01 | 2 | 2 |
|* 15 | INDEX UNIQUE SCAN | PK_SMSGUSERGROUP | 1 | 5 | 0 (0)| 00:00:01 | | |
|* 16 | INDEX UNIQUE SCAN | PK_SBICUSERGROUP | 2 | 24 | 0 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter(ROWNUM<=5000)
4 - filter(ROWNUM<=5000)
7 - access("X_INST0_UNIT_NAME"="UNIT")
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
11 - access("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
filter("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
13 - filter("RMESG"."MESG_SENDER_X1"='SOGEFRPPXXX' AND "RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND
"RMESG"."MESG_FRMT_NAME"='Swift')
14 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-31 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"RMESG"."MESG_TYPE"='950' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-31 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("RMESG"."MESG_TYPE"='950')
15 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
16 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
40 rows selected.
Second query
INSERT INTO TempSearchResult (t_aid,
t_umidl,
t_umidh,
X_CREA_DATE_TIME_MESG)
SELECT z.aid,
z.mesg_s_umidl,
z.mesg_s_umidh,
z.mesg_crea_date_time
FROM ( SELECT m.aid,
m.mesg_s_umidl,
m.mesg_s_umidh,
m.mesg_crea_date_time
FROM RSMESG_ESIDE m
WHERE 1 = 1
AND m.mesg_crea_date_time BETWEEN TO_DATE (
'20120117 10:00:00',
'YYYYMMDD HH24:MI:SS')
AND TO_DATE (
'20120117 13:00:00',
'YYYYMMDD HH24:MI:SS')
AND m.mesg_frmt_name = 'Swift'
AND m.mesg_sender_x1 = 'SOGEFRPPGSS'
AND m.mesg_nature = 'FINANCIAL_MSG'
AND m.mesg_type LIKE '548'
ORDER BY mesg_crea_date_time) z
WHERE ROWNUM <= 5000
Explain Plan For Second Query :
PLAN_TABLE_OUTPUT
Plan hash value: 4106071428
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | INSERT STATEMENT | | 1073 | 51504 | | 2622 (1)| 00:00:32 | | |
| 1 | LOAD TABLE CONVENTIONAL | TEMPSEARCHRESULT | | | | | | | |
|* 2 | COUNT STOPKEY | | | | | | | | |
| 3 | VIEW | | 1073 | 51504 | | 2622 (1)| 00:00:32 | | |
|* 4 | SORT ORDER BY STOPKEY | | 1073 | 124K| | 2622 (1)| 00:00:32 | | |
| 5 | NESTED LOOPS | | 1073 | 124K| | 2621 (1)| 00:00:32 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 531 | 56817 | | 2621 (1)| 00:00:32 | | |
| 7 | NESTED LOOPS | | 531 | 54162 | | 2621 (1)| 00:00:32 | | |
| 8 | NESTED LOOPS | | 543 | 49413 | | 2621 (1)| 00:00:32 | | |
| 9 | TABLE ACCESS BY INDEX ROWID | SUSER | 1 | 10 | | 1 (0)| 00:00:01 | | |
|* 10 | INDEX UNIQUE SCAN | IX_SUSER | 1 | | | 0 (0)| 00:00:01 | | |
| 11 | PARTITION RANGE SINGLE | | 543 | 43983 | | 2621 (1)| 00:00:32 | 2 | 2 |
|* 12 | TABLE ACCESS BY LOCAL INDEX ROWID| RMESG | 543 | 43983 | | 2621 (1)| 00:00:32 | 2 | 2 |
| 13 | BITMAP CONVERSION TO ROWIDS | | | | | | | | |
| 14 | BITMAP AND | | | | | | | | |
| 15 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | |
|* 16 | INDEX RANGE SCAN | IX_SENDER | 25070 | | | 894 (1)| 00:00:11 | 2 | 2 |
PLAN_TABLE_OUTPUT
| 17 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | |
| 18 | SORT ORDER BY | | | | 408K| | | | |
|* 19 | INDEX RANGE SCAN | IX_RMESG | 25070 | | | 1405 (1)| 00:00:17 | 2 | 2 |
|* 20 | INDEX UNIQUE SCAN | PK_SUNITUSERGROUP | 1 | 11 | | 0 (0)| 00:00:01 | | |
|* 21 | INDEX UNIQUE SCAN | PK_SMSGUSERGROUP | 1 | 5 | | 0 (0)| 00:00:01 | | |
|* 22 | INDEX UNIQUE SCAN | PK_SBICUSERGROUP | 2 | 24 | | 0 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - filter(ROWNUM<=5000)
4 - filter(ROWNUM<=5000)
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
12 - filter("RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND "RMESG"."MESG_FRMT_NAME"='Swift')
16 - access("RMESG"."MESG_SENDER_X1"='SOGEFRPPGSS')
19 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss'))
20 - access("X_INST0_UNIT_NAME"="UNIT" AND "SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
21 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
22 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
45 rows selected.
Table Structure TEMPSEARCHRESULT
CREATE GLOBAL TEMPORARY TABLE TEMPSEARCHRESULT
T_AID NUMBER(3),
T_UMIDL NUMBER(10),
T_UMIDH NUMBER(10),
X_CREA_DATE_TIME_MESG DATE
ON COMMIT PRESERVE ROWS
NOCACHE;
CREATE INDEX SIDE.TEMP_SEARCH_INDEX ON SIDE.TEMPSEARCHRESULT
(T_AID, T_UMIDL, T_UMIDH, X_CREA_DATE_TIME_MESG);Again Thank you For your amazing Answer.
For indexes it's a balance. Check this query which is Simple
Select * from RMESGI generated Explain Plan for it to see effect of indexes .
PLAN_TABLE_OUTPUT
Plan hash value: 1686435785
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 11M| 8920M| 376K (1)| 01:15:20 | | |
| 1 | PARTITION RANGE ALL| | 11M| 8920M| 376K (1)| 01:15:20 | 1 | 12 |
| 2 | TABLE ACCESS FULL | RMESG | 11M| 8920M| 376K (1)| 01:15:20 | 1 | 12 |
---------------------------------------------------------------------------------------------1:15:20 For table access and Full Scan Also , I generate new Indexes on the table like the following
CREATE TABLE RMESG(
aid NUMBER(3) NOT NULL,
mesg_s_umidl NUMBER(10) NOT NULL,
mesg_s_umidh NUMBER(10) NOT NULL,
mesg_validation_requested CHAR(18) NOT NULL,
mesg_validation_passed CHAR(18) NOT NULL,
mesg_class CHAR(16) NOT NULL,
mesg_is_text_readonly NUMBER(1) NOT NULL,
mesg_is_delete_inhibited NUMBER(1) NOT NULL,
mesg_is_text_modified NUMBER(1) NOT NULL,
mesg_is_partial NUMBER(1) NOT NULL,
mesg_crea_mpfn_name CHAR(24) NOT NULL,
mesg_crea_rp_name CHAR(24) NOT NULL,
mesg_crea_oper_nickname CHAR(151) NOT NULL,
mesg_crea_date_time DATE NOT NULL,
mesg_mod_oper_nickname CHAR(151) NOT NULL,
mesg_mod_date_time DATE NOT NULL,
mesg_frmt_name VARCHAR2(17) NOT NULL,
mesg_nature CHAR(14) NOT NULL,
mesg_sender_x1 CHAR(11) NOT NULL,
mesg_sender_corr_type VARCHAR2(24) NOT NULL,
mesg_uumid VARCHAR2(50) NOT NULL,
mesg_uumid_suffix NUMBER(10) NOT NULL,
x_own_lt CHAR(8) NOT NULL,
x_inst0_unit_name VARCHAR2(32) default 'NONE' NOT NULL,
x_category CHAR(1) NOT NULL,
archived NUMBER(1) NOT NULL,
restored NUMBER(1) NOT NULL,
mesg_related_s_umid CHAR(16) NULL,
mesg_status CHAR(12) NULL,
mesg_crea_appl_serv_name CHAR(24) NULL,
mesg_verf_oper_nickname CHAR(151) NULL,
mesg_data_last NUMBER(10) NULL,
mesg_token NUMBER(10) NULL,
mesg_batch_reference VARCHAR2(46) NULL,
mesg_cas_sender_reference VARCHAR2(40) NULL,
mesg_cas_target_rp_name VARCHAR2(20) NULL,
mesg_ccy_amount VARCHAR2(501) NULL,
mesg_copy_service_id VARCHAR2(4) NULL,
mesg_data_keyword1 VARCHAR2(80) NULL,
mesg_data_keyword2 VARCHAR2(80) NULL,
mesg_data_keyword3 VARCHAR2(80) NULL,
mesg_delv_overdue_warn_req NUMBER(1) NULL,
mesg_fin_ccy_amount VARCHAR2(24) NULL,
mesg_fin_value_date CHAR(6) NULL,
mesg_is_live NUMBER(1) NULL,
mesg_is_retrieved NUMBER(1) NULL,
mesg_mesg_user_group VARCHAR2(24) NULL,
mesg_network_appl_ind CHAR(3) NULL,
mesg_network_delv_notif_req NUMBER(1) NULL,
mesg_network_obso_period NUMBER(10) NULL,
mesg_network_priority CHAR(12) NULL,
mesg_possible_dup_creation VARCHAR2(8) NULL,
mesg_receiver_alia_name VARCHAR2(32) NULL,
mesg_receiver_swift_address CHAR(12) NULL,
mesg_recovery_accept_info VARCHAR2(80) NULL,
mesg_rel_trn_ref VARCHAR2(80) NULL,
mesg_release_info VARCHAR2(32) NULL,
mesg_security_iapp_name VARCHAR2(80) NULL,
mesg_security_required NUMBER(1) NULL,
mesg_sender_x2 VARCHAR2(21) NULL,
mesg_sender_x3 VARCHAR2(21) NULL,
mesg_sender_x4 VARCHAR2(21) NULL,
mesg_sender_branch_info VARCHAR2(71) NULL,
mesg_sender_city_name VARCHAR2(36) NULL,
mesg_sender_ctry_code VARCHAR2(3) NULL,
mesg_sender_ctry_name VARCHAR2(71) NULL,
mesg_sender_institution_name VARCHAR2(106) NULL,
mesg_sender_location VARCHAR2(106) NULL,
mesg_sender_swift_address CHAR(12) NULL,
mesg_sub_format VARCHAR2(6) NULL,
mesg_syntax_table_ver VARCHAR2(8) NULL,
mesg_template_name VARCHAR2(32) NULL,
mesg_trn_ref VARCHAR2(16) NULL,
mesg_type CHAR(3) NULL,
mesg_user_issued_as_pde NUMBER(1) NULL,
mesg_user_priority_code CHAR(4) NULL,
mesg_user_reference_text VARCHAR2(30) NULL,
mesg_zz41_is_possible_dup NUMBER(1) NULL,
x_fin_ccy CHAR(3) NULL,
x_fin_amount NUMBER(21,4) NULL,
x_fin_value_date DATE NULL,
x_fin_ocmt_ccy CHAR(3) NULL,
x_fin_ocmt_amount NUMBER(21,4) NULL,
x_receiver_x1 CHAR(11) NULL,
x_receiver_x2 VARCHAR2(21) NULL,
x_receiver_x3 VARCHAR2(21) NULL,
x_receiver_x4 VARCHAR2(21) NULL,
last_update DATE NULL,
set_id NUMBER(10) NULL,
mesg_requestor_dn VARCHAR2(101) NULL,
mesg_service VARCHAR2(31) NULL,
mesg_request_type VARCHAR2(31) NULL,
mesg_identifier VARCHAR2(31) NULL,
mesg_xml_query_ref1 VARCHAR2(101) NULL,
mesg_xml_query_ref2 VARCHAR2(101) NULL,
mesg_xml_query_ref3 VARCHAR2(101) NULL,
mesg_appl_sender_reference VARCHAR2(51) NULL,
mesg_payload_type VARCHAR2(31) NULL,
mesg_sign_digest_reference VARCHAR2(41) NULL,
mesg_sign_digest_value VARCHAR2(51) NULL,
mesg_use_pki_signature NUMBER(1) NULL
PARTITION BY RANGE(MESG_CREA_DATE_TIME) (
PARTITION SIDE_MIN VALUES LESS THAN (TO_DATE(20000101, 'YYYYMMDD')) TABLESPACE TBS_SIDEDB_DA_01);
CREATE UNIQUE INDEX SIDE.IX_PK_RMESG on SIDE.RMESG (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) LOCAL;
ALTER TABLE SIDE.RMESG ADD CONSTRAINT IX_PK_RMESG PRIMARY KEY (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) USING INDEX SIDE.IX_PK_RMESG;
CREATE INDEX SIDE.ix_rmesg_cassender ON SIDE.rmesg (MESG_CAS_SENDER_REFERENCE) LOCAL;
CREATE INDEX SIDE.ix_rmesg_creationdate ON SIDE.rmesg (MESG_CREA_DATE_TIME) LOCAL;
CREATE INDEX SIDE.ix_rmesg_trnref ON SIDE.rmesg (MESG_TRN_REF) LOCAL;
CREATE INDEX SIDE.ix_rmesg_uumid ON SIDE.rmesg (MESG_UUMID, MESG_UUMID_SUFFIX) LOCAL;
CREATE INDEX SIDE.IX_UNIT_NAME_RMESG on RMESG(mesg_crea_date_time,X_INST0_UNIT_NAME) LOCAL;
CREATE INDEX SIDE.IX_RMESG on RMESG(mesg_crea_date_time ,mesg_type,x_fin_ccy) LOCAL;
CREATE INDEX SIDE.IX_NAME_FORMAT_TYPE_RMESG on RMESG(mesg_frmt_name,mesg_sub_format,mesg_type,mesg_crea_date_time ) LOCAL;same Explain Plan Same Result .
I always remember TOM Quote "full scans are not evil, indexes are not good"
Which Mean Something Wrong Goes with Indexes , the partition depend on MESG_CREA_DATE_TIME Column I create Index for this column but same explain plan Appear every time. With Same Time.
Thank you
Osama -
Real explain plan differs from one in v$sqlarea
I have some more or less complex queries which I catch on runtime by reading v$sqlarea table to find sql with high cost..
but..
I found some highly costed sql, but when I run it through client ti see it's explain plan and execution time, it's much faster with very little cost
why?
am I wrong when I read v$sqlarea?
I'm using Oracle 11g R2This is not at all surprising. Jonathan Lewis and many other have discussed this numerous times both in these forums, in books, in white papers, and in conference presentations.
That said ... you should be looking in gv$sql_plan. -
Explain plan - lower cost but higher response time in 11g compared to 10g
Hello,
I have a strange scenario where 'm migrating a db from standalone Sun FS running 10g RDBMS to a 2-Node Sun/ASM 11g RAC env. The issue is with response time of queries -
In 11g Env:
SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
LAST_ANALYZED NUM_ROWS
11-08-2012 18:21:12 3413956
Elapsed: 00:00:00.30
In 10g Env:
SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
LAST_ANAL NUM_ROWS
07-NOV-12 3502160
Elapsed: 00:00:00.04If you look @ the response times, even a simple query on the dba_tables takes ~8 times. Any ideas what might be causing this? I have compared the XPlans and they are exactly the same, moreover, the cost is less in the 11g env compared to the 10g env, but still the response time is higher.
BTW - 'm running the queries directly on the server, so no network latency in play here.
Thanks in advance
aBBy.*11g Env:*
PLAN_TABLE_OUTPUT
Plan hash value: 4147636274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1104 | 376K| 394 (1)| 00:00:05 |
| 1 | SORT ORDER BY | | 1104 | 376K| 394 (1)| 00:00:05 |
| 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1104 | 376K| 393 (1)| 00:00:05 |
|* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1136 | | 15 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
15 rows selected.
*10g Env:*
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4147636274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1137 | 373K| 389 (1)| 00:00:05 |
| 1 | SORT ORDER BY | | 1137 | 373K| 389 (1)| 00:00:05 |
| 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1137 | 373K| 388 (1)| 00:00:05 |
|* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1137 | | 15 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
15 rows selected.
The query used is:
explain plan for
select
NCP_DETAIL_ID ,
NCP_ID ,
STATUS_ID ,
FIBER_NODE ,
NODE_DESC ,
GL ,
FTA_ID ,
OLD_BUS_ID ,
VIRTUAL_NODE_IND ,
SERVICE_DELIVERY_TYPE ,
HHP_AUDIT_QTY ,
COMMUNITY_SERVED ,
CMTS_CARD_ID ,
OPTICAL_TRANSMITTER ,
OPTICAL_RECEIVER ,
LASER_GROUP_ID ,
UNIT_ID ,
DS_SLOT ,
DOWNSTREAM_PORT_ID ,
DS_PORT_OR_MOD_RF_CHAN ,
DOWNSTREAM_FREQ ,
DOWNSTREAM_MODULATION ,
UPSTREAM_PORT_ID ,
UPSTREAM_PORT ,
UPSTREAM_FREQ ,
UPSTREAM_MODULATION ,
UPSTREAM_WIDTH ,
UPSTREAM_LOGICAL_PORT ,
UPSTREAM_PHYSICAL_PORT ,
NCP_DETAIL_COMMENTS ,
ROW_CHANGE_IND ,
STATUS_DATE ,
STATUS_USER ,
MODEM_COUNT ,
NODE_ID ,
NODE_FIELD_ID ,
CREATE_USER ,
CREATE_DT ,
LAST_CHANGE_USER ,
LAST_CHANGE_DT ,
UNIT_ID_IP ,
US_SLOT ,
MOD_RF_CHAN_ID ,
DOWNSTREAM_LOGICAL_PORT ,
STATE
from markethealth.NCP_DETAIL_TAB
WHERE UNIT_ID = :B1
ORDER BY UNIT_ID, DS_SLOT, DS_PORT_OR_MOD_RF_CHAN, FIBER_NODE
This is the query used for Query 1.
Stats differences are:
1. Rownum differes by apprx - 90K more rows in 10g env
2. RAC env has 4 additional columns (excluded in the select statement for analysis purposes).
3. Gather Stats was performed with estimate_percent = 20 in 10g and estimate_percent = 50 in 11g. -
Cpu time is not getting displayed in explain plan
Hi All,
I am trying to analyze one query using explain plan .like below
1) explain plan for
SELECT /*+ parallel(tsp,8) use_hash( tsp tp) */ count(1)
FROM router tp,
receiver tsp
WHERE tp.rs = tsp.rp
AND creater_date >=to_date('04032009000000','ddmmyyyyhh24miss')
and tsp.XVF is not null
and tp.XVF is not null
and tp.role_name='BR';
2)@$ORACLE_HOME/rdbms/admin/utlxpls.sql
But i am getting only following columns in result .
| Id | Operation | Name | Rows | Bytes | Cost |
No Cpu time preset .
How can i extimate CPU time ?
Pls help
Thanksam_73798 wrote:
I am trying to analyze one query using explain plan .like below
But i am getting only following columns in result .
| Id | Operation | Name | Rows | Bytes | Cost |
No Cpu time preset .
How can i extimate CPU time ?You need to mention your database version (4-digits, e.g. 9.2.0.8).
In Oracle 9i CPU costing is disabled by default, you need to gather WORKLOAD system statistics to enable the CPU costing.
In 10g CPU costing is enabled by default and uses default NOWORKLOAD system statistics if no WORKLOAD system statistics have been gathered. It can only be disabled by setting an undocumented parameter or by changing the OPTIMIZER_FEATURES_ENABLE parameter back to 9i compatibility.
You can check the status of your system statistics by running the following query in SQL*Plus:
column sname format a20
column pname format a20
column pval2 format a20
select
sname
, pname
, pval1
, pval2
from
sys.aux_stats$;Can you show us the actual (complete) output you get from "utlxpls.sql"? Use the \ tag to preserve formatting here:
\output
\will show asoutput
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
What is the significance of "cost" column in explain plan
Hi,
Can anyone explain what is the meaning of the values which we get in the cost column in the explain plan..For Ex : Cost : 4500 . What does this value mean...and is it measured in which form of units...i mean seconds,nanoseconds etckingfisher,
Ok one more link for you but I shall quote the text also here,
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#i82005
The cost is an estimated value proportional to the expected resource use needed to execute the statement with a particular plan. The optimizer calculates the cost of access paths and join orders based on the estimated computer resources, which includes I/O, CPU, and memory.
And few paragraphs down,
13.4.1.3.3 Cost
The cost represents units of work or resource used. The query optimizer uses disk I/O, CPU usage, and memory usage as units of work. So, the cost used by the query optimizer represents an estimate of the number of disk I/Os and the amount of CPU and memory used in performing an operation. The operation can be scanning a table, accessing rows from a table by using an index, joining two tables together, or sorting a row set. The cost of a query plan is the number of work units that are expected to be incurred when the query is executed and its result produced.
The access path determines the number of units of work required to get data from a base table. The access path can be a table scan, a fast full index scan, or an index scan. During table scan or fast full index scan, multiple blocks are read from the disk in a single I/O operation. Therefore, the cost of a table scan or a fast full index scan depends on the number of blocks to be scanned and the multiblock read count value. The cost of an index scan depends on the levels in the B-tree, the number of index leaf blocks to be scanned, and the number of rows to be fetched using the rowid in the index keys. The cost of fetching rows using rowids depends on the index clustering factor. See "Assessing I/O for Blocks, not Rows".
The join cost represents the combination of the individual access costs of the two row sets being joined, plus the cost of the join operation.
Now I guess if you read this part, it should be pretty clear what cost is.Cost is an evlaution of the resource that is estimated by Oracle for every step incurred in the uery execution.There are no of steps and each may involve doing IO,consuming CPU and/or using memory.Cost is a factor which oracle uses combining all of these 3 (depending on the version) together to propose the work done or expected to be done in exeuting a query.So this actualy should represent the time spent exactly on each and every step.That's what the objective frm cost is.But at the moment,this is not there.There amy be a situation that cost is shown as very high but query is working fine.There are woraround which can bring the cost down for example using and tweaking optimizer_index_cost_adj parameter , we can propose oracle regarding our indexes and it may pick up lesser cost evaluation.What is mentioned is that this model is becoming more and more mature and in the next releases, we may see that cost is representing exactly the time that we would spend inthe query.At the moment,its not there.So as Chris mentioned,Tuning for low cost only is not a good way.
I suggest you grab a copy of JL's book.He has explained it much better in his book.
Hope I said some thing useful.
Aman.... -
Time column of an explain plan
Hi,
I'm using Oracle version 10.2.0.3.0. I have 2 tables with 10 million records each. The DDL is as follows.
create table bigtable(col1 varchar2(20), col2 varchar2(20))
create table bigtablechild(col1 varchar2(20), col2 varchar(20))
bigtablechild.col1 is a foreign key to bigtable.col1. Below is the query and explain plan. Over several executions, the query runs for about 20 seconds before returning results. Could anyone please explain what the time column represents? It doesn't match the time it took to return results.
SQL> set autotrace on
SQL>
SQL> select b.col2
2 from bigtable a, bigtablechild b
3 where a.col1 = b.col1
4 and a.col1 = 'ABC6554';
COL2
XYZ6554
XYZ6554
XYZ6554
XYZ6554
XYZ6554
Execution Plan
Plan hash value: 4210396901
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 5 | 150 | 21538 (4)| 00:04:19 |
|* 1 | HASH JOIN | | 5 | 150 | 21538 (4)| 00:04:19 |
|* 2 | TABLE ACCESS FULL| BIGTABLE | 1 | 10 | 13124 (4)| 00:02:38 |
|* 3 | TABLE ACCESS FULL| BIGTABLECHILD | 5 | 100 | 8413 (5)| 00:01:41 |
Predicate Information (identified by operation id):
1 - access("A"."COL1"="B"."COL1")
2 - filter("A"."COL1"='ABC6554')
3 - filter("B"."COL1"='ABC6554')
Statistics
0 recursive calls
0 db block gets
93672 consistent gets
91845 physical reads
0 redo size
463 bytes sent via SQL*Net to client
396 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
5 rows processedHi,
the values in the TIME column are calculated from cost using system I/O statistics. If dbms_stats.gather_system_stats has never been run, then these stats have default values which may be very far from the truth. In your case, the optimizer expects a single-block I/O read to take about 12 ms, while in reality it is closer to 1 ms, thus the discrepancy between the prediction and actual results.
In general, TIME column is not very helpful not just because of potentially incorrect I/O time estimates, but also because it is hard to predict how much data will be found in cash, so I would recommend not to pay too much attention to it (note, however, that A-time column, on the other hand, is extremely useful, but it's only available if rowsource statistics for the plan have been populated).
Best regards,
Nikolay -
Understanding the COST column of an explain plan
Hello,
I executed the following query, and obtained the corresponding explain plan:
select * from isis.clas_rost where cour_off_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS 2 10 1540
TABLE ACCESS BY INDEX ROWID ISIS CLAS_ROST 2 10 1540
INDEX RANGE SCAN ISIS CLAS_ROST_N2 1 10
I don't understand how these cost values add up. What is the significance of the cost in each row of the explain plan output?
By comparison, here is another plan output for the following query:
select * from isis.clas_rost where clas_rost_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS 1 1 154
TABLE ACCESS BY INDEX ROWID ISIS CLAS_ROST 1 1 154
INDEX UNIQUE SCAN ISIS CLAS_ROST_U1 1 1
Thanks!For the most part, you probably want to ignore the cost column. The cardinality column is generally what you want to pay attention to.
Ideally, the cost column is Oracle's estimate of the amount of work that will be required to execute a query. It is a unitless value that attempts to combine the cost of I/O and CPU (depending on the Oracle version and whether CPU costing is enabled) and to scale physical and logical I/O appropriately). As a unitless number, it doesn't really relate to something "real" like the expected number of buffer gets. It is also determined in part by initialization parameters,session settings, system statistics, etc. that may artificially increase or decrease the cost of certain operations.
Beyond that, however, cost is problematic because it is only as accurate as the optimizer's estimates. If the optimizer's estimates are accurate, that implies that the cost is reasonably representative (in the sense that a query with a cost of 200 will run in less time than a query with a cost of 20000). But if you're looking at a query plan, it's generally because you believe there may be a problem which means that you are inherently suspicious that some of the optimizer's estimates are incorrect. If that's the case, you should generally distrust the cost.
Justin -
Execution time from explain plan
Hi
How can i get the execution time of a query from explain plan (not tkprof). I don't see the execution time in the plan table output.
ThanksExplain plan won't give execution time of a query because:
- it does not execute the query
- it only evaluates the execution plan and gives estimated costs
I dont't know if it is possible to deduce execution time from estimated cost.
Message was edited by:
Pierre Forstmann -
Hi,
I have explain plan a sql using Enterprise manager. What does the cost indicates, if a query is having a cost of 119 and after tuning its cost is 16 what does it indicate. What is the relationship between time taken by a query to run and its cost.
Regards
RajHi, Raj.
<What does the cost indicate.
In theory, the cost indicates how long a query should take if actually run. Small number means fast, bug number means slow. Its just an arbitrary number computed to indicate how long a query should take to run.
In practice, the cost has little meaning especially in 10g. Its becoming common enough for a high cost to actually run faster than a low cost that our DBA group pretty much ignores the cost.
Remember that the cost is computed before the query is actually run, against computed statistics and available system resources. The cost is an guess, and like all guesses is subject to reality checks.
Message was edited by:
riedelme -
Hi,
Is there any relationship between the cost factor in the explain plan and query execution time. I have come across situations in both ways, i.e. high cost and low execution time, low cost and high execution time. What parameters do we need to consider in tuning a query high cost or low cost?So my assumption is that the lower cost does not guarantee faster response time. Again i have have seen many people try to reduce the cost first.Can anyone help me on this issue please.
Thanks-BhaskarCost is a metric that Oracle uses to estimate the runtime of a query. However, it is not something that you probably ought to pay a lot of attention to. If you are looking at the performance of a query, you are presumably operating on the assumption that the optimizer may have chosen an incorrect plan. If the optimizer chose an incorrect plan then by definition the cost is incorrect. If the cost is correct then, by definition, Oracle chose the correct plan.
It makes much more sense to focus on things like the cardinality of each step (the number of rows each step in the plan is expected to return). If the cardinality estimates are correct (or reasonably close), then the optimizer probably chose the correct plan. If the cardinality estimates are way off, the optimizer probably chose a less than optimal plan. And when you find the first step where the cardinality estimates are wildly incorrect, you'll know where you need to start focusing your tuning efforts.
Justin
Maybe you are looking for
-
Availability of Samsung SCX-4500W.
This is the wireless version of the printer. I am trying to find out when this will be available in the US
-
Issue with attaching photos to email
Hi, when I want to attach a photo to an email, I go to attach a file and the only choice I have to is to attach my entire iPhoto library. Can anyone help me work out how I can send individual photos? Thanks, Sue
-
When creating a menu with text in Photoshop, Indesign, whatever.. Once we bring the file into DVD Pro.. the text looks jaggid and horrible.. Can anyone tell me why? The menus were created at 720 x540 and it's a SIMPLE MENU.. Nothing crazy whatsoever.
-
Handling Exceptions thrown by EDT Thread?
Hi, How to handle exceptions thrown by EDT Thread?. If anybody can give any link or any example, then it really helpful. Thanks
-
IM08 supports new YouTube Feature 'Watch in high quality'
maybe not all of you have noticed the new feature on YT, to playback uploaded videos in higher quality (.. IF the upload offered higher quality... ) the difference is amazing: 1) shows no detail.. +who's that mennekin?+ 2) shows the new 'button'.. fe