Number of rows in execution plans

Hi ,
I have issued the following command:
SQL> SELECT * FROM DEPT
  2         WHERE LOC between 'BOSTON' AND 'DALLAS'
  3  /
DEPTNO DNAME                                      LOC
    40 OPERATIONS                                 BOSTON
    30 SALES                                      CHICAGO
    20 RESEARCH                                   DALLASWhen i examine the exec plan the number of rows returned by the exec step 1 is 1 and not 3... should't it be 3....????
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4153608586
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Tim
|   0 | SELECT STATEMENT            |         |     1 |    23 |     2   (0)| 00:
|   1 |  TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    23 |     2   (0)| 00:
|*  2 |   INDEX RANGE SCAN          | IDX_LOC |     1 |       |     1   (0)| 00:
Predicate Information (identified by operation id):
   2 - access("LOC">='BOSTON' AND "LOC"<='DALLAS')
14 rows selectedI use 10g. v.2 DB and i have analyzed the whole schema...before running the exec.plan
SQL> EXEC DBMS_STATS.gather_schema_stats(ownname => 'SCOTT');
Thanks....
Sim

Hi,
Try this code...
REPORT zreport.
PARAMETER p_infile LIKE rlgrap-filename DEFAULT 'C:TEMPZMPR.xls'.
DATA : lin TYPE i.
DATA: itab LIKE alsmex_tabline OCCURS 0 WITH HEADER LINE.
START-OF-SELECTION.
  CALL FUNCTION 'ALSM_EXCEL_TO_INTERNAL_TABLE'
    EXPORTING
      filename                = p_infile
      i_begin_col             = '1'
      i_begin_row             = '1'
      i_end_col               = '1'
      i_end_row               = '28000'
    TABLES
      intern                  = itab
    EXCEPTIONS
      inconsistent_parameters = 1
      upload_ole              = 2
      OTHERS                  = 3.
  IF sy-subrc <> 0.
    MESSAGE text-009 TYPE 'S'. "Problem uploading Excel Spreadsheet
    EXIT.
  ENDIF.
  DESCRIBE TABLE itab LINES lin.
  WRITE :/ 'Number of lines: ', lin.

