Tuning sql - uneven execution times

Hi-
A common problem we have when we are performance tuning our sql queries is that an initial run of the query will be slow but subsequent runs of the same sql might be up to ten times faster. Presumably this results from some kind of caching.
This confounds our ability it to tune the sql, as we cannot distinguish changes in run time that result from changes to the sql or from whatever caching Oracle is doing.
Is there a way for us to tell Oracle "we are trying to tune this query, please don't do any caching" or some other way to get consistent run times for performance comparison?
Thanks,
Steve

jgarry wrote:
Which brings up another fundamental tuning issue - how do you order the importance of problems unless you start by measuring the elapsed times?I would argue that looking at what that elapsed time is spend on (wait events) is a lot more useful.
(I happen to agree with you Billy, I'm just pointing out what some tuning methodologies say and an aspect of compulsive tuning disorder. Never really suffered from that. 90%, if not more, of all performance problems I've ever dealt with were due to either application code or application/database design.
When you pop open the hood of a RDBMS or operating system to address performance problems, then you are saying by implication that the code is 100% correct and the design is a 100% correct.
I always get uncomfortable with people wanting to immediately pop the hood to fix performance problems. Set this s/pfile parameter.. turn that Oracle knob.. throw that switch. This is second guessing as to what the actual root cause of the problem is.
When I'm given a problem SQL to tune for performance (some of these spanned a couple of A4 pages for a single SQL!), may first question is always what is the goal? What is the query suppose to do? Not setting up a SQL trace, and playing with trace events and the like. That comes afterward, when you know for a fact that the design of the query is correct.
I think people underestimate SQL. It is a relatively simple language. Unlike object orientated and even procedural languages. And because it is seen as simple, very little though goes into designing a SQL "+program+" - as that is what a SQL statement is. A program that specifies how (sometimes enormous) data sets need to be processed, applying (sometimes very complex) business logic.
Ask the same same developer to write that in Java/.Net/etc and the developer will spend a significant time in designing the program. Yet, when writing it in SQL, very little though is given (IMO) by developers as to the design of that SQL program... as with very little code you are hitting large data sets doing some pretty complex processing.
So because SQL is treated as "+simplistic+", performance problems in this regard is often treated as a SQL problems. CBO not doing it correctly. Slapping more indexes on a table. Etc. Instead of looking at the design of that SQL and first determining whether that is correct or not.
Top down. Something that was drilled into me when I started programming in Cobol on mainframes years ago. You deal with design and problems from the top down. :-)
The real reconciliation comes in recognizing the importance of context, sequencing and iteration in problem definition. When you add multiuser issues into the mix you can get things like, users complain their queries take too long, developer starts tuning the sql since hey, most performance problems are sql, but the resources are sucked by something else entirely, or even the problem sql punching itself in the face).Yep. Have seen many SQLs that hurts themselves badly (in addition to the rest of the server). Like multiple passes through the same data set.
So shouldn't there be a "typical" load on the test system when tuning, rather than fresh system or empty system with iterations? It depends...It makes sense to deal with a base line ito performance and measurement and data volumes and so on when designing and coding.

Similar Messages

SQL Tuning and OPTIMIZER - Execution Time with " AND col .."

Hi all,
I get a question about SQL Tuning and OPTIMIZER.
There are three samples with EXPLAIN PLAN and execution time.
This "tw_pkg.getMaxAktion" is a PLSQL Package.
1.) Execution Time : 0.25 Second
2.) Execution Time : 0.59 Second
3.) Execution Time : 1.11 Second
The only difference is some additional "AND col <> .."
Why is this execution time growing so strong?
Many Thanks,
Thomas
----[First example]---
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as dbadmin2
SQL>
SQL> EXPLAIN PLAN FOR
2 SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
3                    FROM studie
4                 ) max_aktion
5 WHERE max_aktion.max_aktion_id < 900 ;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id | Operation            | Name        | Rows | Bytes | Cost (%CPU)| Time
|   0 | SELECT STATEMENT     |             |   220 |   880 |     5 (40)| 00:00:
|* 1 | INDEX FAST FULL SCAN| SYS_C005393 |   220 |   880 |     5 (40)| 00:00:
Predicate Information (identified by operation id):
   1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900)
