Execution plan caching in oracle

Does oracle store the explain plan in memory cache?
Edited by: :) on Aug 2, 2011 10:45 PM

It depends.
In general execution plan don't change if Oracle has found a sharable cursor in shared pool even if related table data change.
But it can depend on Oracle version, on the bind variables usage by the query (look for adaptative cursor sharing in 11G). It depends also if statistics for related tables and objects have been recomputed with some flag or not to invalidate plan (aka cursors).
Tom Kyte has written in his Expert Oracle book (page 148 that you can read online with Google Books):
>
The shared pool was designed so that query plans would be used over and over again.
>
Edited by: P. Forstmann on 2 août 2011 19:38
Edited by: P. Forstmann on 2 août 2011 19:42

Similar Messages

SQL Query C# Using Execution Plan Cache Without SP

I have a situation where i am executing an SQL query thru c# code. I cannot use a stored procedure because the database is hosted by another company and i'm not allowed to create any new procedures. If i run my query on the sql mgmt studio the first time
is approx 3 secs then every query after that is instant. My query is looking for date ranges and accounts. So if i loop thru accounts each one takes approx 3 secs in my code. If i close the program and run it again the accounts that originally took 3 secs
now are instant in my code. So my conclusion was that it is using an execution plan that is cached. I cannot find how to make the execution plan run on non-stored procedure code. I have created a sqlcommand object with my queary and 3 params. I loop thru each
one keeping the same command object and only changing the 3 params. It seems that each version with the different params are getting cached in the execution plans so they are now fast for that particular query. My question is how can i get sql to not do this
by either loading the execution plan or by making sql think that my query is the same execution plan as the previous? I have found multiple questions on this that pertain to stored procedures but nothing i can find with direct text query code.
Bob;

I did the query running different accounts and different dates with instant results AFTER the very first query that took the expected 3 secs. I changed all 3 fields that i've got code for parameters for and it still remains instant in the mgmt studio but
still remains slow in my code. I'm providing a sample of the base query i'm using.
select i.Field1, i.Field2,
d.Field3 'Field3',
ip.Field4 'Field4',
k.Field5 'Field5'
from SampleDataTable1 i,
SampleDataTable2 k,
SampleDataTable3 ip,
SampleDataTable4 d
where i.Field1 = k.Field1 and i.Field4 = ip.Field4
i.FieldDate between '<fromdate>' and '<thrudate>'
and k.Field6 = <Account>
Obviously the field names have been altered because the database is not mine but other then the actual names it is accurate. It works it just takes too long in code as described in the initial post.
My params setup during the init for the connection and the command.
sqlCmd.Parameters.Add("@FromDate", SqlDbType.DateTime);
sqlCmd.Parameters.Add("@ThruDate", SqlDbType.DateTime);
sqlCmd.Parameters.Add("@Account", SqlDbType.Decimal);
Each loop thru the code changes these 3 fields.
sqlCommand.Parameters["@FromDate"].Value = dtFrom;
sqlCommand.Parameters["@ThruDate"].Value = dtThru;
sqlCommand.Parameters["@Account"].Value = sAccountNumber;
SqlDataReader reader = sqlCommand.ExecuteReader();
while (reader.Read())
reader.Close();
One thing i have noticed is that the account field is decimal(20,0) and by default the init i'm using defaults to decimal(10) so i'm going to change the init to
sqlCmd.Parameters["@Account"].Precision = 20;
sqlCmd.Parameters["@Account"].Scale = 0;
I don't believe this would change anything but at this point i'm ready to try anything to get the query running faster.
Bob;

How to write SQL in crystal report that can reuse SQL execution plan cache?

I write the following SQL with crystal report parameter fields, and it is connecting to SQL 2005
Select Name from Customer where CustID = '{?CustID}'
The SQL profiler show that It is an ad-hoc query, how to write parameterized SQL which can reuse Execution Plan.
Edited by: Chan Yue Wah on May 14, 2009 3:17 AM

Since there are too many report, it is not possible rewrite all. Is that crystal report do not have option to change how it query the database ?

Explain Plan Cache?

How do you flush the Explain Plan Cache on Oracle 10g?

Do you refer to the contents of these views?
V$SQLAREA_PLAN_HASH
V$SQL_PLAN
V$SQL_PLAN_STATISTICS
V$SQL_PLAN_STATISTICS_ALL
If this is the case, those cannot be flushed but by an instance restart.
If you mean flushing the library cache, then this can be achieved by means of the command:
ALTER SYSTEM FLUSH SHARED POOL;
~ Madrid
http://hrivera99.blogspot.com/

Executions Plans stored on CACHE

Hello Friends and Oracle Gurus...
I'm not much expert on Execution Plan but I have a select on Oracle 9.2.0.1.0 Windows 2003 server that takes too long since a few days ago...
When I look on E.Manager, Session Details... its doing a full table scan in one of my tables....
But just above the Execution Plan is a message saying..
EXECUTION PLAN STORED ON CACHE: MODE: ALL_ROWS
However, my OPTIMIZER_MODE is CHOOSE and all tables on select have statistics up to date...
How Did Oracle use this plan and how eliminate it and use another one? that would accept CHOOSE because the statistics?
Tks for everyone