Similar Messages

  • How to corret an execution plan that shows wrong number of rows?

    Using Oracle 10gR2 RAC (10.2.0.3) on SUSE Linux 9 (x86_64).
    I have a partition table that has 5 million rows (5,597,831). However an execution plan against the table show that the table has 10 million rows.
    Execution plan:
    SELECT STATEMENT ALL_ROWS Cost : 275,751 Bytes : 443 Cardinality : 1
    3 HASH GROUP BY Cost : 275,751 Bytes : 443 Cardinality : 1
         2 PARTITION RANGE ALL Cost : 275,018 Bytes : 4,430,000,000 Cardinality : *10,000,000* Partition # : 2 Partitions accessed #1 - #6
              1 TABLE ACCESS FULL TRACESALES.TRACE_BUSINESS_AREA Cost : 275,018 Bytes : 4,430,000,000 Cardinality : 10,000,000 Partition # : 2 Partitions accessed #1 - #6
    Plan hash value: 322783426
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
    | 0 | SELECT STATEMENT | | 1 | 443 | 275K (2)| 00:55:10 | | |
    | 1 | HASH GROUP BY | | 1 | 443 | 275K (2)| 00:55:10 | | |
    | 2 | PARTITION RANGE ALL| | 10M| 4224M| 275K (2)| 00:55:01 | 1 | 6 |
    | 3 | TABLE ACCESS FULL | TRACE_BUSINESS_AREA | 10M| 4224M| 275K (2)| 00:55:01 | 1 | 6 |
    How does one correct the explain plan?
    The problem: Queries against the table are taking hours to complete. The problem started when the table was dropped then recreated with a new partition.
    I have complete the drop and creation against several tables for several years without problems until now.
    I have done the following: Analyzed statistics against the table, flushed buffer cache. Created a materialized view.
    However users queries are taking several hours to complete, where before the addition of the partition the queries where taking 5 minutes to complete.
    Thanks. BL.

    Yes, complete analysis of statistic was complete on indexes and against partitions.
    Table creation statement:
    CREATE TABLE TRACESALES.TRACE_BUSINESS_AREA
    ... *(400 columns)*
    TABLESPACE "trace_OLAPTS"
    PCTUSED 0
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL KEEP
    PARTITION BY RANGE (YEAR)
    PARTITION TRACE_06 VALUES LESS THAN ('2007')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2006
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_07 VALUES LESS THAN ('2008')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2007
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_08 VALUES LESS THAN ('2009')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2008
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_09 VALUES LESS THAN ('2010')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2009
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_10 VALUES LESS THAN ('2011')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2010
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_11 VALUES LESS THAN (MAXVALUE)
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2011
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    NOCOMPRESS
    CACHE
    PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT )
    MONITORING;
    *(index statements, constraints, triggers and security)*
    Table caching is on and running in parallel degree 4 instances 1.

  • Avoid execution plan that resolves unused join

    There are two tables Master and LookUp.
    Master references LookUp by its indexed primary key.
    CREATE TABLE "LookUp" (
    ID_LU NUMBER NOT NULL,
    DATA VARCHAR2(100) );
    CREATE UNIQUE INDEX LOOKUP_PK ON "LookUp"(ID_LU);
    ALTER TABLE "LookUp" ADD (
    CONSTRAINT LOOKUP_PK
    PRIMARY KEY (ID_LU)
    USING INDEX );
    CREATE TABLE "Master" (
    ID NUMBER NOT NULL,
    DATA VARCHAR2(100),
    ID_LU NUMBER );
    CREATE UNIQUE INDEX MASTER_PK ON "Master"(ID);
    ALTER TABLE "Master" ADD (
    CONSTRAINT MASTER_PK
    PRIMARY KEY (ID)
    USING INDEX );
    ALTER TABLE "Master" ADD (
    CONSTRAINT FK_MASTER
    FOREIGN KEY (ID_LU)
    REFERENCES "LookUp" (ID_LU));
    Selecting rows from LookUp with LEFT OUTER JOIN Master produces a query execution plan that does not consider Master as it is not used.
    SELECT t1.ID_LU FROM "LookUp" t1
    LEFT OUTER JOIN "Master" t2
    ON t1.ID_LU = t2.ID_LU;
    PLAN_ID     ID     PARENT_ID     DEPTH     OPERATION     OPTIMIZER     OPTIONS     OBJECT_NAME     OBJECT_ALIAS     OBJECT_TYPE
    2     0          0     SELECT STATEMENT     ALL_ROWS                    
    2     1     0     1     TABLE ACCESS          FULL     Master     T1@SEL$2     TABLE
    But selecting rows from Master with LEFT OUTER JOIN LookUp produces a not specular query execution plan that considers LookUp table although it is not used.
    SELECT t1.ID_LU FROM "Master" t1
    LEFT OUTER JOIN "LookUp" t2
    ON t1.ID_LU = t2.ID_LU;
    PLAN_ID     ID     PARENT_ID     DEPTH     OPERATION     OPTIMIZER     OPTIONS     OBJECT_NAME     OBJECT_ALIAS     OBJECT_TYPE
    1     0          0     SELECT STATEMENT     ALL_ROWS                    
    1     1     0     1     HASH JOIN          OUTER               
    1     2     1     2     INDEX          FAST FULL SCAN     LOOKUP_PK     T1@SEL$2     INDEX (UNIQUE)
    1     3     1     2     TABLE ACCESS          FULL     Master     T2@SEL$1     TABLE
    For example Sql Server 2005 does not make distiction between the two query execution plans.
    I would like to know why sql optimizer behaves this way and especially if there is a hint or an option that helps optimizer to avoid involving unused join tables.

    Actually, something does not add up. Left outer join selects all rows in left table even if there is no matching row in right table. Left table in first query is Lookup table. So I can not understand how execution plan:
    SELECT t1.ID_LU FROM "LookUp" t1
    LEFT OUTER JOIN "Master" t2
    ON t1.ID_LU = t2.ID_LU;
    PLAN_ID ID PARENT_ID DEPTH OPERATION OPTIMIZER OPTIONS OBJECT_NAME OBJECT_ALIAS OBJECT_TYPE
    2 0 0 SELECT STATEMENT ALL_ROWS
    2 1 0 1 TABLE ACCESS FULL Master T1@SEL$2 TABLEbypasses Lookup table. On my 10.2.0.4.0 I get:
    SQL> SELECT t1.ID_LU FROM "LookUp" t1
      2  LEFT OUTER JOIN "Master" t2
      3  ON t1.ID_LU = t2.ID_LU;
    no rows selected
    Execution Plan
    Plan hash value: 3482147238
    | Id  | Operation          | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |        |     1 |    26 |     5  (20)| 00:00:01 |
    |*  1 |  HASH JOIN OUTER   |        |     1 |    26 |     5  (20)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL| LookUp |     1 |    13 |     2   (0)| 00:00:01 |
    |   3 |   TABLE ACCESS FULL| Master |     1 |    13 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - access("T1"."ID_LU"="T2"."ID_LU"(+))
    Note
       - dynamic sampling used for this statement
    Statistics
            209  recursive calls
              0  db block gets
             48  consistent gets
              0  physical reads
              0  redo size
            274  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              6  sorts (memory)
              0  sorts (disk)
              0  rows processedI do question this plan. I would expect FULL INDEX SCAN of LOOKUP_PK index. And for second query I get plan same a OP:
    SQL> SELECT t1.ID_LU FROM "Master" t1
      2  LEFT OUTER JOIN "LookUp" t2
      3  ON t1.ID_LU = t2.ID_LU;
    no rows selected
    Execution Plan
    Plan hash value: 3856835961
    | Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |           |     1 |    26 |     2   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS OUTER|           |     1 |    26 |     2   (0)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL| Master    |     1 |    13 |     2   (0)| 00:00:01 |
    |*  3 |   INDEX UNIQUE SCAN| LOOKUP_PK |     1 |    13 |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - access("T1"."ID_LU"="T2"."ID_LU"(+))
    Note
       - dynamic sampling used for this statement
    Statistics
              1  recursive calls
              0  db block gets
              7  consistent gets
              0  physical reads
              0  redo size
            274  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed
    SQL> SY.

  • Wrh$_sql_plan - execution plan

    Hello!
    In wrh$_sql_plan I see data with sql_id that I need ,
    but there is't any row with my snap_id,
    should I consider snap_id with the first smallest number to get cuurent execution plan of statement or how to get teal execution plan of statement that
    already isn't present in cashe ?
    In other words in some interval of time DML-statement was executed ,
    it is present at the AWR report, but isn't visible in wrh$_sql_plan with my snap_id
    Thanks and regards,
    Pavel
    Edited by: Pavel on Oct 31, 2012 4:29 AM

    Dba_hist_sql_plan (Wrh$_sql_plan) does not need to pay attention to snap id.
    From a data modelling perspective, this makes sense because one particular plan may appear multiple times across multiple snaps.
    All we need is one recording of that particular plan to show what that plan is.
    What you probably want to reference is dba_hist_sqlstat which will tell you about the executions of a particular statement in a period and which plans were used.
    Edited by: Dom Brooks on Oct 31, 2012 11:59 AM

  • Number of rows to be displayed in Compensation Planning iView in ECM

    Hi Experts,
    I want to increase a number of rows to be displayed in the Compensation Planning iView in ECM from 5 to 10. How do I do that? Thanks!
    Anthony

    We can set the numnber of rows to be displayed by using the standard table UI of java web dynpro. Thanks!

  • How can I reduce number of rows in Planning webform in Smartview?

    Hi,
    I downloaded a Planning webform into Smartview. I want to reduce the 1000 rows down to 20 for a particular user as he does not submit data for the other 980 rows. How can I reduce number of rows in Planning webform in Smartview?
    Someone said that I can insert vlookup code into Smartiveiw pointing to a new worksheet that has only 20 rows. I could not test it as our Planning 9.3.1 has a bug that would not take sub variables from Smartview.
    Thanks.

    Hi,
    My first reaction is why do you have a form with a 1000 rows, surely this is a design issue and doesn't benefit anybody when entering data, anyway why not have security on the dimensions then users will only see what they have access to when they retrieve the form in smart view or through the planning web front end.
    Cheers
    John
    http://john-goodwin.blogspot.com/

  • Help in TKPROF Output: Row Source Operation v.s Execution plan confusing

    Hello,
    Working with oracle 10g/widnows, and trying to understand from the TKPROF what is the purpose of the "Row Source operation" section.
    From the "Row Source Operation" section the PMS_ROOM table is showing 16 rows selected, and accessed by an ACCESS FULL, and the following script gives another value.
    select count(*) from pms_folio give the following.
    COUNT(*)
    148184
    But in the execution plan section, the PMS_FOLIO table is accessed by ROW ID after index scan in the JIE_BITMAP_CONVERSION index
    What really means Row Source operation compares to the execution plan and how both information should be read to fully know if the optimizer is not making wrong estimation?
    furthermore readding 13594 buffers to fetch 2 rows, show the SQL Script itself is not sufficient, but the elapsed time is roughly 0.7seconds,but shrinking the # of buffers to be read should probably shrink the response time.
    The following TKPROF output.
    Thanks very much for your help
    SELECT NVL(SUM(NVL(t1.TOTAL_GUESTS, 0)), 0)
    FROM DEV.PMS_FOLIO t1
    WHERE (t1.FOLIO_STATUS <> 'CANCEL'
    AND t1.ARRIVAL_DATE <= TO_DATE(:1, 'SYYYY/MMDDHH24MISS')
    AND t1.DEPARTURE_DATE > TO_DATE(:1, 'SYYYY/MMDDHH24MISS')
    AND t1.PRIMARY_OR_SHARE = 'P' AND t1.IS_HOUSE = 'N')
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 2 0.00 0.00 0 0 0 0
    Fetch 2 0.12 0.12 0 13594 0 2
    total 5 0.12 0.12 0 13594 0 2
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 82 (PMS5000)
    Rows Row Source Operation
    2 SORT AGGREGATE (cr=13594 pr=0 pw=0 time=120165 us)
    16 TABLE ACCESS FULL PMS_FOLIO (cr=13594 pr=0 pw=0 time=121338 us)
    Rows Execution Plan
    0 SELECT STATEMENT MODE: ALL_ROWS
    2 SORT (AGGREGATE)
    16 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PMS_FOLIO'
    (TABLE)
    0 INDEX MODE: ANALYZED (RANGE SCAN) OF
    'JIE_BITMAP_CONVERSION' (INDEX)
    <Edited by: user552326 on 8-Apr-2009 12:49 PM
    Edited by: user552326 on 8-Apr-2009 12:52 PM
    Edited by: user552326 on 8-Apr-2009 12:53 PM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

    Your query is using bind variables. Explain Plan doesn't work exactly the same way -- it can't handle bind variables.
    See http://www.oracle.com/technology/oramag/oracle/08-jan/o18asktom.html
    In your output, the row source operations listing is the real execution.
    The explain plan listing may well be misleading as Oracle uses cardinality estimates when trying to explain with bind variables.
    Also, it seems that your plan table may be a 9i version, not the 10g PLAN_TABLE created by catplan.sql There are additional columns in the 10g PLAN_TABLE that explain uses well.
    BTW, you start off with a mention of "PMS_ROOM" showing 16 rows, but it doesn't appear in the data you have presented.

  • How to find number of rows in a table

    i have one table ,it contains millions of record,how can i know number of rows in that table without using count(*),
    i tried in user_table ,for the column NUM_ROWS,but it is not showing number of rows,pls send me a solution for this.
    regards,
    singh

    Ok, that only was to show simply that max option
    might not an option to reduce execution time.Yes, but I/O variances have a tendency to really skew the observed elapsed execution time - making execution time alone a poor choice to determine what SQL will perform better than another.
    Both MAX(ROWNUM) and COUNT(*) results in the same amount of I/O - as both uses the exact same execution plan, I/O wise. In this example, a FTS.
    SQL> create table testtab nologging as select * from all_objects where rownum < 10001;
    Table created.
    -- warmed up the buffer cache with a couple of SELECTs against TESTAB in order
    -- to discard PIOs from the results
    SQL> set autotrace on
    SQL> select count(*) from testtab;
    COUNT(*)
    10000
    Execution Plan
    Plan hash value: 2656308840
    | Id | Operation | Name | Rows | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 35 (9)| 00:00:01 |
    | 1 | SORT AGGREGATE | | 1 | | |
    | 2 | TABLE ACCESS FULL| TESTTAB | 9262 | 35 (9)| 00:00:01 |
    Note
    - dynamic sampling used for this statement
    Statistics
    0 recursive calls
    0 db block gets
    131 consistent gets
    0 physical reads
    0 redo size
    223 bytes sent via SQL*Net to client
    238 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed
    SQL> select max(rownum) from testtab;
    MAX(ROWNUM)
    10000
    Execution Plan
    Plan hash value: 2387991791
    | Id | Operation | Name | Rows | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 35 (9)| 00:00:01 |
    | 1 | SORT AGGREGATE | | 1 | | |
    | 2 | COUNT | | | | |
    | 3 | TABLE ACCESS FULL| TESTTAB | 9262 | 35 (9)| 00:00:01 |
    Note
    - dynamic sampling used for this statement
    Statistics
    0 recursive calls
    0 db block gets
    131 consistent gets
    0 physical reads
    0 redo size
    225 bytes sent via SQL*Net to client
    238 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed
    So seeing that we have the exact same baseline for both queries, and that PIO does not influence the results, we time a 1000 executions of both.
    SQL> declare
    2 cnt number;
    3 begin
    4 for i in 1..1000
    5 loop
    6 select count(*) into cnt from testtab;
    7 end loop;
    8 end;
    9 /
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:03.19
    SQL>
    SQL> declare
    2 cnt number;
    3 begin
    4 for i in 1..1000
    5 loop
    6 select max(rownum) into cnt from testtab;
    7 end loop;
    8 end;
    9 /
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:15.87
    SQL>
    This shows that what makes the MAX() more expensive is just that - determining the MAX(). For each row, Oracle has to call its internal MAX() function with two values - the current max result and the new value. This function then returns the new max value. This overhead per row adds up to a significant overhead in execution time - making the MAX() approach 5x slower than the COUNT() approach.

  • How to get execution plan in a CLOB?

    Hello,
    I want to get execution plans of a query in a CLOB format. I am trying to run following query against v$sql view. One of the columns I want is the execution plan for the query. I am getting following error. Eventually, I am going to insert this data into a log table to keep history of all SQLs and their execution plans.
    How can I do that?
    Thank you in advance.
    SQL> SELECT sql_id,
      2         plan_hash_value,
      3         TO_CLOB (DBMS_XPLAN.display_awr (sql_id            => sql_id,
      4                                          plan_hash_value   => plan_hash_value,
      5                                          format            => '+PEEKED_BINDS'))
      6            sql_plan_clob,
      7         buffer_gets,
      8         executions
      9    FROM v$sql
    10   WHERE ROWNUM < 5;
           TO_CLOB (DBMS_XPLAN.display_awr (sql_id            => sql_id,
    ERROR at line 3:
    ORA-00932: inconsistent datatypes: expected NUMBER got SYS.DBMS_XPLAN_TYPE_TABLE

    try first
    select *
      from table(DBMS_XPLAN.display_awr(sql_id          => sql_id,
                                        plan_hash_value => plan_hash_value,
                                        format          => '+PEEKED_BINDS'
                )to see the table returned
    then try to adapt http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:68212348056 to produce fixed length rows.
    look for describe_columns procedures in http://docs.oracle.com/cd/E11882_01/appdev.112/e25788/d_sql.htm#i1025449 for column length information available in internal tables and write the rows directly to clob instead of writing to disk and loading your clob from there.
    Regards
    Etbin
    Edited by: Etbin on 31.10.2012 19:56
    pointing to dbms_sql package added

  • What to look for in Execution plans ?

    Hi Pals,
    Assuming the query execution is slow , I have collected the xml plan. What should I look for in the actual execution plan . What are the top 10 things I need to watch out for?
    I know this is a broad and generic question but I am looking for anyone who is experienced in query tuning to answer this question.
    Thanks in Advance.

    Reading execution plans is a bit of an art. But a couple of things:
    1) Download and install SQL Sentry Plan Explorer (www.sqlsentry.net). This is a free tool that in msny cases gives a better experience to look at execution plans, particularly big and ugly ones.
    2) I usually look for the thickest arrows, as thickness indicates the number of rows being processed.
    3) Look for deviations between estimates and actual values, as these deviations are often the source for bad performance. In Plan Explorer, you can quickly flip between the too. In SSMS you need to look at the popup for every operator. (But again, it is
    the operator with fat arrows that are of most interest - and those before them.
    4) The way to read the plan is that the left-most operator asks the operators it is connected to for data. The net effect is that data flows from right to left, and the right-hand side if often more interesting.
    5) Don't pay much attention to the percentages about operator cost. These percentages are estimates only,
    not actual values. They are only reliable if the estimates are correct all the way through - and when you have a bad plan that is rarely the case.
    This was the overall advice. Then there is more specific one: are indexes being used when expected? Note that scans are necessarily not bad. Sometimes your problem is that you have a loop join + index seek, when you should have had two scans and a hash join.
    Try to get a grip of how you would process the query, if you had to do it manually. Does the plan match that idea?
    Erland Sommarskog, SQL Server MVP, [email protected]

  • Worst execution plan ever?

    World record estimation fail.  We expect 1 row back, Sql Server expects over 23 trillion!  The estimated memory is 111 Petabytes (yes, I said Peta).
    We're using a pretty ugly view.  Ugly because it has nested views, a correlated subquery and about 20 total joins.  On the good side, the call is restricting the view with a single ID against the base table (this is for a single patient).  The
    rest of the view goes out and gets the patient's address, phone, contacts, status, insurance, diagnosis, etc.  The db structure is fairly normalized so that does include about 20 tables.
    This is a new application and as such there isn't much data yet.  When we run the view on our server with thousands of patients, the results are returned quickly.  Query time is subsecond.  The execution plan is ugly as expected, it's got
    hundreds of nodes, but the cost is pretty low and the performance is acceptable.
    When we run the same view on a disconnected device running Sql Server Localdb, it sometimes loses it's mind.  Note that the number of patients on the device is rarely over 100, it's a subset of the records on the server.  That's when we get the
    numbers that I'm quoting above.  Basically, the first join thinks there might be 12 records returns, then the next estimates 20 times that many, then 50 times that many, and that number just keeps multiplying until we get to trillions.
    I have a screenshot in case anyone thinks I'm exaggerating those numbers.  I also have the execution plan XML.  
    Bottom line is we're going to rewrite the query, but this now becomes an excuse to learn.  Where is Grant Fritchey when you need him?

    In situations like this, there are a few typical situations:
    The statistics are stale
    You are using parameters and parameter sniffing goes awry
    You've hit a bug or flaw in the optimizer
    The query can not be properly optimized
    The first possible situation is the easiest to find and fix. Simply run UPDATE STATISTICS (preferably WITH FULLSCAN) on each table that is part of the query.
    The second situation is also easily testable. For example, you can add OPTION WITH RECOMPILE (or any other relevant Compilation Option) to defeat parameter sniffing.
    Of course, you should always check whether you have proper indexes in place. Be aware that Foreign Key relations are not automatically indexed.
    If you are out of luck, and it is not any of the first two, then you can dive deeper and find out what is going wrong. If you lack the time or knowledge to do that, you can break the query in several queries and use temporary tables with intermediate results.
    Gert-Jan

  • 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;
    /

  • Too many nested loops in execution plan?

    Hi,
    i wonder about execution plan not indicating that access to some tables (for join) is in parallel.
    Please see this example:
    ------------------------ snip ------------------------------------
    drop table test_a1;
    drop table test_a2;
    drop table test_b;
    drop table test_c;
    drop table test_d;
    create table test_a1 (
    x number,
    y number,
    z number);
    create unique index testa1_pk on test_a1 (x);
    create table test_a2 (
    x number,
    y number,
    z number);
    create unique index testa2_pk on test_a2 (x);
    create table test_b (
    x number,
    y number,
    z number);
    create unique index testb_pk on test_b (y);
    create table test_c (
    x number,
    y number,
    z number);
    create unique index testc_pk on test_b (z);
    create table test_d (
    x number,
    y number,
    z number);
    create unique index testd_pk on test_d (y);
    select
    a1.x a1_x,
    a1.y a1_y,
    a1.z a1_z,
    a2.x a2_x,
    a2.y a2_y,
    a2.z a2_z,
    b.x b_x,
    b.y b_y,
    b.z b_z,
    c.x c_x,
    c.y c_y,
    c.z c_z,
    d.x d_x,
    d.y d_y,
    d.z d_z
    from test_a1 a1, test_a2 a2, test_b b, test_c c, test_d d
    where a1.x = 100
    and a2.x = 200
    and b.y = a1.y
    and c.z = b.z
    and d.y = a1.y;
    ------------------------ snap ------------------------------------
    The execution plan goes like this:
    Select Stmt
         nested loops
              nested loops
                   nested loops
                        nested loops
                             table access
                                  index
                                       access predicate
                                            a2.x = 200
                             table access
                                  index
                                       access predicate
                                            a1.x = 100
                        table access
                             index
                                  access predicate
                                       d.y = a1.y
                   table access
                        index
                             access predicate
                                  b.y = a1.y
              table acess
                   index
                        acess predicate
                             c.z = b.z
    Access to tables a1 and a2 is on the same level (in parallel - i guess).
    However, why isn't access to table d and b on the same level?
    Both depend on a1. So no need to execute one after the other (no inter-dependency).
    Maybe i have just wrong expectation to the output of the execution plan(?!)
    - many thanks!
    best regards,
    Frank

    Preservation of identation and spacing is invaluable when it comes to reading an explain plan.
    | Id  | Operation                       | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                |           |     1 |   195 |     2   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS                   |           |     1 |   195 |     2   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS                  |           |     1 |   156 |     0   (0)| 00:00:01 |
    |   3 |    NESTED LOOPS                 |           |     1 |   117 |     0   (0)| 00:00:01 |
    |   4 |     NESTED LOOPS                |           |     1 |    78 |     0   (0)| 00:00:01 |
    |   5 |      TABLE ACCESS BY INDEX ROWID| TEST_A2   |     1 |    39 |     0   (0)| 00:00:01 |
    |*  6 |       INDEX UNIQUE SCAN         | TESTA2_PK |     1 |       |     0   (0)| 00:00:01 |
    |   7 |      TABLE ACCESS BY INDEX ROWID| TEST_A1   |     1 |    39 |     0   (0)| 00:00:01 |
    |*  8 |       INDEX UNIQUE SCAN         | TESTA1_PK |     1 |       |     0   (0)| 00:00:01 |
    |   9 |     TABLE ACCESS BY INDEX ROWID | TEST_D    |    82 |  3198 |     0   (0)| 00:00:01 |
    |* 10 |      INDEX UNIQUE SCAN          | TESTD_PK  |     1 |       |     0   (0)| 00:00:01 |
    |  11 |    TABLE ACCESS BY INDEX ROWID  | TEST_B    |    82 |  3198 |     0   (0)| 00:00:01 |
    |* 12 |     INDEX UNIQUE SCAN           | TESTB_PK  |     1 |       |     0   (0)| 00:00:01 |
    |* 13 |   TABLE ACCESS FULL             | TEST_C    |     1 |    39 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       6 - access("A2"."X"=200)
       8 - access("A1"."X"=100)
      10 - access("D"."Y"="A1"."Y")
      12 - access("B"."Y"="A1"."Y")
      13 - filter("C"."Z"="B"."Z")
    Access to tables a1 and a2 is on the same level (in parallel - i guess).
    Maybe i have just wrong expectation to the output of the execution plan(?!)You guess wrong, there's nothing parallel going on here.
    Execution plan is a tree of parent-child operations.
    For example, the NESTED LOOP at operation 4 has two children @ 5 and 7.
    Both of these operations- 5 & 7 - have a single child operation.
    The execution tree starts with operation 6, using the TESTA2_PK index to identify rows where A2.X=100.
    From this list of rowids, we go to the table TEST_A2 operation 5.
    The rows from operation five feed into the NESTED LOOP - operation 4.
    For each of these rows, we go to TEST_A1 via the index TEST_A1_PK for rows where A1.X=100.
    This is really a cartesian join because there's no join condition between the two tables.
    etc, etc, etc
    Three things in particular to point out.
    Firstly, that nothing joins to A2. So there will be a cartesian product - i.e. for every row in the result set between the joined tables A1, B, C and D, these will be multiplied by the number of rows returned by the the A2 rowsource.
    Secondly, when everything has got one or zero rows (or the optimizer thinks that it's one or zero rows), you can get very different plans from when there are known/thought to be more rows.
    Both depend on a1. So no need to execute one after the other (no inter-dependency).Thirdly, in terms of isolated join operations (ignoring A2 and C for the moment), A1 cannot join to B and D at the same time, you can either join A1 to B and then join the result of that to D, or join A1 to D then B, which is what you've got in your plan (well, actually we have A2 joined to A1 then the result of that joined to D and then the result of that to B).
    Edited by: Dom Brooks on Jul 6, 2011 4:07 PM
    Corrected typo

  • Query Execution Plans Change between 2 servers even when we have same data.

    Hi Friends,
    Currently One of the Query which normally takes 15 seconds but it started taking 160 seconds.So same query was executed on the secondary site and the query returned in 15 seconds which is expected.Raised a call with ORacle and they are still investigating since 27th Sept.
    Oracle version=11.2.0.2
    OS=Solaris 10.
    Issue DB execution plan
    select * From  tibex_openinghomemktok as of scn 17032999332 where meid='ME1'
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.12       0.12          0          0          0           0
    Execute      1    161.20     161.21         55    1539719        206           0
    Fetch        6      0.05       0.05        190        386          1         464
    total        8    161.37     161.38        245    1540105        207         464
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 191
    Number of plan statistics captured: 1
    Rows (1st) Rows (avg) Rows (max)  Row Source Operation
           464        464        464  VIEW  TIBEX_OPENINGHOMEMKTOK (cr=1540105 pr=245 pw=191 time=161246176 us cost=149 size=291 card=1)
           464        464        464   TEMP TABLE TRANSFORMATION  (cr=1540105 pr=245 pw=191 time=161245860 us)
             0          0          0    LOAD AS SELECT  (cr=27 pr=0 pw=1 time=24101 us)
            13         13         13     HASH JOIN  (cr=27 pr=0 pw=0 time=13149 us cost=35 size=1408 card=8)
             1          1          1      TABLE ACCESS FULL TIBEX_TRADINGMETHODENUM (cr=2 pr=0 pw=0 time=83 us cost=5 size=14 card=1)
           235        235        235      HASH JOIN  (cr=25 pr=0 pw=0 time=12612 us cost=30 size=22356 card=138)
           235        235        235       NESTED LOOPS OUTER (cr=21 pr=0 pw=0 time=11568 us cost=22 size=16560 card=138)
           235        235        235        HASH JOIN  (cr=20 pr=0 pw=0 time=10831 us cost=22 size=10074 card=138)
            40         40         40         HASH JOIN  (cr=18 pr=0 pw=0 time=8119 us cost=17 size=2200 card=40)
            40         40         40          HASH JOIN OUTER (cr=12 pr=0 pw=0 time=5920 us cost=13 size=1320 card=40)
            40         40         40           NESTED LOOPS  (cr=10 pr=0 pw=0 time=4155 us cost=3 size=800 card=40)
            80         80         80            VIEW  index$_join$_018 (cr=6 pr=0 pw=0 time=4245 us cost=3 size=1040 card=80)
            80         80         80             HASH JOIN  (cr=6 pr=0 pw=0 time=3057 us)
            80         80         80              INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=169 us cost=1 size=1040 card=80)(object id 1354894)
            80         80         80              INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=70 us cost=1 size=1040 card=80)(object id 1354895)
            40         40         40            INDEX UNIQUE SCAN XPKTIBEX_DAYSTRADINGCYCLEMAP (cr=4 pr=0 pw=0 time=152 us cost=0 size=7 card=1)(object id 1354685)
             0          0          0           VIEW  (cr=2 pr=0 pw=0 time=316 us cost=10 size=143 card=11)
             0          0          0            HASH JOIN  (cr=2 pr=0 pw=0 time=315 us cost=8 size=352 card=11)
             0          0          0             MERGE JOIN  (cr=2 pr=0 pw=0 time=118 us cost=4 size=209 card=11)
             0          0          0              TABLE ACCESS BY INDEX ROWID TIBEX_HOLIDAYS (cr=2 pr=0 pw=0 time=113 us cost=2 size=26 card=2)
            83         83         83               INDEX FULL SCAN XPKTIBEX_HOLIDAYS (cr=1 pr=0 pw=0 time=113 us cost=1 size=0 card=83)(object id 1354737)
             0          0          0              SORT JOIN (cr=0 pr=0 pw=0 time=0 us cost=2 size=2412 card=402)
             0          0          0               INDEX FULL SCAN XPKTIBEX_HOLIDAYTRADINGCYCLEMA (cr=0 pr=0 pw=0 time=0 us cost=1 size=2412 card=402)(object id 1354739)
             0          0          0             VIEW  index$_join$_023 (cr=0 pr=0 pw=0 time=0 us cost=3 size=1040 card=80)
             0          0          0              HASH JOIN  (cr=0 pr=0 pw=0 time=0 us)
             0          0          0               INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354894)
             0          0          0               INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354895)
            80         80         80          VIEW  index$_join$_024 (cr=6 pr=0 pw=0 time=1121 us cost=3 size=1760 card=80)
            80         80         80           HASH JOIN  (cr=6 pr=0 pw=0 time=1040 us)
            80         80         80            INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=66 us cost=1 size=1760 card=80)(object id 1354894)
            80         80         80            INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=57 us cost=1 size=1760 card=80)(object id 1354895)
           275        275        275         TABLE ACCESS FULL TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=229 us cost=5 size=4950 card=275)
             0          0          0        TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=384 us cost=0 size=47 card=1)
             0          0          0         INDEX UNIQUE SCAN XPKTIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=135 us cost=0 size=0 card=1)(object id 1354925)
           330        330        330       TABLE ACCESS FULL TIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=61 us cost=7 size=13860 card=330)
             0          0          0    LOAD AS SELECT  (cr=1539692 pr=55 pw=190 time=161190726 us)
         12435      12435      12435     NESTED LOOPS  (cr=1539692 pr=55 pw=0 time=158262964 us cost=109 size=284 card=1)
         12435      12435      12435      FILTER  (cr=1539688 pr=55 pw=0 time=158208902 us)
        497400     497400     497400       NESTED LOOPS OUTER (cr=1539688 pr=55 pw=0 time=212847780 us cost=109 size=280 card=1)
        497400     497400     497400        NESTED LOOPS  (cr=544888 pr=55 pw=0 time=60349504 us cost=108 size=267 card=1)
        497400     497400     497400         MERGE JOIN CARTESIAN (cr=47484 pr=55 pw=0 time=57182690 us cost=107 size=254 card=1)
         12435      12435      12435          NESTED LOOPS  (cr=47483 pr=55 pw=0 time=2368168 us cost=106 size=247 card=1)
         13877      13877      13877           NESTED LOOPS  (cr=33602 pr=55 pw=0 time=5930848 us cost=105 size=233 card=1)
          1473       1473       1473            NESTED LOOPS  (cr=212 pr=2 pw=0 time=9371 us cost=35 size=390 card=3)
            13         13         13             HASH JOIN  (cr=193 pr=1 pw=0 time=8029 us cost=34 size=116 card=1)
            13         13         13              NESTED LOOPS  (cr=191 pr=1 pw=0 time=7255 us cost=31 size=95 card=1)
           338        338        338               HASH JOIN  (cr=187 pr=1 pw=0 time=6329 us cost=31 size=2821 card=31)
            13         13         13                VIEW  VW_NSO_1 (cr=184 pr=1 pw=0 time=5958 us cost=26 size=26 card=1)
            13         13         13                 SORT GROUP BY (cr=184 pr=1 pw=0 time=5954 us cost=26 size=115 card=1)
            65         65         65                  NESTED LOOPS ANTI (cr=184 pr=1 pw=0 time=5898 us cost=25 size=115 card=1)
            78         78         78                   NESTED LOOPS  (cr=102 pr=1 pw=0 time=6140 us cost=24 size=101 card=1)
            78         78         78                    NESTED LOOPS OUTER (cr=20 pr=1 pw=0 time=5341 us cost=23 size=94 card=1)
            78         78         78                     HASH JOIN  (cr=19 pr=1 pw=0 time=5077 us cost=23 size=55 card=1)
            13         13         13                      HASH JOIN  (cr=17 pr=1 pw=0 time=4056 us cost=17 size=352 card=8)
            40         40         40                       NESTED LOOPS  (cr=13 pr=0 pw=0 time=3300 us cost=15 size=1480 card=40)
            40         40         40                        HASH JOIN OUTER (cr=9 pr=0 pw=0 time=2928 us cost=15 size=1320 card=40)
            40         40         40                         HASH JOIN  (cr=7 pr=0 pw=0 time=1976 us cost=5 size=800 card=40)
            40         40         40                          INDEX RANGE SCAN XPKTIBEX_DAYSTRADINGCYCLEMAP (cr=1 pr=0 pw=0 time=120 us cost=1 size=280 card=40)(object id 1354685)
            80         80         80                          VIEW  index$_join$_044 (cr=6 pr=0 pw=0 time=1251 us cost=3 size=1040 card=80)
            80         80         80                           HASH JOIN  (cr=6 pr=0 pw=0 time=1249 us)
            80         80         80                            INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=70 us cost=1 size=1040 card=80)(object id 1354894)
            80         80         80                            INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=135 us cost=1 size=1040 card=80)(object id 1354895)
             0          0          0                         VIEW  (cr=2 pr=0 pw=0 time=295 us cost=10 size=143 card=11)
             0          0          0                          HASH JOIN  (cr=2 pr=0 pw=0 time=293 us cost=8 size=352 card=11)
             0          0          0                           MERGE JOIN  (cr=2 pr=0 pw=0 time=118 us cost=4 size=209 card=11)
             0          0          0                            TABLE ACCESS BY INDEX ROWID TIBEX_HOLIDAYS (cr=2 pr=0 pw=0 time=113 us cost=2 size=26 card=2)
            83         83         83                             INDEX FULL SCAN XPKTIBEX_HOLIDAYS (cr=1 pr=0 pw=0 time=116 us cost=1 size=0 card=83)(object id 1354737)
             0          0          0                            SORT JOIN (cr=0 pr=0 pw=0 time=0 us cost=2 size=2412 card=402)
             0          0          0                             INDEX FULL SCAN XPKTIBEX_HOLIDAYTRADINGCYCLEMA (cr=0 pr=0 pw=0 time=0 us cost=1 size=2412 card=402)(object id 135473
    9)
             0          0          0                           VIEW  index$_join$_049 (cr=0 pr=0 pw=0 time=0 us cost=3 size=1040 card=80)
             0          0          0                            HASH JOIN  (cr=0 pr=0 pw=0 time=0 us)
             0          0          0                             INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354894)
             0          0          0                             INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354895)
            40         40         40                        INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=79 us cost=0 size=4 card=1)(object id 1354895)
            13         13         13                       VIEW  (cr=4 pr=1 pw=0 time=362 us cost=2 size=112 card=16)
            13         13         13                        TABLE ACCESS FULL SYS_TEMP_0FD9D660D_F7392ACA (cr=4 pr=1 pw=0 time=349 us cost=2 size=1216 card=16)
           275        275        275                      TABLE ACCESS FULL TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=164 us cost=5 size=3025 card=275)
             0          0          0                     TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=136 us cost=0 size=39 card=1)
             0          0          0                      INDEX UNIQUE SCAN XPKTIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=52 us cost=0 size=0 card=1)(object id 1354925)
            78         78         78                    TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGPERIOD (cr=82 pr=0 pw=0 time=343 us cost=1 size=7 card=1)
            78         78         78                     INDEX UNIQUE SCAN XPKTIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=144 us cost=0 size=0 card=1)(object id 1354899)
            13         13         13                   TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGMETHODENUM (cr=82 pr=0 pw=0 time=252 us cost=1 size=14 card=1)
            78         78         78                    INDEX UNIQUE SCAN XPKTIBEX_TRADINGMETHODENUM (cr=4 pr=0 pw=0 time=98 us cost=0 size=0 card=1)(object id 1354897)
             0          0          0                             INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354895)
            40         40         40                        INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=79 us cost=0 size=4 card=1)(object id 1354895)
            13         13         13                       VIEW  (cr=4 pr=1 pw=0 time=362 us cost=2 size=112 card=16)
            13         13         13                        TABLE ACCESS FULL SYS_TEMP_0FD9D660D_F7392ACA (cr=4 pr=1 pw=0 time=349 us cost=2 size=1216 card=16)
           275        275        275                      TABLE ACCESS FULL TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=164 us cost=5 size=3025 card=275)
             0          0          0                     TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=136 us cost=0 size=39 card=1)
             0          0          0                      INDEX UNIQUE SCAN XPKTIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=52 us cost=0 size=0 card=1)(object id 1354925)
            78         78         78                    TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGPERIOD (cr=82 pr=0 pw=0 time=343 us cost=1 size=7 card=1)
            78         78         78                     INDEX UNIQUE SCAN XPKTIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=144 us cost=0 size=0 card=1)(object id 1354899)
            13         13         13                   TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGMETHODENUM (cr=82 pr=0 pw=0 time=252 us cost=1 size=14 card=1)
            78         78         78                    INDEX UNIQUE SCAN XPKTIBEX_TRADINGMETHODENUM (cr=4 pr=0 pw=0 time=98 us cost=0 size=0 card=1)(object id 1354897)
           275        275        275                MERGE JOIN OUTER (cr=3 pr=0 pw=0 time=892 us cost=5 size=17875 card=275)
           275        275        275                 TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=401 us cost=2 size=4950 card=275)
           275        275        275                  INDEX FULL SCAN XPKTIBEX_CYCLEPERIODMAP (cr=1 pr=0 pw=0 time=115 us cost=1 size=0 card=275)(object id 1354681)
             0          0          0                 SORT JOIN (cr=1 pr=0 pw=0 time=207 us cost=3 size=47 card=1)
             0          0          0                  TABLE ACCESS FULL TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=17 us cost=2 size=47 card=1)
            13         13         13               INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=349 us cost=0 size=4 card=1)(object id 1354895)
            13         13         13              VIEW  (cr=2 pr=0 pw=0 time=52 us cost=2 size=336 card=16)
            13         13         13               TABLE ACCESS FULL SYS_TEMP_0FD9D660D_F7392ACA (cr=2 pr=0 pw=0 time=49 us cost=2 size=1216 card=16)
          1473       1473       1473             INDEX RANGE SCAN XPKTIBEX_INSTRUMENTBOARDMAP (cr=19 pr=1 pw=0 time=1378 us cost=1 size=504 card=36)(object id 1354759)
         13877      13877      13877            TABLE ACCESS BY INDEX ROWID TIBEX_INSTRUMENTADMIN (cr=33390 pr=53 pw=0 time=2023879 us cost=27 size=103 card=1)
         44576      44576      44576             INDEX RANGE SCAN SYS_C001331991 (cr=1277 pr=53 pw=0 time=43026 us cost=1 size=0 card=35)(object id 1354964)
         12435      12435      12435           TABLE ACCESS BY INDEX ROWID TIBEX_INSTRACTIONENUM (cr=13881 pr=0 pw=0 time=81117 us cost=1 size=14 card=1)
         13877      13877      13877            INDEX UNIQUE SCAN XPKTIBEX_INSTRACTIONENUM (cr=4 pr=0 pw=0 time=32628 us cost=0 size=0 card=1)(object id 1354753)
        497400     497400     497400          BUFFER SORT (cr=1 pr=0 pw=0 time=323076 us cost=106 size=280 card=40)
            40         40         40           INDEX RANGE SCAN XPKTIBEX_DAYSTRADINGCYCLEMAP (cr=1 pr=0 pw=0 time=61 us cost=1 size=280 card=40)(object id 1354685)
        497400     497400     497400         TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGCYCLE (cr=497404 pr=0 pw=0 time=2609562 us cost=1 size=13 card=1)
        497400     497400     497400          INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=1019970 us cost=0 size=0 card=1)(object id 1354895)
             0          0          0        VIEW PUSHED PREDICATE  (cr=994800 pr=0 pw=0 time=151415026 us cost=1 size=13 card=1)
             0          0          0         HASH JOIN  (cr=994800 pr=0 pw=0 time=150806856 us cost=7 size=32 card=1)
             0          0          0          MERGE JOIN  (cr=994800 pr=0 pw=0 time=19714460 us cost=4 size=209 card=11)
             0          0          0           TABLE ACCESS BY INDEX ROWID TIBEX_HOLIDAYS (cr=994800 pr=0 pw=0 time=18729534 us cost=2 size=26 card=2)
      41284200   41284200   41284200            INDEX FULL SCAN XPKTIBEX_HOLIDAYS (cr=497400 pr=0 pw=0 time=16264606 us cost=1 size=0 card=83)(object id 1354737)
             0          0          0           SORT JOIN (cr=0 pr=0 pw=0 time=0 us cost=2 size=2412 card=402)
             0          0          0            INDEX FULL SCAN XPKTIBEX_HOLIDAYTRADINGCYCLEMA (cr=0 pr=0 pw=0 time=0 us cost=1 size=2412 card=402)(object id 1354739)
             0          0          0          TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=2 size=26 card=2)
             0          0          0           INDEX RANGE SCAN XAK1TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=2)(object id 1354894)
         12435      12435      12435      INDEX UNIQUE SCAN XPKTIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=33106 us cost=0 size=4 card=1)(object id 1354899)
           464        464        464    HASH JOIN SEMI (cr=386 pr=190 pw=0 time=30227 us cost=6 size=331 card=1)
          5684       5684       5684     VIEW  (cr=194 pr=190 pw=0 time=8864 us cost=2 size=582 card=2)
         12435      12435      12435      TABLE ACCESS FULL SYS_TEMP_0FD9D660E_F7392ACA (cr=194 pr=190 pw=0 time=9137 us cost=2 size=272 card=2)
          1267       1267       1267     VIEW  VW_NSO_2 (cr=192 pr=0 pw=0 time=13710 us cost=3 size=80 card=2)
          1267       1267       1267      HASH GROUP BY (cr=192 pr=0 pw=0 time=13074 us cost=3 size=38 card=2)
         12435      12435      12435       VIEW  (cr=192 pr=0 pw=0 time=11843 us cost=2 size=38 card=2)
         12435      12435      12435        TABLE ACCESS FULL SYS_TEMP_0FD9D660E_F7392ACA (cr=192 pr=0 pw=0 time=5751 us cost=2 size=272 card=2)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      Disk file operations I/O                        1        0.00          0.00
      direct path write temp                          2        0.00          0.00
      direct path sync                                1        0.00          0.00
      db file sequential read                        55        0.00          0.00
      SQL*Net message to client                       6        0.00          0.00
      db file scattered read                          2        0.00          0.00
      SQL*Net message from client                     6        0.00          0.00Regards
    NM

    Hi,
    Execution Plan after generating stats on TIBEX_TRADINGCYCLE.
    Execution Plan
    Plan hash value: 1209012613
    | Id  | Operation                                               | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                                        |                                |     1 |   291 |   130   (7)| 00:00:02 |
    |   1 |  VIEW                                                   | TIBEX_OPENINGHOMEMKTOK         |     1 |   291 |   130   (7)| 00:00:02 |
    |   2 |   TEMP TABLE TRANSFORMATION                             |                                |       |       |            |          |
    |   3 |    LOAD AS SELECT                                       | SYS_TEMP_0FD9D662B_FB42A6E1    |       |       |            |          |
    |*  4 |     HASH JOIN                                           |                                |     8 |  1392 |    27  (12)| 00:00:01 |
    |*  5 |      TABLE ACCESS FULL                                  | TIBEX_TRADINGMETHODENUM        |     1 |    14 |     5   (0)| 00:00:01 |
    |*  6 |      HASH JOIN                                          |                                |   138 | 22080 |    21  (10)| 00:00:01 |
    |   7 |       NESTED LOOPS OUTER                                |                                |   138 | 16284 |    14  (15)| 00:00:01 |
    |*  8 |        HASH JOIN                                        |                                |   138 |  9798 |    14  (15)| 00:00:01 |
    |*  9 |         HASH JOIN                                       |                                |    40 |  2120 |     8  (13)| 00:00:01 |
    |  10 |          NESTED LOOPS OUTER                             |                                |    40 |  1240 |     5   (0)| 00:00:01 |
    |  11 |           NESTED LOOPS                                  |                                |    40 |   800 |     3  (34)| 00:00:01 |
    |  12 |            VIEW                                         | index$_join$_018               |    80 |  1040 |     3  (34)| 00:00:01 |
    |* 13 |             HASH JOIN                                   |                                |       |       |            |          |
    |  14 |              INDEX FAST FULL SCAN                       | XAK1TIBEX_TRADINGCYCLE         |    80 |  1040 |     1   (0)| 00:00:01 |
    |  15 |              INDEX FAST FULL SCAN                       | XPKTIBEX_TRADINGCYCLE          |    80 |  1040 |     1   (0)| 00:00:01 |
    |* 16 |            INDEX UNIQUE SCAN                            | XPKTIBEX_DAYSTRADINGCYCLEMAP   |     1 |     7 |     0   (0)| 00:00:01 |
    |  17 |           VIEW PUSHED PREDICATE                         |                                |     1 |    11 |     1   (0)| 00:00:01 |
    |* 18 |            HASH JOIN                                    |                                |     1 |    32 |     7  (29)| 00:00:01 |
    |  19 |             MERGE JOIN                                  |                                |     3 |    57 |     4  (25)| 00:00:01 |
    |* 20 |              TABLE ACCESS BY INDEX ROWID                | TIBEX_HOLIDAYS                 |     1 |    13 |     2   (0)| 00:00:01 |
    |  21 |               INDEX FULL SCAN                           | XPKTIBEX_HOLIDAYS              |    83 |       |     1   (0)| 00:00:01 |
    |* 22 |              SORT JOIN                                  |                                |   402 |  2412 |     2  (50)| 00:00:01 |
    |  23 |               INDEX FULL SCAN                           | XPKTIBEX_HOLIDAYTRADINGCYCLEMA |   402 |  2412 |     1   (0)| 00:00:01 |
    |  24 |             TABLE ACCESS BY INDEX ROWID                 | TIBEX_TRADINGCYCLE             |     2 |    26 |     2   (0)| 00:00:01 |
    |* 25 |              INDEX RANGE SCAN                           | XAK1TIBEX_TRADINGCYCLE         |     2 |       |     1   (0)| 00:00:01 |
    |  26 |          VIEW                                           | index$_join$_024               |    80 |  1760 |     3  (34)| 00:00:01 |
    |* 27 |           HASH JOIN                                     |                                |       |       |            |          |
    |  28 |            INDEX FAST FULL SCAN                         | XAK1TIBEX_TRADINGCYCLE         |    80 |  1760 |     1   (0)| 00:00:01 |
    |  29 |            INDEX FAST FULL SCAN                         | XPKTIBEX_TRADINGCYCLE          |    80 |  1760 |     1   (0)| 00:00:01 |
    |  30 |         TABLE ACCESS FULL                               | TIBEX_CYCLEPERIODMAP           |   275 |  4950 |     5   (0)| 00:00:01 |
    |  31 |        TABLE ACCESS BY INDEX ROWID                      | TIBEX_CYCLEPERIODMAPOVER       |     1 |    47 |     0   (0)| 00:00:01 |
    |* 32 |         INDEX UNIQUE SCAN                               | XPKTIBEX_CYCLEPERIODMAPOVER    |     1 |       |     0   (0)| 00:00:01 |
    |  33 |       TABLE ACCESS FULL                                 | TIBEX_TRADINGPERIOD            |   330 | 13860 |     7   (0)| 00:00:01 |
    |  34 |    LOAD AS SELECT                                       | SYS_TEMP_0FD9D662C_FB42A6E1    |       |       |            |          |
    |  35 |     NESTED LOOPS                                        |                                |     1 |   282 |    98   (5)| 00:00:02 |
    |* 36 |      FILTER                                             |                                |       |       |            |          |
    |  37 |       NESTED LOOPS OUTER                                |                                |     1 |   278 |    98   (5)| 00:00:02 |
    |  38 |        NESTED LOOPS                                     |                                |     1 |   267 |    97   (5)| 00:00:02 |
    |  39 |         MERGE JOIN CARTESIAN                            |                                |     1 |   254 |    96   (5)| 00:00:02 |
    |  40 |          NESTED LOOPS                                   |                                |       |       |            |          |
    |  41 |           NESTED LOOPS                                  |                                |     1 |   247 |    95   (5)| 00:00:02 |
    |  42 |            NESTED LOOPS                                 |                                |     1 |   233 |    94   (5)| 00:00:02 |
    |  43 |             NESTED LOOPS                                |                                |     3 |   390 |    24  (17)| 00:00:01 |
    |* 44 |              HASH JOIN                                  |                                |     1 |   116 |    23  (18)| 00:00:01 |
    |  45 |               NESTED LOOPS                              |                                |     1 |    95 |    21  (20)| 00:00:01 |
    |  46 |                NESTED LOOPS OUTER                       |                                |    31 |  2821 |    21  (20)| 00:00:01 |
    |  47 |                 NESTED LOOPS                            |                                |    31 |  1364 |    21  (20)| 00:00:01 |
    |  48 |                  VIEW                                   | VW_NSO_1                       |     1 |    26 |    18  (17)| 00:00:01 |
    |  49 |                   SORT GROUP BY                         |                                |     1 |   113 |    18  (17)| 00:00:01 |
    |  50 |                    NESTED LOOPS ANTI                    |                                |     1 |   113 |    17  (12)| 00:00:01 |
    |  51 |                     NESTED LOOPS                        |                                |     1 |    99 |    16  (13)| 00:00:01 |
    |  52 |                      NESTED LOOPS OUTER                 |                                |     1 |    92 |    15  (14)| 00:00:01 |
    |* 53 |                       HASH JOIN                         |                                |     1 |    53 |    15  (14)| 00:00:01 |
    |* 54 |                        HASH JOIN                        |                                |     8 |   336 |     9  (12)| 00:00:01 |
    |  55 |                         NESTED LOOPS                    |                                |    40 |  1400 |     7  (15)| 00:00:01 |
    |  56 |                          NESTED LOOPS OUTER             |                                |    40 |  1240 |     7  (15)| 00:00:01 |
    |* 57 |                           HASH JOIN                     |                                |    40 |   800 |     4  (25)| 00:00:01 |
    |* 58 |                            INDEX RANGE SCAN             | XPKTIBEX_DAYSTRADINGCYCLEMAP   |    40 |   280 |     1   (0)| 00:00:01 |
    |  59 |                            VIEW                         | index$_join$_044               |    80 |  1040 |     3  (34)| 00:00:01 |
    |* 60 |                             HASH JOIN                   |                                |       |       |            |          |
    |  61 |                              INDEX FAST FULL SCAN       | XAK1TIBEX_TRADINGCYCLE         |    80 |  1040 |     1   (0)| 00:00:01 |
    |  62 |                              INDEX FAST FULL SCAN       | XPKTIBEX_TRADINGCYCLE          |    80 |  1040 |     1   (0)| 00:00:01 |
    |  63 |                           VIEW PUSHED PREDICATE         |                                |     1 |    11 |     1   (0)| 00:00:01 |
    |* 64 |                            HASH JOIN                    |                                |     1 |    32 |     7  (29)| 00:00:01 |
    |  65 |                             MERGE JOIN                  |                                |     3 |    57 |     4  (25)| 00:00:01 |
    |* 66 |                              TABLE ACCESS BY INDEX ROWID| TIBEX_HOLIDAYS                 |     1 |    13 |     2   (0)| 00:00:01 |
    |  67 |                               INDEX FULL SCAN           | XPKTIBEX_HOLIDAYS              |    83 |       |     1   (0)| 00:00:01 |
    |* 68 |                              SORT JOIN                  |                                |   402 |  2412 |     2  (50)| 00:00:01 |
    |  69 |                               INDEX FULL SCAN           | XPKTIBEX_HOLIDAYTRADINGCYCLEMA |   402 |  2412 |     1   (0)| 00:00:01 |
    |  70 |                             TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGCYCLE             |     2 |    26 |     2   (0)| 00:00:01 |
    |* 71 |                              INDEX RANGE SCAN           | XAK1TIBEX_TRADINGCYCLE         |     2 |       |     1   (0)| 00:00:01 |
    |* 72 |                          INDEX UNIQUE SCAN              | XPKTIBEX_TRADINGCYCLE          |     1 |     4 |     0   (0)| 00:00:01 |
    |  73 |                         VIEW                            |                                |    16 |   112 |     2   (0)| 00:00:01 |
    |  74 |                          TABLE ACCESS FULL              | SYS_TEMP_0FD9D662B_FB42A6E1    |    16 |  1216 |     2   (0)| 00:00:01 |
    |  75 |                        TABLE ACCESS FULL                | TIBEX_CYCLEPERIODMAP           |   275 |  3025 |     5   (0)| 00:00:01 |
    |  76 |                       TABLE ACCESS BY INDEX ROWID       | TIBEX_CYCLEPERIODMAPOVER       |     1 |    39 |     0   (0)| 00:00:01 |
    |* 77 |                        INDEX UNIQUE SCAN                | XPKTIBEX_CYCLEPERIODMAPOVER    |     1 |       |     0   (0)| 00:00:01 |
    |  78 |                      TABLE ACCESS BY INDEX ROWID        | TIBEX_TRADINGPERIOD            |     1 |     7 |     1   (0)| 00:00:01 |
    |* 79 |                       INDEX UNIQUE SCAN                 | XPKTIBEX_TRADINGPERIOD         |     1 |       |     0   (0)| 00:00:01 |
    |* 80 |                     TABLE ACCESS BY INDEX ROWID         | TIBEX_TRADINGMETHODENUM        |     1 |    14 |     1   (0)| 00:00:01 |
    |* 81 |                      INDEX UNIQUE SCAN                  | XPKTIBEX_TRADINGMETHODENUM     |     1 |       |     0   (0)| 00:00:01 |
    |  82 |                  TABLE ACCESS BY INDEX ROWID            | TIBEX_CYCLEPERIODMAP           |    31 |   558 |     2   (0)| 00:00:01 |
    |* 83 |                   INDEX SKIP SCAN                       | XPKTIBEX_CYCLEPERIODMAP        |    31 |       |     1   (0)| 00:00:01 |
    |  84 |                 TABLE ACCESS BY INDEX ROWID             | TIBEX_CYCLEPERIODMAPOVER       |     1 |    47 |     0   (0)| 00:00:01 |
    |* 85 |                  INDEX UNIQUE SCAN                      | XPKTIBEX_CYCLEPERIODMAPOVER    |     1 |       |     0   (0)| 00:00:01 |
    |* 86 |                INDEX UNIQUE SCAN                        | XPKTIBEX_TRADINGCYCLE          |     1 |     4 |     0   (0)| 00:00:01 |
    |  87 |               VIEW                                      |                                |    16 |   336 |     2   (0)| 00:00:01 |
    |  88 |                TABLE ACCESS FULL                        | SYS_TEMP_0FD9D662B_FB42A6E1    |    16 |  1216 |     2   (0)| 00:00:01 |
    |* 89 |              INDEX RANGE SCAN                           | XPKTIBEX_INSTRUMENTBOARDMAP    |    36 |   504 |     1   (0)| 00:00:01 |
    |* 90 |             TABLE ACCESS BY INDEX ROWID                 | TIBEX_INSTRUMENTADMIN          |     1 |   103 |    27   (0)| 00:00:01 |
    |* 91 |              INDEX RANGE SCAN                           | SYS_C001331991                 |    35 |       |     1   (0)| 00:00:01 |
    |* 92 |            INDEX UNIQUE SCAN                            | XPKTIBEX_INSTRACTIONENUM       |     1 |       |     0   (0)| 00:00:01 |
    |* 93 |           TABLE ACCESS BY INDEX ROWID                   | TIBEX_INSTRACTIONENUM          |     1 |    14 |     1   (0)| 00:00:01 |
    |  94 |          BUFFER SORT                                    |                                |    40 |   280 |    95   (5)| 00:00:02 |
    |* 95 |           INDEX RANGE SCAN                              | XPKTIBEX_DAYSTRADINGCYCLEMAP   |    40 |   280 |     1   (0)| 00:00:01 |
    |  96 |         TABLE ACCESS BY INDEX ROWID                     | TIBEX_TRADINGCYCLE             |     1 |    13 |     1   (0)| 00:00:01 |
    |* 97 |          INDEX UNIQUE SCAN                              | XPKTIBEX_TRADINGCYCLE          |     1 |       |     0   (0)| 00:00:01 |
    |  98 |        VIEW PUSHED PREDICATE                            |                                |     1 |    11 |     1   (0)| 00:00:01 |
    |* 99 |         HASH JOIN                                       |                                |     1 |    32 |     7  (29)| 00:00:01 |
    | 100 |          MERGE JOIN                                     |                                |     3 |    57 |     4  (25)| 00:00:01 |
    |*101 |           TABLE ACCESS BY INDEX ROWID                   | TIBEX_HOLIDAYS                 |     1 |    13 |     2   (0)| 00:00:01 |
    | 102 |            INDEX FULL SCAN                              | XPKTIBEX_HOLIDAYS              |    83 |       |     1   (0)| 00:00:01 |
    |*103 |           SORT JOIN                                     |                                |   402 |  2412 |     2  (50)| 00:00:01 |
    | 104 |            INDEX FULL SCAN                              | XPKTIBEX_HOLIDAYTRADINGCYCLEMA |   402 |  2412 |     1   (0)| 00:00:01 |
    | 105 |          TABLE ACCESS BY INDEX ROWID                    | TIBEX_TRADINGCYCLE             |     2 |    26 |     2   (0)| 00:00:01 |
    |*106 |           INDEX RANGE SCAN                              | XAK1TIBEX_TRADINGCYCLE         |     2 |       |     1   (0)| 00:00:01 |
    |*107 |      INDEX UNIQUE SCAN                                  | XPKTIBEX_TRADINGPERIOD         |     1 |     4 |     0   (0)| 00:00:01 |
    |*108 |    HASH JOIN SEMI                                       |                                |     1 |   331 |     6  (34)| 00:00:01 |
    |*109 |     VIEW                                                |                                |     2 |   582 |     2   (0)| 00:00:01 |
    | 110 |      TABLE ACCESS FULL                                  | SYS_TEMP_0FD9D662C_FB42A6E1    |     2 |   272 |     2   (0)| 00:00:01 |
    | 111 |     VIEW                                                | VW_NSO_2                       |     2 |    80 |     3  (34)| 00:00:01 |
    | 112 |      HASH GROUP BY                                      |                                |     2 |    38 |     3  (34)| 00:00:01 |
    | 113 |       VIEW                                              |                                |     2 |    38 |     2   (0)| 00:00:01 |
    | 114 |        TABLE ACCESS FULL                                | SYS_TEMP_0FD9D662C_FB42A6E1    |     2 |   272 |     2   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------------------------------------------------------

  • Current running SQL stms execution plan?

    Hi,
    Is it any ways to findout the current running SQL stms execution plan?
    without using Explain plan & autotrace.
    Thanks in advance,
    Thomas.

    I'm using this code. You just have to give the Session Identifier (&SID ):SELECT     '| Operation                                     |  Objet   | Lignes| Bytes|  Cout  | Pstart| Pstop |' as "Plan Table"  FROM DUAL
    UNION ALL
    SELECT     '----------------------------------------------------------------------------------------------------' FROM DUAL
    UNION ALL
    SELECT * FROM
             (SELECT /*+ NO_MERGE */
              RPAD('| '||
                   SUBSTR(
                        LPAD(' ',1*(LEVEL-1)) || OPERATION || DECODE(OPTIONS, NULL,'',' '||OPTIONS), 1, 47
                         ), 48, ' '
              )||'|'||
              RPAD(
                   SUBSTR(OBJECT_NAME||' ',1, 9), 10, ' '
              )||'|'||
              LPAD(
                   DECODE(CARDINALITY,
                        NULL,'  ',
                        DECODE(SIGN(CARDINALITY-1000),
                              -1, CARDINALITY||' ',
                             DECODE(SIGN(CARDINALITY-1000000),
                                   -1,TRUNC(CARDINALITY/1000)||'K',
                                  DECODE(SIGN(CARDINALITY-1000000000),
                                       -1,TRUNC(CARDINALITY/1000000)||'M',
                                       TRUNC(CARDINALITY/1000000000)||'G')
                        ), 7, ' '
              )||'|'||
              LPAD(
                   DECODE(BYTES,
                        NULL,' ',
                        DECODE(SIGN(BYTES-1024),
                             -1, BYTES||' ',
                             DECODE(SIGN(BYTES-1048576),
                                  -1, TRUNC(BYTES/1024)||'K',
                                  DECODE(SIGN(BYTES-1073741824),
                                       -1,TRUNC(BYTES/1048576)||'M',
                                       TRUNC(BYTES/1073741824)||'G')
                        ), 6, ' '
              )||'|'||
              LPAD(
                   DECODE(COST,
                        NULL,' ',
                        DECODE(SIGN(COST-10000000),
                             -1, COST||' ',
                             DECODE(SIGN(COST-1000000000),
                                  -1, TRUNC(COST/1000000)||'M',
                                  TRUNC(COST/1000000000)||'G')
                        ), 8, ' '
              )||'|'||
              LPAD(
                   DECODE(PARTITION_START,
                        'ROW LOCATION', 'ROWID',
                        DECODE(PARTITION_START,
                             'KEY', 'KEY',
                             DECODE(PARTITION_START,
                                  'KEY(INLIST)', 'KEY(I)',
                                  DECODE(SUBSTR(PARTITION_START, 1, 6),
                                       'NUMBER', SUBSTR(SUBSTR(PARTITION_START, 8, 10), 1,LENGTH(SUBSTR(PARTITION_START, 8, 10))-1),
                                       DECODE(PARTITION_START,
                                            NULL,' ',
                                            PARTITION_START)
                        )||' ', 7, ' '
              )||'|'||
              LPAD(
                   DECODE(PARTITION_STOP,
                        'ROW LOCATION', 'ROW L',
                        DECODE(PARTITION_STOP,
                             'KEY', 'KEY',
                             DECODE(PARTITION_STOP,
                                  'KEY(INLIST)', 'KEY(I)',
                                  DECODE(SUBSTR(PARTITION_STOP, 1, 6),
                                  'NUMBER', SUBSTR(SUBSTR(PARTITION_STOP, 8, 10), 1,LENGTH(SUBSTR(PARTITION_STOP, 8, 10))-1),
                                  DECODE(PARTITION_STOP,
                                       NULL,' ',
                                       PARTITION_STOP)
                   )||' ', 7, ' '
              )||'|' AS "Explain plan"
         FROM V$SQL_PLAN
         START WITH (ADDRESS = (SELECT SQL_ADDRESS FROM V$SESSION WHERE SID=&SID)
                   AND HASH_VALUE = (SELECT SQL_HASH_VALUE FROM V$SESSION WHERE SID=&SID)
                   AND CHILD_NUMBER = 0
                   AND ID=0 )
         CONNECT BY PRIOR ID = PARENT_ID
                        AND PRIOR ADDRESS = ADDRESS
                        AND PRIOR HASH_VALUE = HASH_VALUE
                        AND PRIOR CHILD_NUMBER = CHILD_NUMBER
         ORDER BY ID, POSITION)
    UNION ALL
    SELECT '----------------------------------------------------------------------------------------------------' FROM DUAL;Regards,
    Yoann.

Maybe you are looking for

  • Itunes won't let me access my account! HELP!!!!

    I updated Itunes and when I went to login, it posted an error saying, "We could not complete your Itunes Store request. A secure network connection could not be established. Check that your computers' time and date are correct and try again." I check

  • How to browse data in memory

    If I type statement  "import r_track from memory id 'IRTRACKNO' ", how do I browse the object "IRTRACKNO" value. Thanks

  • Question about returning online items...

    Just to confirm, the 15-day timeframe begins when the item is delivered to the residence, correct? Not when the order is initially placed?

  • My new mac and old mac are linked, and I don't want them to be!

    I had a mac and I gave it to someone and I now have a new mac which I set up in the same way. I have noticed that my internet bookmarks that I created on my old mac have been carried over, but I can see the bookmarks that the current user of the othe

  • ACTIVATE SUBTITLES USING SCRIPT

    Creating subtitle script in Apple's DVD Studio Pro. To anyone who can help, this is what we are trying to accomplish in Apple's DVD Studio Pro. We want to create a script that will allow us to turn on / activate subtitles using some type of memory re