13 rows selected
SQL>
Execution time (PL/SQL Developer says): 0.25 seconds
----[/First]---
----[Second example]---
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as dbadmin2
SQL>
SQL> EXPLAIN PLAN FOR
2 SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
3                    FROM studie
4                 ) max_aktion
5 WHERE max_aktion.max_aktion_id < 900
6    AND max_aktion.max_aktion_id <> 692;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id | Operation            | Name        | Rows | Bytes | Cost (%CPU)| Time
|   0 | SELECT STATEMENT     |             |    11 |    44 |     6 (50)| 00:00:
|* 1 | INDEX FAST FULL SCAN| SYS_C005393 |    11 |    44 |     6 (50)| 00:00:
Predicate Information (identified by operation id):
   1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
              "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692)
14 rows selected
SQL>
Execution time (PL/SQL Developer says): 0.59 seconds
----[/Second]---
----[Third example]---
SQL> EXPLAIN PLAN FOR
2 SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
3                    FROM studie
4                 ) max_aktion
5 WHERE max_aktion.max_aktion_id < 900
6    AND max_aktion.max_aktion_id <> 692
7    AND max_aktion.max_aktion_id <> 392;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id | Operation            | Name        | Rows | Bytes | Cost (%CPU)| Time
|   0 | SELECT STATEMENT     |             |     1 |     4 |     6 (50)| 00:00:
|* 1 | INDEX FAST FULL SCAN| SYS_C005393 |     1 |     4 |     6 (50)| 00:00:
Predicate Information (identified by operation id):
   1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
              "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692 AND
              "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>392)
15 rows selected
SQL>
Execution time (PL/SQL Developer says): 1.11 seconds
----[/Third]---Edited by: thomas_w on Jul 9, 2010 11:35 AM
Edited by: thomas_w on Jul 12, 2010 8:29 AM

Hi,
this is likely because SQL Developer fetches and displays only limited number of rows from query results.
This number is a parameter called 'sql array fetch size', you can find it in SQL Developer preferences under Tools/Preferences/Database/Advanced tab, and it's default value is 50 rows.
Query scans a table from the beginning and continue scanning until first 50 rows are selected.
If query conditions are more selective, then more table rows (or index entries) must be scanned to fetch first 50 results and execution time grows.
This effect is usually unnoticeable when query uses simple and fast built-in comparison operators (like = <> etc) or oracle built-in functions, but your query uses a PL/SQL function that is much more slower than built-in functions/operators.
Try to change this parameter to 1000 and most likely you will see that execution time of all 3 queries will be similar.
Look at this simple test to figure out how it works:
CREATE TABLE studie AS
SELECT row_number() OVER (ORDER BY object_id) studie_id, o.*
FROM (
SELECT * FROM all_objects
CROSS JOIN
(SELECT 1 FROM dual CONNECT BY LEVEL <= 100)
) o;
CREATE INDEX studie_ix ON studie(object_name, studie_id);
ANALYZE TABLE studie COMPUTE STATISTICS;
CREATE OR REPLACE FUNCTION very_slow_function(action IN NUMBER)
RETURN NUMBER
IS
BEGIN
RETURN action;
END;
/'SQL array fetch size' parameter in SQLDeveloper has been set to 50 (default). We will run 3 different queries on test table.
Query 1:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id < 900
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      1.22       1.29          0       1310          0          50
total        3      1.22       1.29          0       1310          0          50
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows     Row Source Operation
     50 INDEX FAST FULL SCAN STUDIE_IX (cr=1310 pr=0 pw=0 time=355838 us cost=5536 size=827075 card=165415)(object id 79865)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
     50   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id < 900
      AND max_aktion.max_aktion_id > 800
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.01          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      8.40       8.62          0       9351          0          50
total        3      8.40       8.64          0       9351          0          50
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows     Row Source Operation
     50 INDEX FAST FULL SCAN STUDIE_IX (cr=9351 pr=0 pw=0 time=16988202 us cost=5552 size=41355 card=8271)(object id 79865)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
     50   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id = 600
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     18.72      19.16          0      19315          0           1
total        3     18.73      19.16          0      19315          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows     Row Source Operation
      1 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      1   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 1 - 1,29 sec, 50 rows fetched, 1310 index entries scanned to find these 50 rows.