Guys..
here is the select I was talking about
SELECT SUM(NOTAS_ITENS.QUANTIDADE),NOTAS_ITENS.CHAVE_NOTA, NOTAS_ITENS.NUMPED,SUM(NOTAS_ITENS.PESO_BRUTO),NOTAS_ITENS.CHAVE_ALMOXARIFADO,
NOTAS_ITENS.VALOR_TOTAL, NOTAS_ITENS.CHAVE,
PRODUTOS.CPROD, PRODUTOS.CODIGO, PRODUTOS.DESCRICAO, PRODUTOS.LOCACAO, PRODUTOS.VASILHAME,PRODUTOS.PESO_LIQUIDO,
UNIDADES.UNIDADE,
PERICULOSIDADE.DESCRICAO
FROM NOTAS_ITENS, PRODUTOS, UNIDADES, PERICULOSIDADE
WHERE (NOTAS_ITENS.CHAVE_PRODUTO = PRODUTOS.CPROD)
AND (NOTAS_ITENS.QUANTIDADE > 0)
AND (PRODUTOS.CHAVE_UNIDADE = UNIDADES.CHAVE)
AND (PRODUTOS.CHAVE_PERICULOSIDADE = PERICULOSIDADE.CHAVE(+))
AND ( CHAVE_NOTA IN
(SELECT CHAVE FROM NOTAS WHERE CHAVE = CHAVE AND (NOTAS.ATIVA = 'SIM') AND (NOTAS.IMPRESSO_ROMANEIO = 'NAO')))
GROUP BY PRODUTOS.CPROD, PRODUTOS.CODIGO, PRODUTOS.DESCRICAO, PRODUTOS.LOCACAO, PRODUTOS.VASILHAME, PRODUTOS.PESO_LIQUIDO,
UNIDADES.UNIDADE,
PERICULOSIDADE.DESCRICAO,
NOTAS_ITENS.CHAVE_NOTA, NOTAS_ITENS.NUMPED, NOTAS_ITENS.CHAVE_ALMOXARIFADO, NOTAS_ITENS.CHAVE, NOTAS_ITENS.VALOR_TOTAL
ORDER BY NOTAS_ITENS.CHAVE;
and here is the execution plan for him..
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=10615 Card=66372 Byt
es=11747844)
1 0 SORT (GROUP BY) (Cost=10615 Card=66372 Bytes=11747844)
2 1 HASH JOIN (Cost=8855 Card=66372 Bytes=11747844)
3 2 TABLE ACCESS (FULL) OF 'UNIDADES' (Cost=2 Card=30 Byte
s=240)
4 2 HASH JOIN (OUTER) (Cost=8851 Card=66372 Bytes=11216868
5 4 HASH JOIN (Cost=8696 Card=66372 Bytes=9225708)
6 5 TABLE ACCESS (FULL) OF 'PRODUTOS' (Cost=98 Card=19
01 Bytes=171090)
7 5 HASH JOIN (Cost=8584 Card=66387 Bytes=3252963)
8 7 VIEW OF 'index$_join$_005' (Cost=347 Card=13193
Bytes=171509)
9 8 HASH JOIN
10 9 HASH JOIN
11 10 INDEX (RANGE SCAN) OF 'NOTAS_ATIVA_IDX' (N
ON-UNIQUE) (Cost=140 Card=13193 Bytes=171509)
12 10 INDEX (RANGE SCAN) OF 'NOTAS_IMPRESSO_ROMA
NEIO' (NON-UNIQUE) (Cost=140 Card=13193 Bytes=171509)
13 9 INDEX (FAST FULL SCAN) OF 'NOTAS_PK' (UNIQUE
) (Cost=140 Card=13193 Bytes=171509)
14 7 TABLE ACCESS (FULL) OF 'NOTAS_ITENS' (Cost=8170
Card=265547 Bytes=9559692)
15 4 TABLE ACCESS (FULL) OF 'PERICULOSIDADE' (Cost=2 Card
=1 Bytes=30)
Estatística
0 recursive calls
0 db block gets
855476 consistent gets
83917 physical reads
0 redo size
1064 bytes sent via SQL*Net to client
368 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
Note that the cost for the HASH JOIN is high-- Is there anyway to get it lower ?
Note that Oracle performs FTS on NOTAS_ITENS table which is quite big for ue... I tryied a lot of hints but none of them avoid FTS ...
Any tips ?

Can Oracle make mistakes while making execution plan?

Env: Running Oracle DB 11g Rel 1.
Is it possible that oracle may use a different execution plan for the same query depending on the environment where its running due to any reason. I am running an oracle report 6i/10g which has started to take too long to run but at the same time runs better/faster while in sql*plus or toad. Report has nothing more than a query (like: no pl/sql, or triggers with sqls).
Is it also possible that depending on the different environment that runs the query or user profile, oracle might be using a different (may be bad) execution plan. Though at the same time database is same, no parameters are changed at run time explicitly by user or application. Base table of the query are all analyzed on regular basis.
Or, is it possible that at some point in time in the past, the same query had a bad plan and oracle kept using it from the cache (though I can't find any doc which would support this). I think that estimated plan might be bad based on past statistics but actual plan shouldn't be same bad as estimated. Does clearing the cache help?
Any insight or links to docs are appreciated.

ocp9i wrote:
Env: Running Oracle DB 11g Rel 1.
Is it possible that oracle may use a different execution plan for the same query depending on the environment where its running due to any reason. That is after all what cost based optimisation is.. taking the existing factors into consideration for determining the execution plans. Different factors may apply for future executions of that SQL - which could mean a different execution plan.
CBO does not mean that there will be a consistent-always-the-same execution plan for a SQL. It can and often will differ over time.
I am running an oracle report 6i/10g which has started to take too long to run but at the same time runs better/faster while in sql*plus or toad.You cannot evaluate performance using elapsed execution time - that is a flawed approach. The very same query can run a lot faster after the 1st execution as the 1st execution did expensive physical I/O from disk. Subsequent execution of that query will find the data in the buffer cache and instead of physical I/O, do cheaper logical I/O.
Also, reporting will typically include rendering. This is an added overhead that a plain SQL select in comparison will not have.
So you need to be careful in how you match the performance of a query like this. There's a lot more to it than meets the eye.
Or, is it possible that at some point in time in the past, the same query had a bad plan and oracle kept using it from the cache (though I can't find any doc which would support this). How do you know that this is a bad execution plan? How do you know that the report SQL uses a different execution plan than what your plain SQL select test does?
If the query is exactly the same (proper shared SQL), then there will be a single execution plan for that query. The 1st time that the query is hard parsed, this execution plan is created. Subsequent processes/sessions will use the very same execution plan (soft parsing) until that cursor is aged from the Shared Pool.
Thus if you are firing off an identical query via Reports and something like SQL*Plus.. chances are excellent that both is using the exact same execution plan.
Any insight or links to docs are appreciated.Suggest that you look at the Oracle Concepts guide. You'll find it via http://tahiti.oracle.com

Oracle 10g Diff in execution plan query with binding var Vs without

We recently did 10g upgrade. In 10g, execution plan differs for query with binding var(thru jdbc etc) Vs without it as given below. For query with binding var,
it chooses poor execution plan(no index is used, full scan is done etc). everything worked fine in 9i. To rectify the problem, we have to hint query with right index,join etc. but i dont like this solution.
I would rather prefer to correct database to choose right execution path instead of eacy query level. but not sure what causes the issue.
Does anybody came across this issue? if so, Please share your experiences. Thanks for the help. Do let me know if you need more info.
1. Query without binding bar:
select * from test where col1 = :1 and col2 = :2
1. Query without binding bar:
select * from test where col1 = 'foo' and col2= 'bar'

I am not an expert but in my humble opinion it is the developer's responsability to ensure the correct explain plan is used before deploying code to production, if the explain plan returned by the DB is bad, then the use of a hint is perfectly acceptable.
Check this out: http://lcgapp.cern.ch/project/CondDB/snapshot/performance.html
Excerpt:
Bind variable peeking. If an SQL query contains bind variables, the optimal execution plan may depend on the values of those variables. When the Oracle query optimizer chooses the execution plan for such a query, it may indeed look at the values of all bind variables involved: this is known as "bind variable peeking".
In summary, the execution plan used for a given SQL query cannot be predicted a priori because it depends on the presence and quality of statistics and on the values of bind variables used at the time the query was first executed (hard-parsed). As a consequence of this instability of execution plans, very different performances may be observed for the same SQL query. In COOL, this issue is addressed by adding Oracle hints to the queries, to make sure that the same (good) plan is used in all cases, even with unreliable statistics or unfavourable bind variables.
Edited by: Rodolfo Ferrari on Jun 3, 2009 9:40 PM

How can I get an execution plan for a Function in oracle 10g

Hi
I have:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
I would like to know if is possible to get an EXECUTION PLAN for a FUNCTION if so, how can I get it ?
Regards

You can query the AWR data if your interesting SQL consumes enough resources.
Here is a SQL*Plus script I call MostCPUIntensiveSQLDuringInterval.sql (nice name eh?)
You'll need to know the AWR snap_id numbers for the time period of interest, then run it like this to show the top 20 SQLs during the interval:
@MostCPUIntensiveSQLDuringInterval 20The script outputs a statement to run when you are interested in looking at the plan for an interesting looking statement.
-- MostCPUintesticeSQLDuringInterval: Report on the top n SQL statements during an AWR snapshot interval.
-- The top statements are ranked by CPU usage
col inst_no             format      999 heading 'RAC|Node'
col sql_id              format a16      heading 'SQL_ID'
col plan_hash_value     format 999999999999 heading 'Plan|hash_value'
col parsing_schema_name format a12      heading 'Parsing|Schema'
col module              format a10      heading 'Module'
col pct_of_total   format        999.99 heading '% Total'
col cpu_time       format   999,999,999 heading 'CPU     |Time (ms)'
col elapsed_time   format   999,999,999 heading 'Elapsed |Time (ms)'
col lios           format 9,999,999,999 heading 'Logical|Reads'
col pios           format   999,999,999 heading 'Physical|Reads'
col execs          format    99,999,999 heading 'Executions'
col fetches        format    99,999,999 heading 'Fetches'
col sorts          format       999,999 heading 'Sorts'
col parse_calls    format       999,999 heading 'Parse|Calls'
col rows_processed format   999,999,999 heading 'Rows|Processed'
col iowaits        format   999,999,999,999 heading 'iowaits'
set lines 195
set pages 75
PROMPT Top &&1 SQL statements during interval
SELECT diff.*
FROM (SELECT e.instance_number inst_no
            ,e.sql_id
            ,e.plan_hash_value
            ,e.parsing_schema_name
            ,substr(trim(e.module),1,10) module
            ,ratio_to_report(e.cpu_time_total - b.cpu_time_total) over (partition by 1) * 100 pct_of_total
            ,(e.cpu_time_total - b.cpu_time_total)/1000 cpu_time
            ,(e.elapsed_time_total - b.elapsed_time_total)/1000 elapsed_time
            ,e.buffer_gets_total - b.buffer_gets_total lios
            ,e.disk_reads_total - b.disk_reads_total pios
            ,e.executions_total - b.executions_total execs
            ,e.fetches_total - b.fetches_total fetches
            ,e.sorts_total - b.sorts_total sorts
            ,e.parse_calls_total - b.parse_calls_total parse_calls
            ,e.rows_processed_total - b.rows_processed_total rows_processed
--            ,e.iowait_total - b.iowait_total iowaits
--            ,e.plsexec_time_total - b.plsexec_time_total plsql_time
      FROM dba_hist_sqlstat b -- begining snap
          ,dba_hist_sqlstat e -- ending snap
      WHERE b.sql_id = e.sql_id
      AND   b.dbid   = e.dbid
      AND   b.instance_number = e.instance_number
      and   b.plan_hash_value = e.plan_hash_value
      AND   b.snap_id = &LowSnapID
      AND   e.snap_id = &HighSnapID
      ORDER BY e.cpu_time_total - b.cpu_time_total DESC
     ) diff
WHERE ROWNUM <=&&1
set define off
prompt to get the text of the SQL run the following:
prompt @id2sql &SQL_id
prompt .
prompt to obtain the execution plan for a session run the following:
prompt select * from table(DBMS_XPLAN.DISPLAY_AWR('&SQL_ID'));
prompt or
prompt select * from table(DBMS_XPLAN.DISPLAY_AWR('&SQL_ID',NULL,NULL,'ALL'));
prompt .
set define on
undefine LowSnapID
undefine HighSnapIDI guess you'll need the companion script id2sql.sql, so here it is:
set lines 190
set verify off
declare
   maxDisplayLine NUMBER := 150; --max linesize to display the SQL
   WorkingLine     VARCHAR2(32000);
   CurrentLine     VARCHAR2(64);
   LineBreak       NUMBER;
   cursor ddl_cur is
      select sql_id
        ,sql_text
      from v$sqltext_with_newlines
      where sql_id='&1'
      order by piece
   ddlRec ddl_cur%ROWTYPE;
begin
   WorkingLine :='.';
   OPEN ddl_cur;
   LOOP
      FETCH ddl_cur INTO ddlRec;
      EXIT WHEN ddl_cur%NOTFOUND;
      IF ddl_cur%ROWCOUNT = 1 THEN
         dbms_output.put_line('.');
         dbms_output.put_line('   sql_id: '||ddlRec.sql_id);
         dbms_output.put_line('.');
         dbms_output.put_line('.');
         dbms_output.put_line('SQL Text');
         dbms_output.put_line('----------------------------------------------------------------');
      END IF;
      CurrentLine := ddlRec.sql_text;
      WHILE LENGTH(CurrentLine) > 1 LOOP
         IF INSTR(CurrentLine,CHR(10)) > 0 THEN -- if the current line has an embeded newline
            WorkingLine := WorkingLine||SUBSTR(CurrentLine,1,INSTR(CurrentLine,CHR(10))-1); -- append up to new line
            CurrentLine := SUBSTR(CurrentLine,INSTR(CurrentLine,CHR(10))+1); -- strip off up through new line character
            dbms_output.put_line(WorkingLine); -- print the WorkingLine
            WorkingLine :='';                   -- reset the working line
         ELSE
            WorkingLine := WorkingLine||CurrentLine; -- append the current line
            CurrentLine :=''; -- the rest of the line has been processed
            IF LENGTH(WorkingLine) > maxDisplayLine THEN   -- the line is morethan the display limit
               LineBreak := instr(substr(WorkingLine,1,maxDisplayLine),' ',-1); --find the last space before the display limit
               IF LineBreak = 0 THEN -- there is no space, so look for a comma instead
                  LineBreak := substr(WorkingLine,instr(substr(WorkingLine,1,maxDisplayLine),',',-1));
               END IF;
               IF LineBreak = 0 THEN -- no space or comma, so force the line break at maxDisplayLine
                 LineBreak := maxDisplayLine;
               END IF;
               dbms_output.put_line(substr(WorkingLine,1,LineBreak));
               WorkingLine:=substr(WorkingLine,LineBreak);
            END IF;
         END IF;
      END LOOP;
      --dbms_output.put(ddlRec.sql_text);
   END LOOP;
   dbms_output.put_line(WorkingLine);
   dbms_output.put_line('----------------------------------------------------------------');
   CLOSE ddl_cur;
END;
/

Bytes in execution plans shows high value in oracle 11.2.0.3 than 10.2.0.4

Hi,
I copied data from 10.2.0.4 database to 11.2.0.3, gathered stats similar to 10.2.0.4 database and running same query against both database.
Bytes shows 257 in 10.2.0.4 and 2263 in 11.2.0.3. Both plans are using index access. Can someone help me why I see this discrepancy?
Thank You
Sarayu
select * from TABLE_1 where column_1 = 12345
Oracle 10.2.0.4
Execution Plan
| Id | Operation                   | Name          | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT            |               |     1 |   257 |     3   (0)|
|   1 | TABLE ACCESS BY INDEX ROWID| TABLE_1       |     1 |   257 |     3   (0)|
|* 2 |   INDEX UNIQUE SCAN         | IDX_TABLE_1   |     1 |       |     2   (0)|
----------------------------------------------------------------------------------Oracle 11.2.0.3
| Id | Operation                   | Name          | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |               |     1 | 2263 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| TABLE_1       |     1 | 2263 |     3   (0)| 00:00:01 |
|* 2 |   INDEX UNIQUE SCAN         | IDX_TABLE_1   |     1 |       |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------Edited by: user13312943 on Oct 15, 2012 8:35 AM

That would seem to imply that the 11.2.0.3 database expects one row of the table to occupy 2263 bytes while the 10.2.0.4 database expects one row of the table to occupy 257 bytes. Which estimate is closer to the correct value? How much space does the table occupy in each database? How many rows are in each database?
Justin

Very different execution plan in Oracle 10g vs. 9i

Good afternoon,
A few days ago I migrated an Oracle database 9i to 10g.
Right now I have an exact copy of the 9i instance running on another machine.
I noticed that the time for some queries take much more. For example, when comparing the execution plan for this query on the instance with Oracle 9i and Oracle 10g instance, I see that the cost in 10g is 94981765382, while in 9i is 120106.
Any idea what might be happening?
Execution Plan Oracle 9: http://blog.davidlozanolucas.com/uploads/execution_plan_Oracle_9i.jpg
Execution Plan Oracle 10g: http://blog.davidlozanolucas.com/uploads/execution_plan_Oracle_10g.jpg
Edited by: david_lozano_lucas on Dec 14, 2011 4:54 PM

Sorry,
Here are the details.
For Oracle 9i:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 16M| 3675M| | 120K (0)| | | | | |
|* 1 | FILTER | | | | | | | | | | |
|* 2 | HASH JOIN | | 16M| 3675M| | 120K (0)| | | 03,09 | P->S | QC (RAND) |
| 3 | TABLE ACCESS FULL | ORG_LOC_DM | 2261 | 13566 | | 8 (0)| | | 03,01 | S->P | HASH |
|* 4 | HASH JOIN OUTER | | 16M| 3582M| 1023M| 120K (0)| | | 03,08 | P->P | HASH |
|* 5 | HASH JOIN OUTER | | 16M| 2783M| 1041M| 102K (0)| | | 03,08 | PCWP | |
|* 6 | HASH JOIN OUTER | | 16M| 2521M| 715M| 69515 (0)| | | 03,08 | PCWP | |
| 7 | PARTITION RANGE ALL | | | | | | 1 | 14 | 03,08 | PCWP | |
| 8 | TABLE ACCESS FULL | SURT_SKU_LD_DM | 16M| 1922M| | 60988 (0)| 1 | 14 | 03,04 | P->P | HASH |
| 9 | VIEW | | 909K| 33M| | | | | 03,05 | P->P | HASH |
| 10 | SORT GROUP BY | | 909K| 19M| 62M| 1553 (0)| | | 03,05 | PCWP | |
|* 11 | HASH JOIN | | 909K| 19M| | 164 (0)| | | 03,05 | PCWP | |
|* 12 | TABLE ACCESS FULL| ORG_LOC_DM | 1131 | 6786 | | 8 (0)| | | 03,00 | S->P | HASH |
|* 13 | TABLE ACCESS FULL| INV_MOVE_SKU_LCM_DM | 909K| 13M| | 154 (0)| 60 | 60 | 03,02 | P->P | HASH |
|* 14 | TABLE ACCESS FULL | SURT_SKU_LCM_DM | 16M| 260M| | 6457 (0)| 59 | 59 | 03,06 | P->P | HASH |
| 15 | VIEW | | 1795K| 89M| | | | | 03,07 | P->P | HASH |
| 16 | SORT GROUP BY | | 1795K| 63M| 233M| 4565 (0)| | | 03,07 | PCWP | |
|* 17 | TABLE ACCESS FULL | SLS_SKU_LCM_DM | 1795K| 63M| | 599 (0)| 60 | 60 | 03,03 | P->P | HASH |
| 18 | NESTED LOOPS | | 1 | 16 | | 7 (15)| | | | | |
| 19 | TABLE ACCESS FULL | MAINT_LOAD_DT | 1 | 8 | | 1 (0)| | | | | |
|* 20 | INDEX RANGE SCAN | DAY_IDNT_I1 | 1 | 8 | | 1 (0)| | | | | |
Predicate Information (identified by operation id):
1 - filter("SYS_ALIAS_1"."DAY_IDNT"= (SELECT /*+ */ :B1 FROM "RDW91_DM"."MAINT_LOAD_DT" "Y","RDW91_DM"."TIME_DAY_DM" "X" WHERE
"X"."DAY_DT"="Y"."CURR_LOAD_DT"))
2 - access("SYS_ALIAS_1"."LOC_KEY"="G"."LOC_KEY")
4 - access("SYS_ALIAS_1"."LOC_KEY"="I"."LOC_KEY"(+) AND "SYS_ALIAS_1"."SKU_KEY"="I"."SKU_KEY"(+))
5 - access("SYS_ALIAS_1"."LOC_KEY"="B"."LOC_KEY"(+) AND "SYS_ALIAS_1"."SKU_KEY"="B"."SKU_KEY"(+))
6 - access("SYS_ALIAS_1"."LOC_KEY"="J"."LOC_KEY"(+) AND "SYS_ALIAS_1"."SKU_KEY"="J"."SKU_KEY"(+))
11 - access("A"."LOC_KEY"="B"."LOC_KEY")
12 - filter("B"."LOC_TYPE_CDE"='W')
13 - filter("A"."CMTH_IDNT"=201112)
14 - filter("B"."CMTH_IDNT"(+)=201111)
17 - filter("SLS_SKU_LCM_DM"."CMTH_IDNT"=201112)
20 - access("X"."DAY_DT"="Y"."CURR_LOAD_DT")
For 10g:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 16M| 3685M| | 94G| | | | | |
| 1 | FILTER | | | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10008 | 16M| 3685M| | 94G| | | Q1,08 | P->S | QC (RAND) |
| 4 | BUFFER SORT | | 16M| 3685M| | | | | Q1,08 | PCWP | |
| 5 | NESTED LOOPS OUTER | | 16M| 3685M| | 94G| | | Q1,08 | PCWP | |
| 6 | HASH JOIN | | 16M| 3424M| | 201K| | | Q1,08 | PCWP | |
| 7 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 8 | PX RECEIVE | | 2261 | 13566 | | 8 | | | Q1,08 | PCWP | |
| 9 | PX SEND HASH | :TQ10001 | 2261 | 13566 | | 8 | | | | S->P | HASH |
| 10 | TABLE ACCESS FULL | ORG_LOC_DM | 2261 | 13566 | | 8 | | | | | |
| 11 | PX RECEIVE | | 16M| 3332M| | 201K| | | Q1,08 | PCWP | |
| 12 | PX SEND HASH | :TQ10007 | 16M| 3332M| | 201K| | | Q1,07 | P->P | HASH |
| 13 | HASH JOIN OUTER BUFFERED | | 16M| 3332M| 982M| 201K| | | Q1,07 | PCWP | |
| 14 | HASH JOIN OUTER | | 16M| 2733M| 735M| 127K| | | Q1,07 | PCWP | |
| 15 | PX RECEIVE | | 16M| 1934M| | 75785 | | | Q1,07 | PCWP | |
| 16 | PX SEND HASH | :TQ10004 | 16M| 1934M| | 75785 | | | Q1,04 | P->P | HASH |
| 17 | PX BLOCK ITERATOR | | 16M| 1934M| | 75785 | 1 | 14 | Q1,04 | PCWC | |
| 18 | TABLE ACCESS FULL | SURT_SKU_LD_DM | 16M| 1934M| | 75785 | 1 | 14 | Q1,04 | PCWP | |
| 19 | PX RECEIVE | | 1450K| 71M| | 3892 | | | Q1,07 | PCWP | |
| 20 | PX SEND HASH | :TQ10005 | 1450K| 71M| | 3892 | | | Q1,05 | P->P | HASH |
| 21 | VIEW | | 1450K| 71M| | 3892 | | | Q1,05 | PCWP | |
| 22 | SORT GROUP BY | | 1450K| 53M| 188M| 3892 | | | Q1,05 | PCWP | |
| 23 | PX RECEIVE | | 1450K| 53M| | 562 | | | Q1,05 | PCWP | |
| 24 | PX SEND HASH | :TQ10002 | 1450K| 53M| | 562 | | | Q1,02 | P->P | HASH |
| 25 | PX BLOCK ITERATOR | | 1450K| 53M| | 562 | 60 | 60 | Q1,02 | PCWC | |
| 26 | MAT_VIEW ACCESS FULL| SLS_SKU_LCM_DM | 1450K| 53M| | 562 | 60 | 60 | Q1,02 | PCWP | |
| 27 | PX RECEIVE | | 652K| 24M| | 1150 | | | Q1,07 | PCWP | |
| 28 | PX SEND HASH | :TQ10006 | 652K| 24M| | 1150 | | | Q1,06 | P->P | HASH |
| 29 | VIEW | | 652K| 24M| | 1150 | | | Q1,06 | PCWP | |
| 30 | SORT GROUP BY | | 652K| 14M| | 1150 | | | Q1,06 | PCWP | |
| 31 | HASH JOIN | | 652K| 14M| | 128 | | | Q1,06 | PCWP | |
| 32 | BUFFER SORT | | | | | | | | Q1,06 | PCWC | |
| 33 | PX RECEIVE | | 1131 | 6786 | | 8 | | | Q1,06 | PCWP | |
| 34 | PX SEND HASH | :TQ10000 | 1131 | 6786 | | 8 | | | | S->P | HASH |
| 35 | TABLE ACCESS FULL | ORG_LOC_DM | 1131 | 6786 | | 8 | | | | | |
| 36 | PX RECEIVE | | 652K| 10M| | 118 | | | Q1,06 | PCWP | |
| 37 | PX SEND HASH | :TQ10003 | 652K| 10M| | 118 | | | Q1,03 | P->P | HASH |
| 38 | PX BLOCK ITERATOR | | 652K| 10M| | 118 | 60 | 60 | Q1,03 | PCWC | |
| 39 | MAT_VIEW ACCESS FULL| INV_MOVE_SKU_LCM_DM | 652K| 10M| | 118 | 60 | 60 | Q1,03 | PCWP | |
| 40 | PARTITION RANGE SINGLE | | 1 | 17 | | 8609 | 59 | 59 | Q1,08 | PCWP | |
| 41 | TABLE ACCESS FULL | SURT_SKU_LCM_DM | 1 | 17 | | 8609 | 59 | 59 | Q1,08 | PCWP | |
| 42 | NESTED LOOPS | | 1 | 16 | | 6 | | | | | |
| 43 | TABLE ACCESS FULL | MAINT_LOAD_DT | 1 | 8 | | 1 | | | | | |
| 44 | INDEX RANGE SCAN | DAY_IDNT_I1 | 1 | 8 | | 5 | | | | | |
Note
- 'PLAN_TABLE' is old version
- cpu costing is off (consider enabling it)

Oracle 11g R2 consuming 100% CPU on execution plans

Hi Friends
I just installed oracle 11.2.0.1.0 on Windows 2008 Server R2.
I got 4GB of RAM = 2536MB for SGA and 600M for PGA
I'm running a processes that is consuming 100% of CPU ant its showed on execution plan of every statement this utilization.
I have worked with disk_asynch_io parameter to FALSE and had no improvement on performance.
Reading a doc relating to a bug I set up the dbwr_io_slaves to 4 but no changes.
Now I'm stuck on asynch descriptor resize wait event for more than 4 hours.
Any ideias os tips or experience about this issue?
Tks a lot

Well, Tks for your help guys,
The problem was solved "almost" at all by disabling MEMORY_TARGET and SGA_TARGET and setting up all the memory parameters manually.
This has eliminated the event "asynch description resize" and the overall performance of the DB has increased. I was able then, to complete my operation.
I believe its a Windows bug or a poor design or configuration of mine. But at this time we are able to run the system well and fast enough.
Tks a lot

Oracle Execution Plan

Hi!
How come the Oracle execution plan doesn't show inner select statements?
ie:
select s.id, (select name from anothertable where id = s.id)
from subs s
where s.createdate < '20-March-2005'

Which version of database are you running?
When you run the following query on SCOTT schema, what type of plan do you get?
SQL> set autotrace traceonly explain
SQL> select d.*, (select sum(sal) from emp e where e.deptno = d.deptno) from dept d ;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=327 Bytes=981
          0)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (BY INDEX ROWID) OF 'EMP' (Cost=2 Card=3333
          3 Bytes=166665)
   3    2       INDEX (RANGE SCAN) OF 'IDX_EMP_DEPTNO' (NON-UNIQUE) (C
          ost=1 Card=33333)
   4    0   TABLE ACCESS (FULL) OF 'DEPT' (Cost=2 Card=327 Bytes=9810)
SQL> disconnect
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production
SQL>

Explain SQL Query execution plan: Oracle

Dear Masters,
Kindly help me to understand execution plan for an SQL statement. I have following SQL execution plan for a query in system. How should I interpret it. I thank You in advace for your guidance.
SELECT STATEMENT ( Estimated Costs = 1.372.413 , Estimated #Rows = 0 )
       5 NESTED LOOPS
         ( Estim. Costs = 1.372.413 , Estim. #Rows = 3.125 )
         Estim. CPU-Costs = 55.798.978.498 Estim. IO-Costs = 1.366.482
           2 TABLE ACCESS BY INDEX ROWID MSEG
             ( Estim. Costs = 1.326.343 , Estim. #Rows = 76.717 )
             Estim. CPU-Costs = 55.429.596.575 Estim. IO-Costs = 1.320.451
             Filter Predicates
               1 INDEX RANGE SCAN MSEG~R
                 ( Estim. Costs = 89.322 , Estim. #Rows = 60.069.500 )
                 Search Columns: 1
                 Estim. CPU-Costs = 2.946.739.229 Estim. IO-Costs = 89.009
                 Access Predicates
           4 TABLE ACCESS BY INDEX ROWID MKPF
             ( Estim. Costs = 1 , Estim. #Rows = 1 )
             Estim. CPU-Costs = 4.815 Estim. IO-Costs = 1
             Filter Predicates
               3 INDEX UNIQUE SCAN MKPF~0
                 Search Columns: 3
                 Estim. CPU-Costs = 3.229 Estim. IO-Costs = 0
                 Access Predicates

Hi Panjak,
Yeahh, there's a huge unperformatic SQL statment, what I can see from this acces plan is:
1 DBO decided to start the query on index R on MSEG, using only part of the index (only one column) with no good uniqueness, accessing disk IO-Costs for this (60mi records), and expecting many interactions (loops) in memory to filter, see CPU-Costs.
So with the parameters you gave to SQL, they start in a very bad way.
2 After that program will access the MSEG commanded by what was found on First step, also with a huge loading from DB and filtering (another where criteria on MSEG fields, not found on index R), reducing the result set to 76.717 rows.
3/4 With this, program goes direct to primary key index on MKPF with direct access (optimized access) and follow to access database table MKPF.
5 At last will "loop" the result sets from MSEG and MKPF, mixing the tuplas generating the final result set.
Do you want to share your SQL, the parameters you are sending and code which generate it with us?
Regards, Fernando Da Ró

Query text and execution plan collection from prod DB Oracle 11g

Hi all,
I would like to collect query text, query execution plan and other statistics for all queries (mainly select queries) from production database.
I am doing this by using OEM by click on Top activity link under performance tab but this gives top sql which is recent.
This approach is helpful only when I need to debug recent queries only. If I need to know slow running queries and their execution plan at the end of day or sometime later then it’s not helpful for me.
Anybody who has some better idea to do this will really be helpful.

we did followings:
1.Used awrextr.sql to export dmp file from production database.(imported snpashot id from 331 to 560)
2.transfer file to test database.
3.Used awrload.sql to import it in test database.
but when we used OEM and went to Automatic Workload Repository link under Server tab
its not showing snapshots of production database (which we have imported in test database )
and showing only snapshot which was already there in test database.
We did not find any error in import/export.
do we need to perform something else also to display snapshots of production database in test database.

How to force a execution plan

Hello ,
I am working on oracle 11g R2 on AIX.
One query was performing good around 20 sec. but suddenly it took more then 15 min.
We check that the sql executoin plan changes , it showing that order of operation changed like order of using indexes is different.
Now the new plan is not good.
we want to force the old plan of sql to use in future.
I read about sql plan management , it shows a manual method to create baseline and evolve the all plan. In one texample we found that
first query execution plan was created using with out index and then with index So, second plan was good and accepted.
But in this case we do not need to change any thing ,query is performing bad may be becasue changes order of operation ..
One other way to use hint , but for this we need to change sqls , which is not possiable in production now.
The issue is
For this we need to run the sql again and oracle may not create plan like old one.So we will not be having old good plan to accept.
All 2 execution plan are already in cache .
I am looking for a way using that we can set sql plan hash value ( of good plan) or any other id of that sql plan to force to use that plan only.
any idea how to do it ..

Stored Outlines are deprecated.
OP:
To fix a specific plan you have two choices:
1. SQL Plan Baselines - assuming the "good" plan is in AWR still then the steps are along the lines of load old plan from AWR into sql tuning set using DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY and DBMS_SQLTUNE.LOAD_SQLSET then load plans from sqlset into sql plan baseline using DBMS_SPM.LOAD_PLANS_FROM_SQLSET.
2. Using SQL Profiles to fix the outline hints - so similar to a stored outline but using the sql profile mechanism - using the coe_xfr_sql_profile.sql script, part of an approach in Oracle support doc id 215187.1
But +1 for Nikolay's recommendation of understanding whether there is a root cause to this problem instability (plan instability being "normal", but flip flopping between "good" and "bad" being a problem). Cardinality feedback is an obvious possible influence, different peeked binds another, stat changes, etc.

Execution plan caching in oracle

Similar Messages

Maybe you are looking for