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>

Similar Messages

  • 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

  • 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

  • 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

  • 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.

  • Force statement to use a given rule or execution plan

    Hi!
    We have a statement that in our production system takes 6-7 seconds to complete. The statement comes from our enterprise application's core code and we are not able to change the statement.
    When using a RULE-hint (SELECT /*+RULE*/ 0 pay_rec...........) for this statement, the execution time is down to 500 milliseconds.
    My question is: Is there any way to pin a execution plan to a given statement. I have started reading about outlines, which seems promising. However, the statement is not using bind-variables, and since this is core code in an enterprise application I cannot change that either. Is it possible to use outlines with such a statement?
    Additional information:
    When I remove all statistics for the involved tables, the query blows away in 500 ms.
    The table tran_info_types has 61 rows and is a stable table with few updates
    The table ab_tran_info has 1 717 439 records and is 62 MB in size.
    The table query_result has 777 015 records and is 216 MB in size. This table is constantly updated/insterted/deleted.
    The query below return 0 records as there is no hits in the table query_result.
    This is the statement:
    SELECT  /*+ALL_ROWS*/
           0 pay_rec, abi.tran_num, abi.type_id, abi.VALUE
      FROM ab_tran_info abi,
           tran_info_types ti,
           query_result qr1,
           query_result qr2
    WHERE abi.tran_num = qr1.query_result
       AND abi.type_id = qr2.query_result
       AND abi.type_id = ti.type_id
       AND ti.ins_or_tran = 0
       AND qr1.unique_id = 5334549
       AND qr2.unique_id = 5334550
    UNION ALL
    SELECT 1 pay_rec, abi.tran_num, abi.type_id, abi.VALUE
      FROM ab_tran_info abi,
           tran_info_types ti,
           query_result qr1,
           query_result qr2
    WHERE abi.tran_num = qr1.query_result
       AND abi.type_id = qr2.query_result
       AND abi.type_id = ti.type_id
       AND ti.ins_or_tran = 0
       AND qr1.unique_id = 5334551
       AND qr2.unique_id = 5334552;Here is the explain plan with statistics:
    Plan
    SELECT STATEMENT  HINT: ALL_ROWSCost: 900  Bytes: 82  Cardinality: 2                           
         15 UNION-ALL                      
              7 NESTED LOOPS  Cost: 450  Bytes: 41  Cardinality: 1                 
                   5 NESTED LOOPS  Cost: 449  Bytes: 1,787,940  Cardinality: 59,598            
                        3 NESTED LOOPS  Cost: 448  Bytes: 19,514,824  Cardinality: 1,027,096       
                             1 INDEX RANGE SCAN UNIQUE TRADEDB.TIT_DANIEL_2 Search Columns: 1  Cost: 1  Bytes: 155  Cardinality: 31 
                             2 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_7 Search Columns: 1  Cost: 48  Bytes: 471,450  Cardinality: 33,675 
                        4 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1       
                   6 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1            
              14 NESTED LOOPS  Cost: 450  Bytes: 41  Cardinality: 1                 
                   12 NESTED LOOPS  Cost: 449  Bytes: 1,787,940  Cardinality: 59,598            
                        10 NESTED LOOPS  Cost: 448  Bytes: 19,514,824  Cardinality: 1,027,096       
                             8 INDEX RANGE SCAN UNIQUE TRADEDB.TIT_DANIEL_2 Search Columns: 1  Cost: 1  Bytes: 155  Cardinality: 31 
                             9 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_7 Search Columns: 1  Cost: 48  Bytes: 471,450  Cardinality: 33,675 
                        11 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1       
                   13 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1            Here is the execution plan when I have removed all statistics (exec DBMS_STATS.DELETE_TABLE_STATS(.........,..........); )
    Plan
    SELECT STATEMENT  HINT: ALL_ROWSCost: 12  Bytes: 3,728  Cardinality: 16                           
         15 UNION-ALL                      
              7 NESTED LOOPS  Cost: 6  Bytes: 1,864  Cardinality: 8                 
                   5 NESTED LOOPS  Cost: 6  Bytes: 45,540  Cardinality: 220            
                        3 NESTED LOOPS  Cost: 6  Bytes: 1,145,187  Cardinality: 6,327       
                             1 TABLE ACCESS FULL TRADEDB.TRAN_INFO_TYPES Cost: 2  Bytes: 104  Cardinality: 4 
                             2 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_6 Search Columns: 1  Cost: 1  Bytes: 239,785  Cardinality: 1,547 
                        4 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1       
                   6 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1            
              14 NESTED LOOPS  Cost: 6  Bytes: 1,864  Cardinality: 8                 
                   12 NESTED LOOPS  Cost: 6  Bytes: 45,540  Cardinality: 220            
                        10 NESTED LOOPS  Cost: 6  Bytes: 1,145,187  Cardinality: 6,327       
                             8 TABLE ACCESS FULL TRADEDB.TRAN_INFO_TYPES Cost: 2  Bytes: 104  Cardinality: 4 
                             9 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_6 Search Columns: 1  Cost: 1  Bytes: 239,785  Cardinality: 1,547 
                        11 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1       
                   13 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1            Our Oracle 9.2 database is set up with ALL_ROWS.
    Outlines: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/outlines.htm#13091
    Cursor sharing: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3696883368520

    Hi!
    We are on Oracle 9iR2, running on 64-bit Linux.
    We are going to upgrade to Oracle 10gR2 in some months. Oracle 11g is not an option for us as our application is not certified by our vendor to run on that version.
    However, our performance problems are urgent so we are looking for a solution before we upgrade as we are not able to upgrade before we have done extensive testing which takes 2-3 months.
    We have more problem sql's than the one shown in this post. I am using the above SQL as a sample as I think we can solve many other slow running SQL's if we solve this one.
    Is the SQL Plan management an option on Oracle 9i and/or Oracle 10g?

  • Execution plan with Concatenation

    Hi All,
    Could anyone help in finding why concatenation is being used by optimizer and how can i avoid it.
    Oracle Version : 10.2.0.4
    select * from
                               select distinct EntityType, EntityID, DateModified, DateCreated, IsDeleted
                               from ife.EntityIDs i
                               join (select orgid from equifaxnormalize.org_relationships where orgid is not null and related_orgid is not null
                                  and ((Date_Modified >= to_date('2011-06-12 14:00:00','yyyy-mm-dd hh24:mi:ss') and Date_Modified < to_date('2011-06-13 14:00:00','yyyy-mm-dd hh24:mi:ss'))
                                        OR (Date_Created >= to_date('2011-06-12 14:00:00','yyyy-mm-dd hh24:mi:ss') and Date_Created < to_date('2011-06-13 14:00:00','yyyy-mm-dd hh24:mi:ss'))
                     ) r on(r.orgid= i.entityid)
                               where EntityType = 1
                and ((DateModified >= to_date('2011-06-12 14:00:00','yyyy-mm-dd hh24:mi:ss') and DateModified < to_date('2011-06-13 14:00:00','yyyy-mm-dd hh24:mi:ss'))
                                              OR (DateCreated >= to_date('2011-06-12 14:00:00','yyyy-mm-dd hh24:mi:ss') and DateCreated < to_date('2011-06-13 14:00:00','yyyy-mm-dd hh24:mi:ss'))
                               and ( IsDeleted = 0)
                               and IsDistributable = 1
                               and EntityID >= 0
                               order by EntityID
                               --order by NLSSORT(EntityID,'NLS_SORT=BINARY')
                             where rownum <= 10;
    Execution Plan
    Plan hash value: 227906424
    | Id  | Operation                                 | Name                          | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT                          |                               |    10 |   570 |    39   (6)| 00:00:01 |       |       |
    |*  1 |  COUNT STOPKEY                            |                               |       |       |            |          |       |       |
    |   2 |   VIEW                                    |                               |    56 |  3192 |    39   (6)| 00:00:01 |       |       |
    |*  3 |    SORT ORDER BY STOPKEY                  |                               |    56 |  3416 |    39   (6)| 00:00:01 |       |       |
    |   4 |     HASH UNIQUE                           |                               |    56 |  3416 |    38   (3)| 00:00:01 |       |       |
    |   5 |      CONCATENATION                        |                               |       |       |            |          |       |       |
    |*  6 |       TABLE ACCESS BY INDEX ROWID         | ORG_RELATIONSHIPS             |     1 |    29 |     1   (0)| 00:00:01 |       |       |
    |   7 |        NESTED LOOPS                       |                               |    27 |  1647 |    17   (0)| 00:00:01 |       |       |
    |   8 |         TABLE ACCESS BY GLOBAL INDEX ROWID| ENTITYIDS                     |    27 |   864 |     4   (0)| 00:00:01 | ROWID | ROWID |
    |*  9 |          INDEX RANGE SCAN                 | UX_TYPE_MOD_DIST_DEL_ENTITYID |    27 |       |     2   (0)| 00:00:01 |       |       |
    |* 10 |         INDEX RANGE SCAN                  | IX_EFX_ORGRELATION_ORGID      |     1 |       |     1   (0)| 00:00:01 |       |       |
    |* 11 |       TABLE ACCESS BY INDEX ROWID         | ORG_RELATIONSHIPS             |     1 |    29 |     1   (0)| 00:00:01 |       |       |
    |  12 |        NESTED LOOPS                       |                               |    29 |  1769 |    20   (0)| 00:00:01 |       |       |
    |  13 |         PARTITION RANGE ALL               |                               |    29 |   928 |     5   (0)| 00:00:01 |     1 |     3 |
    |* 14 |          TABLE ACCESS BY LOCAL INDEX ROWID| ENTITYIDS                     |    29 |   928 |     5   (0)| 00:00:01 |     1 |     3 |
    |* 15 |           INDEX RANGE SCAN                | IDX_ENTITYIDS_ETYPE_DC        |    29 |       |     4   (0)| 00:00:01 |     1 |     3 |
    |* 16 |         INDEX RANGE SCAN                  | IX_EFX_ORGRELATION_ORGID      |     1 |       |     1   (0)| 00:00:01 |       |       |
    Predicate Information (identified by operation id):
       1 - filter(ROWNUM<=10)
       3 - filter(ROWNUM<=10)
       6 - filter(("DATE_MODIFIED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "DATE_MODIFIED"<TO_DATE(' 2011-06-13
                  14:00:00', 'syyyy-mm-dd hh24:mi:ss') OR "DATE_CREATED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "DATE_CREATED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss')) AND "RELATED_ORGID" IS NOT NULL)
       9 - access("I"."ENTITYTYPE"=1 AND "I"."DATEMODIFIED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "I"."ISDISTRIBUTABLE"=1 AND "I"."ISDELETED"=0 AND "I"."ENTITYID">=0 AND "I"."DATEMODIFIED"<=TO_DATE(' 2011-06-13 14:00:00',
                  'syyyy-mm-dd hh24:mi:ss'))
           filter("I"."ISDISTRIBUTABLE"=1 AND "I"."ISDELETED"=0 AND "I"."ENTITYID">=0)
      10 - access("ORGID"="I"."ENTITYID")
           filter("ORGID" IS NOT NULL AND "ORGID">=0)
      11 - filter(("DATE_MODIFIED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "DATE_MODIFIED"<TO_DATE(' 2011-06-13
                  14:00:00', 'syyyy-mm-dd hh24:mi:ss') OR "DATE_CREATED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "DATE_CREATED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss')) AND "RELATED_ORGID" IS NOT NULL)
      14 - filter("I"."ISDISTRIBUTABLE"=1 AND "I"."ISDELETED"=0 AND (LNNVL("I"."DATEMODIFIED">=TO_DATE(' 2011-06-12 14:00:00',
                  'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("I"."DATEMODIFIED"<=TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND
                  "I"."ENTITYID">=0)
      15 - access("I"."ENTITYTYPE"=1 AND "I"."DATECREATED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "I"."DATECREATED"<=TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss'))
      16 - access("ORGID"="I"."ENTITYID")
           filter("ORGID" IS NOT NULL AND "ORGID">=0)ife.entityids table has been range - partitioned on data_provider column.
    Is there any better way to rewrite this sql OR is there any way to eliminate concatenation ?
    Thanks

    We cant use data_provider in the given query. We need to pull data irrespective of data_provider and it should be based on ENTITYID.
    Yes table has only three partitions...
    Not sure issue is due to concatenation....but we are in process to create desired indexes which will help for this sql.
    In development we have created multicolumn index and below is the execution plan.....Also in development it takes just 4-5 seconds to execute. But in production it takes more than 8-9 minutes.
    Below is the execution plan from Dev which seems to perform fast:
    Execution Plan
    Plan hash value: 3121857971
    | Id  | Operation                                 | Name                          | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT                          |                               |     1 |    57 |   353   (1)| 00:00:05 |       |       |
    |*  1 |  COUNT STOPKEY                            |                               |       |       |            |          |       |       |
    |   2 |   VIEW                                    |                               |     1 |    57 |   353   (1)| 00:00:05 |       |       |
    |*  3 |    SORT ORDER BY STOPKEY                  |                               |     1 |    58 |   353   (1)| 00:00:05 |       |       |
    |   4 |     HASH UNIQUE                           |                               |     1 |    58 |   352   (1)| 00:00:05 |       |       |
    |   5 |      CONCATENATION                        |                               |       |       |            |          |       |       |
    |*  6 |       TABLE ACCESS BY INDEX ROWID         | ORG_RELATIONSHIPS             |     1 |    26 |     3   (0)| 00:00:01 |       |       |
    |   7 |        NESTED LOOPS                       |                               |     1 |    58 |   170   (1)| 00:00:03 |       |       |
    |   8 |         PARTITION RANGE ALL               |                               |    56 |  1792 |    16   (0)| 00:00:01 |     1 |     3 |
    |*  9 |          TABLE ACCESS BY LOCAL INDEX ROWID| ENTITYIDS                     |    56 |  1792 |    16   (0)| 00:00:01 |     1 |     3 |
    |* 10 |           INDEX RANGE SCAN                | IDX_ENTITYIDS_ETYPE_DC        |    56 |       |     7   (0)| 00:00:01 |     1 |     3 |
    |* 11 |         INDEX RANGE SCAN                  | EFX_ORGID                     |     2 |       |     2   (0)| 00:00:01 |       |       |
    |* 12 |       TABLE ACCESS BY INDEX ROWID         | ORG_RELATIONSHIPS             |     1 |    26 |     3   (0)| 00:00:01 |       |       |
    |  13 |        NESTED LOOPS                       |                               |     1 |    58 |   181   (0)| 00:00:03 |       |       |
    |  14 |         PARTITION RANGE ALL               |                               |    57 |  1824 |    10   (0)| 00:00:01 |     1 |     3 |
    |* 15 |          INDEX RANGE SCAN                 | UX_TYPE_MOD_DIST_DEL_ENTITYID |    57 |  1824 |    10   (0)| 00:00:01 |     1 |     3 |
    |* 16 |         INDEX RANGE SCAN                  | EFX_ORGID                     |     2 |       |     2   (0)| 00:00:01 |       |       |
    Predicate Information (identified by operation id):
       1 - filter(ROWNUM<=10)
       3 - filter(ROWNUM<=10)
       6 - filter("RELATED_ORGID" IS NOT NULL AND ("DATE_CREATED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "DATE_CREATED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss') OR "DATE_MODIFIED">=TO_DATE(' 2011-06-12 14:00:00',
                  'syyyy-mm-dd hh24:mi:ss') AND "DATE_MODIFIED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss')))
       9 - filter("I"."ISDISTRIBUTABLE"=1 AND "I"."ISDELETED"=0 AND "I"."ENTITYID">=0)
      10 - access("I"."ENTITYTYPE"=1 AND "I"."DATECREATED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "I"."DATECREATED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss'))
      11 - access("ORGID"="I"."ENTITYID")
           filter("ORGID" IS NOT NULL AND "ORGID">=0)
      12 - filter("RELATED_ORGID" IS NOT NULL AND ("DATE_CREATED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "DATE_CREATED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss') OR "DATE_MODIFIED">=TO_DATE(' 2011-06-12 14:00:00',
                  'syyyy-mm-dd hh24:mi:ss') AND "DATE_MODIFIED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss')))
      15 - access("I"."ENTITYTYPE"=1 AND "I"."DATEMODIFIED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "I"."ISDISTRIBUTABLE"=1 AND "I"."ISDELETED"=0 AND "I"."ENTITYID">=0 AND "I"."DATEMODIFIED"<TO_DATE(' 2011-06-13 14:00:00',
                  'syyyy-mm-dd hh24:mi:ss'))
           filter("I"."ISDISTRIBUTABLE"=1 AND "I"."ISDELETED"=0 AND (LNNVL("I"."DATECREATED">=TO_DATE(' 2011-06-12 14:00:00',
                  'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("I"."DATECREATED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND
                  "I"."ENTITYID">=0)
      16 - access("ORGID"="I"."ENTITYID")
           filter("ORGID" IS NOT NULL AND "ORGID">=0)Thanks

  • Effect of RLS policy (VPD) on execution plan of a query

    Hi
    I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
    Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
    Regards,
    Amardeep Sidhu

    Amardeep Sidhu wrote:
    I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
    VPD is supposed to be invisible - which is why you get minimal information about security predicates in the standard trace file. However, if you reference a table with a security preidcate in your query, the table is effectively replaced by an inline view of the form: "select * from original_table where {security_predicate}", and the result is then optimised. So the effects of the security predicate is just the same as you writing the predicate into the query.
    Apart from your use of v$sql_plan to show the change in plan and the new predicates, you can see the effects of the predicates by setting event 10730 with 10046. In current versions of Oracle this causes the substitute view being printed in the trace file.
    Bear in mind that security predicates can be very complex - including subqueries - so the effect isn't just that of including the selectivity of "another simple predicate".
    Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
    Think of the effect of changing the SQL by hand - and how you would need to optimise the resultant query. Sometimes you do need to modify your indexing to help the security predicates, sometimes it won't make enough difference to matter.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "Science is more than a body of knowledge; it is a way of thinking"
    Carl Sagan
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Execution plan with bind variable

    dear all
    I join two tables and get "index fast full scan" with high cost using bind variable
    but when I remove the bind variable it executes with "index" and with lower cost
    What is the reason and how should I know which execution plan is really used in real life?
    thanks
    john

    1) What is oracle version?
    2) Post here both query and their explain plan.
    In fact INDEX FAST FULL SCAN indicate is multiblock read for composite indexes(and based on your query and predicates).In this case CBO behavior as FULL TABLE SCAN(affected by db_multiblock_read_count,system stats,etc).And you use bind variable.So in bind variable case CBO define selectivity based on arithmetic(5% of the cardinality) ,if you use concrete values instead of bind variable CBO identify other selectivity based on statistics,histograms,.... then it was identify cost of multiblock read and single block reads.You can see these 10053 event.Finally it choose lower cost`s plan.

  • SQL query with Bind variable with slower execution plan

    I have a 'normal' sql select-insert statement (not using bind variable) and it yields the following execution plan:-
    Execution Plan
    0 INSERT STATEMENT Optimizer=CHOOSE (Cost=7 Card=1 Bytes=148)
    1 0 HASH JOIN (Cost=7 Card=1 Bytes=148)
    2 1 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=4 Card=1 Bytes=100)
    3 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=3 Card=1)
    4 1 INDEX (FAST FULL SCAN) OF 'TABLEB_IDX_003' (NON-UNIQUE)
    (Cost=2 Card=135 Bytes=6480)
    Statistics
    0 recursive calls
    18 db block gets
    15558 consistent gets
    47 physical reads
    9896 redo size
    423 bytes sent via SQL*Net to client
    1095 bytes received via SQL*Net from client
    3 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    55 rows processed
    I have the same query but instead running using bind variable (I test it with both oracle form and SQL*plus), it takes considerably longer with a different execution plan:-
    Execution Plan
    0 INSERT STATEMENT Optimizer=CHOOSE (Cost=407 Card=1 Bytes=148)
    1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=3 Card=1 Bytes=100)
    2 1 NESTED LOOPS (Cost=407 Card=1 Bytes=148)
    3 2 INDEX (FAST FULL SCAN) OF TABLEB_IDX_003' (NON-UNIQUE) (Cost=2 Card=135 Bytes=6480)
    4 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=2 Card=1)
    Statistics
    0 recursive calls
    12 db block gets
    3003199 consistent gets
    54 physical reads
    9448 redo size
    423 bytes sent via SQL*Net to client
    1258 bytes received via SQL*Net from client
    3 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    55 rows processed
    TABLEA has around 3million record while TABLEB has 300 records. Is there anyway I can improve the speed of the sql query with bind variable? I have DBA Access to the database
    Regards
    Ivan

    Many thanks for your reply.
    I have run the statistic already for the both tableA and tableB as well all the indexes associated with both table (using dbms_stats, I am on 9i db ) but not the indexed columns.
    for table I use:-
    begin
    dbms_stats.gather_table_stats(ownname=> 'IVAN', tabname=> 'TABLEA', partname=> NULL);
    end;
    for index I use:-
    begin
    dbms_stats.gather_index_stats(ownname=> 'IVAN', indname=> 'TABLEB_IDX_003', partname=> NULL);
    end;
    Is it possible to show me a sample of how to collect statisc for INDEX columns stats?
    regards
    Ivan

Maybe you are looking for

  • Hardware failure on my iPhone 4s, I want to get a new phone under the NZ consumer guarantees act. How do I go about doing this?

    Hello, My ear speaker has failed in my two year old iPhone 4s. As this is a hardware failure under New Zealands consumers guarantees act apple is liable and is legally obligated to replace my device. Since I ordered my phone online from the apple nz

  • Strange audio distortion in video

    Hi Everyone, I have a Macbook Pro (2.3 ghz, 4 gb of ram, running dual displays) and for the last nine months or so I've been having bizarre (horribly angry robot voices) distortion in audio when running video, seemingly for no reason. Sometimes an ac

  • Db_block

    Hello, How to find the db_block_size set in a database? I know way that is SHOW PARAMETER. Is there any view or table that holds this information? Can I change this value after installation? Thanks.

  • Error start SOA Suite(J2EE Server)

    Usually J2EE Server successfully start and works. But sometimes server cannot start, and shows a following error: ================================================== ias-component: default_group process-type: home process-set: default_group Error Mess

  • Makeing changes on your iweb from multiple macs

    i've been working on my web site from my desktop all this time and i just got a new macbook labtop and i'd love to be able to update my web site from there too..... how do i, or can i do that????