Query 2 - 8,64 sec, 50 rows fetched, 9351 index entries scanned to find these 50 rows.
Query 3 - 19,16 sec, only 1 row fetched, 19315 index entries scanned (full index).
Now 'SQL array fetch size' parameter in SQLDeveloper has been set to 1000.
Query 1:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id < 900
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     18.35      18.46          0      19315          0         899
total        3     18.35      18.46          0      19315          0         899
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows     Row Source Operation
    899 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=20571272 us cost=5536 size=827075 card=165415)(object id 79865)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
    899   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id < 900
      AND max_aktion.max_aktion_id > 800
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     18.79      18.86          0      19315          0          99
total        3     18.79      18.86          0      19315          0          99
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows     Row Source Operation
     99 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=32805696 us cost=5552 size=41355 card=8271)(object id 79865)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
     99   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                     FROM studie
              ) max_aktion
WHERE max_aktion.max_aktion_id = 600
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     18.69      18.84          0      19315          0           1
total        3     18.69      18.84          0      19315          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows     Row Source Operation
      1 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      1   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)And now:
Query 1 - 18.46 sec, 899 rows fetched, 19315 index entries scanned.
Query 2 - 18.86 sec, 99 rows fetched, 19315 index entries scanned.
Query 3 - 18.84 sec, 1 row fetched, 19315 index entries scanned.

Top Sqls by Execution time

Hi,
Can you please provide a query which gives top 5 SQLs ordered by Execution time ( i.e Elapsed Time/No of Executions), for one day.
Appreciate your help.
Thanks
Sravan

Hi,
welcome to the forum!
Here is the query:
select sql_id, sum(elapsed_time_delta)/1e6 total_elapsed_seconds, sum(executions_delta) total_executions
from dba_hist_sqlstat st,
dba_hist_snapshot sn
where st.snap_id = sn.snap_id
and sn.begin_interval_time between sysdate-1 and sysdate
group by sql_id
order by 2 desc;Keep in mind that in order to use it you need the diagnostic pack license.
Best regards,
Nikolay
Edited by: Nikolay Savvinov on Aug 24, 2012 8:40 AM (changed from microseconds to seconds)

Clustering of SQL query execution times

In doing some query execution experiments I have noted a curious (to me, anyhow) clustering of execution times around two distinct points. Across about 100 tests each running 1000 queries using (pseudo-)randomly generated IDs the following pattern emerges. The queries were run from Java using all combinations of pooled/non-pooled and thin/oci driver combinations:
     100          *
     90          *
R     80          *
u     70          *
n     60          *
s     50          *
     40          *                                             *
     30          *                                             *
     20          *                                        *     *     *
     10          *     *                              *     *     *     *
          0     100     200     300     400     500     600     700     800     900     1000     1100     1200
                                   Time(ms)Where about half of the total execution times cluster strongly about a given (short) time value with a smaller but broader clustering at a significantly slower mark, with zero intermediate values. The last point is the one I find most curious.
What I would have expected is something like this:
     100
     90
R     80
u     70
n     60
s     50
     40                              *
     30                         *     *     *
     20                    *     *     *     *     *     *
     10          *     *     *     *     *     *     *     *     *     *
          0     100     200     300     400     500     600     700     800     900     1000     1100     1200
                                   Time(ms)The variables I have tentatively discounted thus far:
-query differences (single query used)
-connection differences (using single pooled connection)
-garbage collection (collection spikes independent of query execution times)
-amount of data returned in bytes (single varchar2 returned and size is independent of execution time)
-driver differences (thin and oci compared, overall times differ but pattern of clustering remains)
-differences between Statement and PreparedStatement usage (both show same pattern)
I know this is a rather open-ended question, but does the described pattern seem faniliar or spark any thoughts?
DB-side file I/O?
Thread time-slicing variations (client or DB-side)?
FWIW, the DB is 9.2.0.3 DB and the clients are running on WinXP with Java 5.0 and 9i drivers.
Thanks and regards,
M

Further context:
Are your queries only SELECT queries ?
Yes, the same SELECT query is used for all tests. The only variable is the bind variable used to identify the primary key of the selection set (i.e. SELECT a.* from a, b, c where a.x = b.x and b.y = c.y and c.pk = ?) where all PKs and FKs are indexed.Do the queries always use the same tables, the same where clauses ?
Yes, the same tables are always invoked. The where clauses invoked are identical with the excepton of the single bind variable as described above.Do your queries always use bind variables ?
A single bind variable is used in all invocations as described above.Are your queries also running in single user mode or multi user mode (do you use SELECT FOR UPDATE ?) ?
We are not using SELECT FOR UPDATEDid something else run on the database/on the server hosting the database on the same time ?
I have not eliminated the idea, but the test has been repeated roughly 100 times over the course of a week and at different times of day with the same pattern emerging. I suppose it is not out of the question that a resource-hogging process is running consistently and constantly on the DB-side box.Thanks for the input,
M

Sql Query execution time

Hello All,
I have the following query as part of other three queries for a report. While as the other two take less than 3 seconds to execute, this one goes on for about an hour.
Environment is 9i/11.5.9 apps on HP Ux 11.0.
SELECT    a.move_order_line_id,c.inventory_location_id
    ,c.segment1||'.'||c.segment2||'.'||c.segment3||'.'||c.segment4 Loc,
    b.lot_number Lot,
    -1*b.primary_quantity lot_qty
FROM     mtl_material_transactions a,
    mtl_transaction_lot_numbers b,
    mtl_item_locations c
WHERE a.transaction_id = b.transaction_id
AND   a.locator_id    = c.inventory_location_id
UNION
SELECT     a.move_order_line_id,c.inventory_location_id
     ,c.segment1||'.'||c.segment2||'.'||c.segment3||'.'||c.segment4 Loc,
     b.lot_number Lot,
     -1*b.primary_quantity lot_qty
FROM      mtl_material_transactions a,
     mtl_transaction_lot_numbers b,
     mtl_item_locations c
WHERE a.transaction_id = b.transaction_id
AND   a.locator_id     = c.inventory_location_id
UNION
SELECT     a.move_order_line_id,c.inventory_location_id
     ,c.segment1||'.'||c.segment2||'.'||c.segment3||'.'||c.segment4 Loc,
     b.lot_number Lot,
     b.primary_quantity lot_qty
FROM      mtl_material_transactions_temp a,
     mtl_transaction_lots_temp b,
     mtl_item_locations c
WHERE a.transaction_temp_id        = b.transaction_temp_id
AND   a.locator_id          = c.inventory_location_id
UNION
SELECT line_id move_order_line_id, null inventory_location_id,
                    null Loc,
                    null Lot,
                    quantity lot_qty
FROM mtl_txn_request_lines
WHERE line_status = 7
and quantity_detailed is null
order by 1;     None of the tables involved has more than 300K rows in it.
Would appreciate some help.
A/A

Hello,
In her attempt to help, need to know the answers to the following questions:
1 .- The 3 queries may return independently repeated same records or records?
1.a. - If you were to take the case, you would want that before two results appear equal only one row?
1.b. - If it is impossible to duplicated rows of each of the three sentences, then use and replace
operator 'UNION' with 'UNION ALL'.
Since the   operator 'UNION' operations makes 'SORT' to make the distinction between
results and penalizes volume data on performance.
2 .- He says that it is a 'report', no? Consultations are united? Because columns?
3 .- Do you know the 'EXPLAIN PLAN' of the sentence? If known, please send an email.Waiting for news, a greeting.
Edited by: RamonRQ on 21-oct-2011 3:54

Query Execution time - Elapsed time v Actual time taken

Hi All,
I have this scenario where I am querying a single table with the following results. It is a very heavy query in that there are multiple aggregate functions and multiple unions on it. Even if the query is written poorly (i doubt it is) why would the actual
time taken to execute the query be much more than the statistics provided through the following commands?
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
Attached are the stats provided for the relevant query in question.
Table '123456789_TEMP_DATA'. Scan count 178, logical reads 582048, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 936 ms, elapsed time = 967 ms.
2014-01-06 17:36:41.383
Now, although the CPU Time/Elapsed time shows that it takes less than a second, it actually takes more than 15 seconds to fetch the results. (This is the actual time that you get on the bottom bar of the Query pane as well.)
What is the reason? Why is it that there is such a big discrepancy between the numbers? How can I improve this situation?
Thanks!

Yes. I am returning a huge number of rows to the client.
The query is simply against a single table.
Select
'First Record',AVG(COLUMN1),STDEV(COLUMN1
),COUNT(COLUMN1)
FROM [TABLE1] WHERE (SOME CONDITION)
UNION ALL
Select 'Second Record',AVG(COLUMN2),STDEV(COLUMN2),COUNT(COLUMN2) FROM [TABLE1]
WHERE (SOME OTHER CONDITION)
Imagine there are 178 records fetched in this manner with 178 UNIONs. The WHERE clause will always change for each SELECT statement.
Now, the question is not so much about the query itself, but why the execution time is actually 15 seconds whilst the SQL STATISTICS show it to be 936ms (<1 second)
Thanks!

How to get query execution time without running...?

Hi ,
I had one requirement .... as follows ......
i had 3 sql statements . I need to execute only one sql which execution time is very less.
Can any one help me , how to get query execution time without running that query and without using explain plan..?
Thanks,
Rajesh

Kim Berg Hansen wrote:
But you have ruled out explain plan for some reason, so I cannot help you.OP might get some answers if query was executed before - but since restart. Check V$SQL dynamic performance view for SQL_TEXT = your query. Then ROUND(ELAPSED_TIME / EXECUTIONS / 1000000) will give you average elapsed time.
SY.
Edited by: Solomon Yakobson on Apr 3, 2012 8:44 AM

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,
Sigcle

The 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

Need help Recording SQL Execution Times in Database

Hello,
I have an interesting thing I am tiring to do. I want to record how much time (Wall Clock) it took the database to execute any select statement against o one particular view lets call it CUST_ORDERS_V.
I would like to record who ran it, what the select statement was (SQL Text) and how much time it took and maybe a few other ancillary things if possible.
Looking at most of my requirements took me right to Oracle Auditing and the SYS.AUD$ table. After setting up auditing with:
audit_trail=db,extended
and
audit select on ME.CUST_ORDERS_V by access;I get every piece of information I need except for the execution time! Wow that would be great if Oracle recorded that!!! So I was thinking if I could. I was considering a trigger on SYS.AUD$ (I know evil thoughts) that would look into some V$ view and get the execution time and write it into some custom table with a link back to SYS.AUD$.
This might be the complete wrong way to do it. I was wondering if anyone had any ideas on this.
I am running on 11.2.0.3 EE. I am on EE so I can use Fine Grained Auditing if it is needed. However I DO NOT have the Tuning or Diagnostic Pack.

>
Hi again,
Yes, a complete set of times from end to end would be great. However
for now I need to stick with what is in my domain of control, the database.
Maybe after the DB I will look to get the others.But your point about the operators blaming the db brings up the probability
that after you tell them that the db is not the issue, they'll start to blame
the app server, the cabling, their OS, the browser, the tea-lady...
If you have click===> page, they have no more places to hide and have to
actually work for a living ;)
I do not think I can access v$active_session_history as I do not have the Tuning Pack.Well, presumably there is a business case for this project. Why not tell management
that it's required?
Otherwise, you could go to ashmasters.com - a site run by Kyle Hailey (Oak Table
member and author). He has an Open Source ASH "substitute" which you might
like to try - haven't used it myself, but if Kyle Hailey's behind it, then it's at
least worthy of investigation.
HTH,
Paul...

How to find out the execution time of a sql inside a function

Hi All,
I am writing one function. There is only one IN parameter. In that parameter, i will pass one SQL select statement. And I want the function to return the exact execution time of that SQL statement.
CREATE OR REPLACE FUNCTION function_name (p_sql IN VARCHAR2)
RETURN NUMBER
IS
exec_time NUMBER;
BEGIN
--Calculate the execution time for the incoming sql statement.
RETURN exec_time;
END function_name;
/

Please note that wrapping query in a "SELECT COUNT(*) FROM (<query>)" doesn't necessarily reflect the execution time of the stand-alone query because the optimizer is smart and might choose a completely different execution plan for that query.
A simple test case shows the potential difference of work performed by the database:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Session altered.
SQL>
SQL> drop table count_test purge;
Table dropped.
Elapsed: 00:00:00.17
SQL>
SQL> create table count_test as select * from all_objects;
Table created.
Elapsed: 00:00:02.56
SQL>
SQL> alter table count_test add constraint pk_count_test primary key (object_id)
Table altered.
Elapsed: 00:00:00.04
SQL>
SQL> exec dbms_stats.gather_table_stats(ownname=>null, tabname=>'COUNT_TEST')
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.29
SQL>
SQL> set autotrace traceonly
SQL>
SQL> select * from count_test;
5326 rows selected.
Elapsed: 00:00:00.10
Execution Plan
Plan hash value: 3690877688
| Id | Operation         | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |            | 5326 |   431K|    23   (5)| 00:00:01 |
|   1 | TABLE ACCESS FULL| COUNT_TEST | 5326 |   431K|    23   (5)| 00:00:01 |
Statistics
          1 recursive calls
          0 db block gets
        419 consistent gets
          0 physical reads
          0 redo size
     242637 bytes sent via SQL*Net to client
       4285 bytes received via SQL*Net from client
        357 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
       5326 rows processed
SQL>
SQL> select count(*) from (select * from count_test);
Elapsed: 00:00:00.00
Execution Plan
Plan hash value: 572193338
| Id | Operation             | Name          | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |               |     1 |     5   (0)| 00:00:01 |
|   1 | SORT AGGREGATE       |               |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| PK_COUNT_TEST | 5326 |     5   (0)| 00:00:01 |
Statistics
          1 recursive calls
          0 db block gets
         16 consistent gets
          0 physical reads
          0 redo size
        412 bytes sent via SQL*Net to client
        380 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL>As you can see the number of blocks processed (consistent gets) is quite different. You need to actually fetch all records, e.g. using a PL/SQL block on the server to find out how long it takes to process the query, but that's not that easy if you want to have an arbitrary query string as input.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

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.

Execution time of sql query differing a lot between two computer

hi
execution time of a query in my computer and more than 30 different computer is less than one second but on one of our
customers' computers, execution time is more than ten minute. databases and data and queries are same. i re-install sql but problem remains. my sql is ms sql 2008 r2.
any one has idea for this problem?

Hi mahdi,
Obviously, we can't get enough information to help you troubleshoot this issue. So, please elaborate your issue with more detail so that the community members can help you in more effecient manner.
In addition, here is a good article regarding checklist for analyzing Slow-Running queries. Please see:
http://technet.microsoft.com/en-us/library/ms177500(v=sql.105).aspx
And SQL Server Profiler and Performance Monitor are good tools to troubleshoot performance issue, please see:
Correlating SQL Server Profiler with Performance Monitor:
https://www.simple-talk.com/sql/database-administration/correlating-sql-server-profiler-with-performance-monitor/
Regards,
Elvis Long
TechNet Community Support

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
raj

what 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)

To Determine the Execution Time of a PL/SQL Block

Hi
I need to determine the total execution time taken by a PL/SQL code (Anonymous Block , Functions etc).
Can anyone please let me know how can I determine the same?
Regards
Kapil.
Edited by: KapilK on Mar 2, 2009 11:00 AM

Kapil,
When you launching your block using sql script or just typing the entire thing
SQL> set timi on;
SQL> BEGIN
2 MYPROC;
3 COMMIT;
4 END;
5 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.64Regards

Feature request - execution time in SQL Developer

I am looking for some feature to detail the execution time of packages/stored procedures/functions. When a package completes execution, lets say, it took longer time than usual ; I would like to know which stored procedures or SQLs within took the longest time. I could trace the session. It will be very helpful if there is a feature on the tool.
Thanks

Look into PL/SQL Profiling. If you are on RDBMS version 11, then profiling command appears in context menu and toolbar.

Tuning sql - uneven execution times

Similar Messages

Maybe you are looking for