Strange query / explain plan

(I posted this in the Oracle Text forum, but I think it's as appropriate here.)
Consider the following queries:
:the_filter := 'FILE';
(1)
SELECT COUNT(*)
FROM FOO
WHERE CONTAINS(search_col,:the_filter) > 0;
(2)
SELECT COUNT(*)
FROM FOO
WHERE 'FILE' IS NULL OR CONTAINS(search_col,:the_filter) > 0;
(3)
SELECT COUNT(*)
FROM FOO
WHERE :the_filter IS NULL OR CONTAINS(search_col,:the_filter) > 0;
(1) and (2) use the text index and run normally, but (3) does a full table scan, but I don't understand why.
The reason behind my using a query of the form (3) is to say 'keep the record if the filter is null or the record contains the filter'. I'm using the filter as a switch, and (3) is actually a simplified form of a complex query with several tables and filters. How can I do this without the query using a full table scan?
Below is the script and a record of the full session:
SET ECHO ON;
SET TIMING ON;
DROP TABLE FOO;
CREATE TABLE FOO (search_col VARCHAR2(100));
-- Loads of dummy data
INSERT INTO FOO (search_col) SELECT OBJECT_NAME || ' ' || OBJECT_TYPE
FROM ALL_OBJECTS WHERE ROWNUM <= 20000;
COMMIT;
CREATE INDEX I1 ON FOO(search_col) INDEXTYPE IS CTXSYS.CONTEXT
PARAMETERS(' section group ctxsys.html_section_group');
variable the_filter varchar2(100);
begin
:the_filter := 'FILE';
end;
SET AUTOTRACE ON EXPLAIN;
SELECT COUNT(*)
FROM FOO
WHERE CONTAINS(search_col,:the_filter) > 0;
SELECT COUNT(*)
FROM FOO
WHERE 'FILE' IS NULL OR CONTAINS(search_col,:the_filter) > 0;
SELECT COUNT(*)
FROM FOO
WHERE :the_filter IS NULL OR CONTAINS(search_col,:the_filter) > 0;
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Nov 21 11:21:22 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
SQL> SET TIMING ON;
SQL> DROP TABLE FOO;
Table dropped.
Elapsed: 00:00:00.73
SQL> CREATE TABLE FOO (search_col VARCHAR2(100));
Table created.
Elapsed: 00:00:00.03
SQL> -- Loads of dummy data
SQL> INSERT INTO FOO (search_col) SELECT OBJECT_NAME || ' ' || OBJECT_TYPE
2 FROM ALL_OBJECTS WHERE ROWNUM <= 20000;
20000 rows created.
Elapsed: 00:00:01.92
SQL> COMMIT;
Commit complete.
Elapsed: 00:00:00.01
SQL> CREATE INDEX I1 ON FOO(search_col) INDEXTYPE IS CTXSYS.CONTEXT
2 PARAMETERS(' section group ctxsys.html_section_group');
Index created.
Elapsed: 00:00:10.76
SQL> variable the_filter varchar2(100);
SQL> begin
2 :the_filter := 'FILE';
3 end;
4 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
SQL> SET AUTOTRACE ON EXPLAIN;
SQL> SELECT COUNT(*)
2 FROM FOO
3 WHERE CONTAINS(search_col,:the_filter) > 0;
COUNT(*)
29
Elapsed: 00:00:00.07
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=59)
1 0 SORT (AGGREGATE)
2 1 DOMAIN INDEX OF 'I1' (Cost=0 Card=1 Bytes=59)
SQL> SELECT COUNT(*)
2 FROM FOO
3 WHERE 'FILE' IS NULL OR CONTAINS(search_col,:the_filter) > 0;
COUNT(*)
29
Elapsed: 00:00:00.08
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=59)
1 0 SORT (AGGREGATE)
2 1 DOMAIN INDEX OF 'I1' (Cost=0 Card=1 Bytes=59)
SQL> SELECT COUNT(*)
2 FROM FOO
3 WHERE :the_filter IS NULL OR CONTAINS(search_col,:the_filter) > 0;
COUNT(*)
29
Elapsed: 00:00:04.06
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=34482 Card=1 Bytes=5
9)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'FOO' (Cost=34482 Card=453 Bytes=
26727)

Nothing is really strange when you are attempting to integrate with legacy systems! =)
If no numerical processing is done why should numerical values be stored as numbers?

Similar Messages

  • Performance problem: Query explain plan changes in pl/sql vs. literal args

    I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
    select * from largeTable large
    join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
    join...(other aux tables)
    where large.pk_id between 123 and 456;
    Its performance was excellent with literal arguments (1 sec per execution).
    But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
    Ex:
    CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
    CURSOR LT_CURSOR IS
    select * from largeTable large
    join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
    join...(other aux tables)
    where large.pk_id between param1 AND param2;
    BEGIN
    FOR aRecord IN LT_CURSOR
    LOOP
    (print timestamp...)
    END LOOP;
    END runQuery;
    Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
    Solution:
    Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
    Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
    Downside: Query not cached for future use. Perfectly fine for this query's purpose.
    Other suggestions are welcome.

    AmandaSoosai wrote:
    I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
    select * from largeTable large
    join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
    join...(other aux tables)
    where large.pk_id between 123 and 456;
    Its performance was excellent with literal arguments (1 sec per execution).
    But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
    Ex:
    CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
    CURSOR LT_CURSOR IS
    select * from largeTable large
    join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
    join...(other aux tables)
    where large.pk_id between param1 AND param2;
    BEGIN
    FOR aRecord IN LT_CURSOR
    LOOP
    (print timestamp...)
    END LOOP;
    END runQuery;
    Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
    Solution:
    Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
    Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
    Downside: Query not cached for future use. Perfectly fine for this query's purpose.
    Other suggestions are welcome.Best wild guess based on what you've posted is a bind variable mismatch (your column is declared as a NUMBER data type and your bind variable is declared as a VARCHAR for example). Unless you have histograms on the columns in question ... which, if you're using bind variables is usually a really bad idea.
    A basic illustration of my guess
    http://blogs.oracle.com/optimizer/entry/how_do_i_get_sql_executed_from_an_application_to_uses_the_same_execution_plan_i_get_from_sqlplus

  • Query Explain Plan Help

    I am running the following query against my database
    SELECT p.ID
      FROM rap_counterparties cou,
           rap_presentation_cou_ratings pcr,
           rap_presentation_states sta,
           rap_app_user_profiles aup,
           rap_presentations p
    WHERE cou.unt_id = aup.unt_id
       AND aup.aur_id = 7529
       AND pcr.cou_id = cou.ID
       AND sta.cur_present_state_instance_flg = 'Y'
       AND sta.state_type_id = pcr.pst_state_type_id
       AND sta.pre_id = pcr.pst_pre_id
       AND sta.state_type_id IN (326, 322, 323, 324, 325)
       AND cou.unt_id = p.unt_id
       AND p.ID = sta.pre_id
       AND (   p.private_flg != 'Y'
            OR (p.private_flg = 'Y' AND p.created_by_user_id = 10000083)
    Explain plan of the query is
    PLAN_TABLE_OUTPUT
    | Id  | Operation                        |  Name                  | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT                 |                        |     8 |   456 |  3936  (16)|
    |*  1 |  TABLE ACCESS BY INDEX ROWID     | RAP_PRESENTATIONS      |     1 |    15 |     2  (50)|
    |   2 |   NESTED LOOPS                   |                        |     8 |   456 |  3936  (16)|
    |*  3 |    HASH JOIN                     |                        |  1745 | 73290 |  2145  (27)|
    |*  4 |     HASH JOIN                    |                        | 14257 |   431K|  1299  (25)|
    |*  5 |      HASH JOIN                   |                        |  5173 | 87941 |   583  (16)|
    |   6 |       TABLE ACCESS BY INDEX ROWID| RAP_APP_USER_PROFILES  |    18 |   144 |     3  (34)|
    |*  7 |        INDEX RANGE SCAN          | RAP_AUP_IX_01          |    18 |       |     2  (50)|
    |   8 |       TABLE ACCESS FULL          | RAP_COUNTERPARTIES     |   118K|  1042K|   560  (13)|
    |*  9 |      INDEX FAST FULL SCAN        | RAP_PCR_PK             |   326K|  4467K|   659  (25)|
    |* 10 |     INDEX FAST FULL SCAN         | RAP_PST_IX_02          |   120K|  1291K|   821  (29)|
    |* 11 |    INDEX RANGE SCAN              | RAP_PRE_PK             |     1 |       |            |
    Predicate Information (identified by operation id):
       1 - filter(("P"."PRIVATE_FLG"<>'Y' OR "P"."CREATED_BY_USER_ID"=10000083 AND
                  "P"."PRIVATE_FLG"='Y') AND "COU"."UNT_ID"="P"."UNT_ID")
       3 - access("STA"."STATE_TYPE_ID"="PCR"."PST_STATE_TYPE_ID" AND
                  "STA"."PRE_ID"="PCR"."PST_PRE_ID")
       4 - access("PCR"."COU_ID"="COU"."ID")
       5 - access("COU"."UNT_ID"="AUP"."UNT_ID")
       7 - access("AUP"."AUR_ID"=7529)
       9 - filter("PCR"."PST_STATE_TYPE_ID"=322 OR "PCR"."PST_STATE_TYPE_ID"=323 OR
                  "PCR"."PST_STATE_TYPE_ID"=324 OR "PCR"."PST_STATE_TYPE_ID"=325 OR "PCR"."PST_STATE_TYPE_ID"=326)
      10 - filter("STA"."CUR_PRESENT_STATE_INSTANCE_FLG"='Y' AND ("STA"."STATE_TYPE_ID"=322 OR
                  "STA"."STATE_TYPE_ID"=323 OR "STA"."STATE_TYPE_ID"=324 OR "STA"."STATE_TYPE_ID"=325 OR
                  "STA"."STATE_TYPE_ID"=326))
      11 - access("P"."ID"="STA"."PRE_ID")
    Table Row count
    rap_app_user_profiles : 30639
    rap_counterparties : 118583
    rap_presentation_cou_ratings -- 652781
    rap_presentation_states -- 982413
    rap_presentations -- 246145
    Questions
    1. Why is the index not being used on the table rap_counterparties. If I force a hint then the index is being used
    2. Is there a way I can have an index range scan as opposed to the index fast full scan.
    3. This query runs in 3s. Is there anything else I can do to tune this query?
    4. In predicate 9 and 10 the two tables have fast full scan. If the filter of unit generates only a few records why can't those few records be joined with these tables. Why the whole tables are first being scanned and then joined
    Appreciate your response

    Thanks for the suggestions.
    So I tried using the FIRST_ROW HINT and i am getting the nested loops join and it runs fast in 250ms.
    SELECT /*+FIRST_ROWS*/
           p.ID ID
      FROM rap_presentations p,
           rap_counterparties cou,
           rap_presentation_states sta,
           rap_presentation_cou_ratings pcr
    WHERE cou.unt_id IN (
               SELECT prof.unt_id
                 FROM rap_application_users u, rap_app_user_profiles prof
                WHERE u.ID = prof.aur_id AND u.ID = 7529
                      AND prof.aro_id NOT IN (8))
       AND cou.unt_id = p.unt_id
       AND p.ID = sta.pre_id
       AND sta.cur_present_state_instance_flg = 'Y'
       AND sta.state_type_id = pcr.pst_state_type_id
       AND sta.pre_id = pcr.pst_pre_id
       AND pcr.cou_id = cou.ID
       AND (   p.private_flg != 'Y'
            OR (p.private_flg = 'Y' AND p.created_by_user_id = 7529)
       AND sta.state_type_id IN (326, 322, 323, 324, 325)
    Explain plan:
    PLAN_TABLE_OUTPUT
    | Id  | Operation                           |  Name                         | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT                    |                               |     7 |   434 | 43334   (2)|
    |*  1 |  TABLE ACCESS BY INDEX ROWID        | RAP_PRESENTATIONS             |     1 |    15 |     2  (50)|
    |   2 |   NESTED LOOPS                      |                               |     7 |   434 | 43334   (2)|
    |   3 |    NESTED LOOPS                     |                               |  1593 | 74871 | 41699   (2)|
    |   4 |     NESTED LOOPS                    |                               | 13016 |   457K| 15196   (2)|
    |   5 |      NESTED LOOPS                   |                               |  4723 |   101K|   798   (2)|
    |   6 |       VIEW                          | VW_NSO_1                      |    16 |   208 |            |
    |   7 |        SORT UNIQUE                  |                               |    16 |   256 |            |
    |   8 |         NESTED LOOPS                |                               |    16 |   256 |     4  (25)|
    |*  9 |          INDEX UNIQUE SCAN          | RAP_AUR_PK                    |     1 |     5 |     2  (50)|
    |* 10 |          TABLE ACCESS BY INDEX ROWID| RAP_APP_USER_PROFILES         |    16 |   176 |     3  (34)|
    |* 11 |           INDEX RANGE SCAN          | RAP_AUP_IX_01                 |    18 |       |     2  (50)|
    |  12 |       TABLE ACCESS BY INDEX ROWID   | RAP_COUNTERPARTIES            |   295 |  2655 |    50   (2)|
    |* 13 |        INDEX RANGE SCAN             | RAP_COU_IX_02                 |    95 |       |     2  (50)|
    |* 14 |      TABLE ACCESS BY INDEX ROWID    | RAP_PRESENTATION_COU_RATINGS  |     3 |    42 |     4  (25)|
    |* 15 |       INDEX RANGE SCAN              | RAP_PCR_IX_03                 |    10 |       |     3  (34)|
    |* 16 |     INDEX RANGE SCAN                | RAP_PST_IX_02                 |     1 |    11 |     3  (34)|
    |* 17 |    INDEX RANGE SCAN                 | RAP_PRE_PK                    |     1 |       |            |
    Predicate Information (identified by operation id):
       1 - filter(("P"."PRIVATE_FLG"<>'Y' OR "P"."PRIVATE_FLG"='Y' AND "P"."CREATED_BY_USER_ID"=7529) AND
                  "COU"."UNT_ID"="P"."UNT_ID")
       9 - access("U"."ID"=7529)
      10 - filter("PROF"."ARO_ID"<>8)
      11 - access("PROF"."AUR_ID"=7529)
      13 - access("COU"."UNT_ID"="VW_NSO_1"."$nso_col_1")
      14 - filter("PCR"."PST_STATE_TYPE_ID"=322 OR "PCR"."PST_STATE_TYPE_ID"=323 OR
                  "PCR"."PST_STATE_TYPE_ID"=324 OR "PCR"."PST_STATE_TYPE_ID"=325 OR "PCR"."PST_STATE_TYPE_ID"=326)
      15 - access("PCR"."COU_ID"="COU"."ID")
      16 - access("STA"."PRE_ID"="PCR"."PST_PRE_ID" AND "STA"."STATE_TYPE_ID"="PCR"."PST_STATE_TYPE_ID" AND
                  "STA"."CUR_PRESENT_STATE_INSTANCE_FLG"='Y')
           filter("STA"."STATE_TYPE_ID"=322 OR "STA"."STATE_TYPE_ID"=323 OR "STA"."STATE_TYPE_ID"=324 OR
                  "STA"."STATE_TYPE_ID"=325 OR "STA"."STATE_TYPE_ID"=326)
      17 - access("P"."ID"="STA"."PRE_ID")
    But my query that runs to get the data has a union with another query and with the change it looks like below
    SELECT /*+FIRST_ROWS*/
           p.ID ID
      FROM rap_presentations p,
           rap_counterparties cou,
           rap_presentation_states sta,
           rap_presentation_cou_ratings pcr
    WHERE cou.unt_id IN (
               SELECT prof.unt_id
                 FROM rap_application_users u, rap_app_user_profiles prof
                WHERE u.ID = prof.aur_id AND u.ID = 7529
                      AND prof.aro_id NOT IN (8))
       AND cou.unt_id = p.unt_id
       AND p.ID = sta.pre_id
       AND sta.cur_present_state_instance_flg = 'Y'
       AND sta.state_type_id = pcr.pst_state_type_id
       AND sta.pre_id = pcr.pst_pre_id
       AND pcr.cou_id = cou.ID
       AND (   p.private_flg != 'Y'
            OR (p.private_flg = 'Y' AND p.created_by_user_id = 7529)
       AND sta.state_type_id IN (326, 322, 323, 324, 325)
    UNION
    SELECT /*+index(pfs)*/
           p.ID ID
      FROM rap_presentations p,
           rap_presentation_states sta,
           rap_facilities f,
           rap_presentation_fac_states pfs
    WHERE f.unt_id IN (
               SELECT prof.unt_id
                 FROM rap_application_users u, rap_app_user_profiles prof
                WHERE u.ID = prof.aur_id AND u.ID = 7529
                      AND prof.aro_id NOT IN (8))
       AND f.unt_id = p.unt_id
       AND p.ID = sta.pre_id
       AND sta.cur_present_state_instance_flg = 'Y'
       AND sta.state_type_id = pfs.pst_state_type_id
       AND sta.pre_id = pfs.pst_pre_id
       AND pfs.fac_id = f.ID
       AND pfs.fac_num = f.num
       AND f.current_facility_instance_flg = 'Y'
       AND (   p.private_flg != 'Y'
            OR (p.private_flg = 'Y' AND p.created_by_user_id = 7529)
       AND sta.state_type_id IN (326, 322, 323, 324, 325)
    Explain plan :
    PLAN_TABLE_OUTPUT
    | Id  | Operation                          |  Name                  | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT                   |                        |     8 |   534 | 14931  (80)|
    |   1 |  SORT UNIQUE                       |                        |     8 |   534 | 14931  (80)|
    |   2 |   UNION-ALL                        |                        |       |       |            |
    |*  3 |    TABLE ACCESS BY INDEX ROWID     | RAP_PRESENTATIONS      |     1 |    15 |     2  (50)|
    |   4 |     NESTED LOOPS                   |                        |     7 |   455 |  3728  (17)|
    |*  5 |      HASH JOIN                     |                        |  1542 | 77100 |  2145  (27)|
    |*  6 |       HASH JOIN                    |                        | 12598 |   479K|  1300  (24)|
    |*  7 |        HASH JOIN                   |                        |  4571 |   111K|   584  (16)|
    |*  8 |         TABLE ACCESS BY INDEX ROWID| RAP_APP_USER_PROFILES  |    16 |   176 |     3  (34)|
    |*  9 |          INDEX RANGE SCAN          | RAP_AUP_IX_01          |    18 |       |     2  (50)|
    |  10 |         NESTED LOOPS               |                        |   118K|  1621K|   561  (13)|
    |* 11 |          INDEX UNIQUE SCAN         | RAP_AUR_PK             |     1 |     5 |     2  (50)|
    |  12 |          TABLE ACCESS FULL         | RAP_COUNTERPARTIES     |   118K|  1042K|   560  (13)|
    |* 13 |        INDEX FAST FULL SCAN        | RAP_PCR_PK             |   326K|  4467K|   659  (25)|
    |* 14 |       INDEX FAST FULL SCAN         | RAP_PST_IX_02          |   120K|  1291K|   821  (29)|
    |* 15 |      INDEX RANGE SCAN              | RAP_PRE_PK             |     1 |       |            |
    |  16 |    NESTED LOOPS                    |                        |     1 |    79 | 11201   (2)|
    |  17 |     NESTED LOOPS                   |                        |    75 |  4800 | 11124   (2)|
    |  18 |      NESTED LOOPS                  |                        |   617 | 32701 |  9867   (2)|
    |  19 |       NESTED LOOPS                 |                        |  2104 | 69432 |  5606   (2)|
    |  20 |        NESTED LOOPS                |                        |    16 |   256 |     4  (25)|
    |* 21 |         INDEX UNIQUE SCAN          | RAP_AUR_PK             |     1 |     5 |     2  (50)|
    |* 22 |         TABLE ACCESS BY INDEX ROWID| RAP_APP_USER_PROFILES  |    16 |   176 |     3  (34)|
    |* 23 |          INDEX RANGE SCAN          | RAP_AUP_IX_01          |    18 |       |     2  (50)|
    |* 24 |        TABLE ACCESS BY INDEX ROWID | RAP_FACILITIES         |   135 |  2295 |   351   (2)|
    |* 25 |         INDEX RANGE SCAN           | RAP_FAC_IX_02          |  1608 |       |     5  (20)|
    |* 26 |       INDEX RANGE SCAN             | RAP_PFR_PK             |     1 |    20 |     3  (34)|
    |* 27 |      INDEX RANGE SCAN              | RAP_PST_IX_02          |     1 |    11 |     3  (34)|
    |* 28 |     TABLE ACCESS BY INDEX ROWID    | RAP_PRESENTATIONS      |     1 |    15 |     2  (50)|
    |* 29 |      INDEX UNIQUE SCAN             | RAP_PRE_PK             |     1 |       |            |
    Predicate Information (identified by operation id):
       3 - filter(("P"."PRIVATE_FLG"<>'Y' OR "P"."PRIVATE_FLG"='Y' AND "P"."CREATED_BY_USER_ID"=7529)
                  AND "COU"."UNT_ID"="P"."UNT_ID")
       5 - access("STA"."STATE_TYPE_ID"="PCR"."PST_STATE_TYPE_ID" AND
                  "STA"."PRE_ID"="PCR"."PST_PRE_ID")
       6 - access("PCR"."COU_ID"="COU"."ID")
       7 - access("COU"."UNT_ID"="PROF"."UNT_ID")
       8 - filter("PROF"."ARO_ID"<>8)
       9 - access("PROF"."AUR_ID"=7529)
      11 - access("U"."ID"=7529)
      13 - filter("PCR"."PST_STATE_TYPE_ID"=322 OR "PCR"."PST_STATE_TYPE_ID"=323 OR
                  "PCR"."PST_STATE_TYPE_ID"=324 OR "PCR"."PST_STATE_TYPE_ID"=325 OR "PCR"."PST_STATE_TYPE_ID"=326)
      14 - filter("STA"."CUR_PRESENT_STATE_INSTANCE_FLG"='Y' AND ("STA"."STATE_TYPE_ID"=322 OR
                  "STA"."STATE_TYPE_ID"=323 OR "STA"."STATE_TYPE_ID"=324 OR "STA"."STATE_TYPE_ID"=325 OR
                  "STA"."STATE_TYPE_ID"=326))
      15 - access("P"."ID"="STA"."PRE_ID")
      21 - access("U"."ID"=7529)
      22 - filter("PROF"."ARO_ID"<>8)
      23 - access("PROF"."AUR_ID"=7529)
      24 - filter("F"."CURRENT_FACILITY_INSTANCE_FLG"='Y')
      25 - access("F"."UNT_ID"="PROF"."UNT_ID")
      26 - access("PFS"."FAC_ID"="F"."ID" AND "PFS"."FAC_NUM"="F"."NUM")
           filter("PFS"."PST_STATE_TYPE_ID"=322 OR "PFS"."PST_STATE_TYPE_ID"=323 OR
                  "PFS"."PST_STATE_TYPE_ID"=324 OR "PFS"."PST_STATE_TYPE_ID"=325 OR "PFS"."PST_STATE_TYPE_ID"=326)
      27 - access("STA"."PRE_ID"="PFS"."PST_PRE_ID" AND
                  "STA"."STATE_TYPE_ID"="PFS"."PST_STATE_TYPE_ID" AND "STA"."CUR_PRESENT_STATE_INSTANCE_FLG"='Y')
           filter("STA"."STATE_TYPE_ID"=322 OR "STA"."STATE_TYPE_ID"=323 OR "STA"."STATE_TYPE_ID"=324
                  OR "STA"."STATE_TYPE_ID"=325 OR "STA"."STATE_TYPE_ID"=326)
      28 - filter(("P"."PRIVATE_FLG"<>'Y' OR "P"."PRIVATE_FLG"='Y' AND "P"."CREATED_BY_USER_ID"=7529)
                  AND "F"."UNT_ID"="P"."UNT_ID")
      29 - access("P"."ID"="STA"."PRE_ID")
    Question:
    1. When I put the query with the FIRST_ROWS hint in a union with another query, the explain plan reverts back to the older explain plan. how can I avoid it when running by iteslf it runs really quick?
    2. Why is the cost with nested loops more higher? Is it because of statistics?
    2. Does the database parameter db_multiblock_read_count have any affect  on the fast full scan?
    3. I gather statistics using the followin method
    begin
       dbms_stats.gather_schema_stats(
          ownname          => 'RAP_OWNER',
          estimate_percent => dbms_stats.auto_sample_size,
          method_opt       => 'for all columns size auto',
          degree           => 7
    end;
    Sometimes I also use the following method
    BEGIN
    dbms_stats.gather_schema_stats( ownname=>'RAP_OWNER',
    METHOD_OPT=>'FOR ALL INDEXED COLUMNS SIZE SKEWONLY',
    CASCADE=>TRUE, ESTIMATE_PERCENT=>100);
    END;
    Which one is good or should I use both?
    Appreciate your input.

  • Explain plan doubt.

    I have done 'explain plan' for this query:-
    explain plan for
    select MD.* from ppbs_mobile_detail MD, ppbs_inv_sim_serial ISS where MD.LATEST_SIM_SERIAL_NO=ISS.SIM_SERIAL_NO
    and MD.MOBILE_NO=ISS.MOBILE_NO
    which is having indexes on all the four columns of the 2 tables used: LATEST_SIM_SERIAL_NO,SIM_SERIAL_NO,MOBILE_NO,
    MOBILE_NO.
    But only 1 index on mobile no. of ppbs_mobile_detail is firing.
    Is that, indexes on only 1 table should fire.
    I hope, my question is clear. Please help in solving the doubt.
    Regards.

    thanks for ur update.
    i tried, @?/rdbms/admin/utlxplan.sql but it was giving a error like 'unable to open file "?/rdbms/admin/utlxplan.sql"'.
    So, i re-created the table.
    I gave both the analyze statements,
    SQL> analyze table PPBS_INV_SIM_SERIAL compute statistics for table for all indexed columns for all indexes ;
    SQL> analyze table PPBS_MOBILE_DETAIL compute statistics for table for all indexed columns for all indexes ;
    Output of select * from TABLE(dbms_xplan.display) is:-
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 1 | 164 | 21174 |
    | 1 | HASH JOIN | | 1 | 164 | 21174 |
    | 2 | TABLE ACCESS FULL | PPBS_INV_SIM_SERIAL | 3221K| 86M| 9772 |
    | 3 | TABLE ACCESS FULL | PPBS_MOBILE_DETAIL | 1469K| 190M| 2718 |
    Note: cpu costing is off, PLAN_TABLE' is old version
    regards.

  • Partition of table n Explain plan

    I am a newbie for oracle partititon. Need help!!!
    I have a created a partition table, range partition by key column datatype is 'timetamp'.
    Stucture would be ::
    CREATE TABLE sales
      ( prod_id       NUMBER(6)
      , cust_id       NUMBER
      , time_id       DATE
      , amount_sold   NUMBER(10,2)
    PARTITION BY RANGE (time_id)
    ( PARTITION sales_q1_2006 VALUES LESS THAN (TO_DATE('01-APR-2006','dd-MON-yyyy'))
    , PARTITION sales_q2_2006 VALUES LESS THAN (TO_DATE('01-JUL-2006','dd-MON-yyyy'))
    , PARTITION sales_q3_2006 VALUES LESS THAN (TO_DATE('01-OCT-2006','dd-MON-yyyy'))
    , PARTITION sales_q4_2006 VALUES LESS THAN (TO_DATE('01-JAN-2007','dd-MON-yyyy'))
    The time i run below query, explain plan shows PStart as #1 and PStop as #4, but this date range access only one partition, explain plan must show particular partition. Also should it show partition name?
    select * from sales where trunc(time_id)=trunc(sysdate-2811);

    Thanks for the reply martin,I have tried below query still it goes for all partitions.Please refer to below Expalin Plan.
    select * from sales where trunc(time_id) between trunc(sysdate-2811) and trunc(sysdate-2810) -1/86400
    <PlanElement id="0" operation="SELECT STATEMENT" optimizer="ALL_ROWS" cost="42" cardinality="1" bytes="48" cpu_cost="1,321,416" io_cost="42" time="1">
    <PlanElements>
    <PlanElement id="1" operation="FILTER" qblock_name="SEL$1" filter_predicates="TRUNC(SYSDATE@!-2811)<=TRUNC(SYSDATE@!-2810)-.00001157407407407407407407407407407407407407">
    <PlanElements>
    <PlanElement id="2" operation="PARTITION RANGE" option="ALL" cost="42" cardinality="1" bytes="48" partition_id="2" partition_start="1" partition_stop="4" cpu_cost="1,321,416" io_cost="42" time="1">
    <PlanElements>
    <PlanElement object_ID="0" id="3" operation="TABLE ACCESS" option="FULL" object_owner="SONARDBO" object_name="SALES" object_type="TABLE" object_instance="1" cost="42" cardinality="1" bytes="48" partition_id="2" partition_start="1" partition_stop="4" cpu_cost="1,321,416" io_cost="42" qblock_name="SEL$1" filter_predicates="TRUNC(INTERNAL_FUNCTION("TIME_ID"))>=TRUNC(SYSDATE@!-2811) AND TRUNC(INTERNAL_FUNCTION("TIME_ID"))<=TRUNC(SYSDATE@!-2810)-.00001157407407407407407407407407407407407407" time="1" />

  • How to explain plan with bind variable

    I want to explain plan for query which contains bind variables. I try to execute the query "explain plan for <query>" using PreparedStatement. If I set the bind variable using setXxx method, I get "ORA-01006: bind variable does not exist" error, if I don't bind, I get "java.sql.SQLException: Missing IN or OUT parameter at index:: 1". First error seems to be generated by JDBC driver, the second by the database. Problem is, that database does not require the bind variables to be bound, but the drivers does. Is there any way to do it?
    I use JDBC 10.1.0.5.0, database is Oracle9i Enterprise Edition Release 9.2.0.6.0.
    Thanks in advance,
    Viliam

    hope this helps;
    SQL> set pagesize 25
    SQL> set linesize 141
    SQL> explain plan for
    2 select ename from emp where ename = :x ;
    Explained.
    SQL> SELECT * FROM table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3956160932
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 6 | 2 (0)| 00:00:01 |
    |* 1 | TABLE ACCESS FULL| EMP | 1 | 6 | 2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    1 - filter("ENAME"=:X)
    13 rows selected.
    http://psoug.org/reference/explain_plan.html
    http://psoug.org/reference/dbms_xplan.html

  • Strange explain plan when query SYS tables

    Oracle Version 9.2.0.7
    We have an application that runs the following query on Oracle 9.2.0.7
    SELECT T1.TABLE_NAME,T1.COLUMN_NAME, T1.SRID, T2.SDO_UB, T2.SDO_LB, T1.OWNER FROM ALL_SDO_GEOM_METADATA T1, TABLE(T1.DIMINFO) T2 WHERE T1.OWNER=UPPER(:"SYS_B_0") AND T1.TABLE_NAME=UPPER(:"SYS_B_1")
    Without the self join the query is fine, but with the self join on our customers database the explain plan is doing full table scans and Hash Joins on SYS tables and takes 2 minutes.
    Rows Row Source Operation
    2 FILTER
    2 NESTED LOOPS
    1 TABLE ACCESS FULL SDO_GEOM_METADATA_TABLE
    2 COLLECTION ITERATOR PICKLER FETCH
    1 UNION-ALL
    0 FILTER
    0 NESTED LOOPS OUTER
    0 HASH JOIN
    37 TABLE ACCESS FULL TS$
    0 HASH JOIN OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS FULL USER$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    0 FILTER
    0 NESTED LOOPS OUTER
    0 HASH JOIN
    54 TABLE ACCESS FULL USER$
    0 HASH JOIN
    29447 TABLE ACCESS FULL OBJ$
    0 HASH JOIN OUTER
    0 HASH JOIN OUTER
    0 HASH JOIN OUTER
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS CLUSTER TS$
    0 INDEX UNIQUE SCAN I_TS# (object id 7)
    0 TABLE ACCESS CLUSTER COL$
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER COLTYPE$
    0 TABLE ACCESS FULL USER$
    0 TABLE ACCESS FULL OBJ$
    0 TABLE ACCESS FULL USER$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    1 FILTER
    1 NESTED LOOPS
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
    1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    On our development database it takes 0.07 sec with no full table scans and no hash joins.
    Rows Row Source Operation
    2 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE
    1 INDEX RANGE SCAN SDO_GEOM_IDX (object id 36753)
    1 UNION-ALL
    0 FILTER
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS CLUSTER TS$
    0 INDEX UNIQUE SCAN I_TS# (object id 7)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    0 FILTER
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS CLUSTER TS$
    0 INDEX UNIQUE SCAN I_TS# (object id 7)
    0 TABLE ACCESS CLUSTER COL$
    0 TABLE ACCESS CLUSTER COLTYPE$
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX RANGE SCAN I_OBJ3 (object id 38)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    1 FILTER
    1 NESTED LOOPS
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
    1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    2 COLLECTION ITERATOR PICKLER FETCH
    ALL_SDO_GEOM_METADATA is a view in the MDSYS schema (generated by Oracle ).
    SELECT SDO_OWNER OWNER,
    SDO_TABLE_NAME TABLE_NAME,
    SDO_COLUMN_NAME COLUMN_NAME,
    SDO_DIMINFO DIMINFO,
    SDO_SRID SRID
    FROM SDO_GEOM_METADATA_TABLE
    WHERE
    (exists
    (select table_name from all_tables
    where table_name=sdo_table_name
    and owner = sdo_owner
    union all
    select table_name from all_object_tables
    where table_name=sdo_table_name
    and owner = sdo_owner
    union all
    select view_name table_name from all_views
    where view_name=sdo_table_name
    and owner = sdo_owner))
    Statistics have been gathered for the MDSYS user.
    If this had not been SYS schema I would have immediately concluded that fresh statistics are required. The SYS objects concerend are valid with all indexes
    From my understanding you are not meant to gather stats for the SYS schema in Oracle 9 as Data Dictionary queries still uses RBO?
    Any ideas as to why Oracle is doing full table scans when querying SYS tables? The optimizer_mode is set to FIRST_ROWS.
    Any ideas greatly recevied.
    Thanks

    Maybe I'm missing something but this:
    INDEX FULL SCAN     SISESTAT     I0_ESTRUTURA_COMERCIALindicates that one of those indexes is being used.
    This:
    T_ESTRUTURA_COMERCIALIs nowhere to be found in your Explain Plan. It appears that either you have posted the wrong plan
    or Oracle is doing a query rewrite to a materialized view.

  • Query with same explain-plan but slower in one env

    Hi there
    I have a stored procedure which is executed from a web application. It contains a query (insert-select-from statement). When this stored procedure is called by the web application in PROD, it takes 13sec but it takes 19sec in TEST env. I checked the explain plan for this insert statement in both instances and it is same (see below). Actually, the cost is lower in TEST env.
    ENV: Oracle 10gR2 EE, on ASM - RHEL 64bit
    The TEST server is on a better/faster hardware and will become the new PROD in near future (faster and 16 CPUs  vs 8 in PROD, high performance SAN, 132GB RAM vs 96GB in PROD, etc). The TEST database has exact same init parameter and version/patch level as current PROD. So the application is being tested against it at the moment.
    Here are the explain-plans from both environments:
    From PROD Server
    Plan
    INSERT STATEMENT ALL_ROWS Cost: 143 Bytes: 696 Cardinality: 3
    18 SORT ORDER BY Cost: 143 Bytes: 696 Cardinality: 3
    17 HASH UNIQUE Cost: 142 Bytes: 696 Cardinality: 3
    16 WINDOW SORT Cost: 143 Bytes: 696 Cardinality: 3
    15 HASH JOIN Cost: 141 Bytes: 696 Cardinality: 3
    13 HASH JOIN Cost: 128 Bytes: 519 Cardinality: 3
    11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 125 Bytes: 1,728 Cardinality: 12
    10 NESTED LOOPS Cost: 125 Bytes: 1,992 Cardinality: 12
    3 HASH JOIN Cost: 5 Bytes: 22 Cardinality: 1
    1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 2 Bytes: 12 Cardinality: 1
    2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 2 Bytes: 10 Cardinality: 1
    9 BITMAP CONVERSION TO ROWIDS
    8 BITMAP AND
    5 BITMAP CONVERSION FROM ROWIDS
    4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 19 Cardinality: 4,920
    7 BITMAP CONVERSION FROM ROWIDS
    6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 89 Cardinality: 4,920
    12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 2 Bytes: 84 Cardinality: 12
    14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,809 Cardinality: 3,251
    From TEST Server
    Plan
    INSERT STATEMENT ALL_ROWS Cost: 107 Bytes: 232 Cardinality: 1
    18 SORT ORDER BY Cost: 107 Bytes: 232 Cardinality: 1
    17 HASH UNIQUE Cost: 106 Bytes: 232 Cardinality: 1
    16 WINDOW SORT Cost: 107 Bytes: 232 Cardinality: 1
    15 HASH JOIN Cost: 105 Bytes: 232 Cardinality: 1
    13 HASH JOIN Cost: 93 Bytes: 173 Cardinality: 1
    11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 89 Bytes: 864 Cardinality: 6
    10 NESTED LOOPS Cost: 89 Bytes: 996 Cardinality: 6
    3 HASH JOIN Cost: 7 Bytes: 22 Cardinality: 1
    1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 3 Bytes: 12 Cardinality: 1
    2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 3 Bytes: 10 Cardinality: 1
    9 BITMAP CONVERSION TO ROWIDS
    8 BITMAP AND
    5 BITMAP CONVERSION FROM ROWIDS
    4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 9 Cardinality: 2,977
    7 BITMAP CONVERSION FROM ROWIDS
    6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 59 Cardinality: 2,977
    12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 3 Bytes: 84 Cardinality: 12
    14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,868 Cardinality: 3,252
    What else can I check to find out why the query is slower in TEST env?
    Please advise.
    Best regards

    Here is some more info. The query is below:
    select distinct dr.line_num 
                     ,row_number() over (partition by di.HEADINGNO,di.DIRECTORYNO order by reportyear,to_number(di.monthno)) monthposition
                     ,di.SATID,di.REPORTYEAR,di.MONTHNO,di.MONTHEN,di.MONTHFR,di.HEADINGNO,hn.NAME_EN,hn.NAME_FR,di.DIRECTORYNO
                     ,di.SUPERDIRECTORYNO,di.PRINTDIRCODE,di.DIRECTORYNAME,round(to_number(di.IMPTTOTAL)) imptotal
                     ,round(to_number(di.IMPBEST)) impbest ,round(to_number(di.IMPTAVERAGE)) imptaverage
                     ,round(to_number(di.CLICKTOTAL)) clicktotal,round(to_number(di.CLICKBEST)) clickbest
                     ,round(to_number(di.CLICKAVERAGE)) clickaverage
                     ,round(avg(to_number(impttotal)) over(partition by di.HEADINGNO,di.DIRECTORYNO)) avgimp
               from satdataimport di,tmpg_clicks_hdgs hd,tmpg_clicks_dirs dr, months12 m12, ref_west_category hn
               where di.headingno   = hd.id
                 and di.directoryno = dr.id
                 and dr.line_num=hd.line_num
                 and di.reportyear  = m12.year
                 and di.monthno     = m12.month
                 and hn.CATEGORY_CODE = di.headingno
               order by di.headingno, di.directoryno,di.reportyear,to_number(di.monthno)
    The largest table is "satdataimport" in the query has "12274818" rows. Rest of the tables are very small containing few rows to less than 4000 rows.
    I have refreshed the statistics of the larger table but this did not help either. Even a simple query like "select count(*) from satdataimport" is taking 15sec in TEST while it takes 4Sec in PROD when I run it from TOAD.
    The other strange thing is that when I run this stored procedure from TOAD, it takes 200 milli sec to complete. There is a logging table to which the stored procedure records the elapsed time taken by this INSERT statement.
    Since this query is in a stored procedure being called from the web app, the QA team wants quicker response. Current PROD is faster.
    The tables have same indexes, etc and contain identical data as that in PROD (were refreshed from PROD yesterday).
    What else can I check?
    Best regards

  • Strange behavior of explain plan

    Hello i don't know if this is the correct category for posting my issue.
    I ma facing a strange behavior of the explain plan. What i mean!
    I have a query which runs very fast and it is well optimized. the explain plan shows very good results in cost and execution time.
    when i am running the query for a second or a third time is appearing a different explain plan with not such a good cost and execution time.
    Could you please guide me what it might be wrong???
    thanks a lot

    HI i found the correct category
    thanks

  • Query tunning in Oracle using Explain Plan

    Adding to my below question: I have now modified the query and the path shownby 'Explain plan' has reduced. The 'Time' column of plan_table is also showing much lesser value. However, some people are suggesting me to consider the time required by the query to execute on Toad. Will it be practical? Please help!!
    Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...
    Edited by: 885901 on Sep 20, 2011 2:10 AM

    885901 wrote:
    Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...how fast is fast enough?

  • How to improve the query performance or tune query from Explain Plan

    Hi
    The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
    SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204                                         
         8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1                                    
              5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1                               
                   2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1                          
                        1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                     
                   4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1                          
                        3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1                     
              7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1                               
                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1                          
         10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1                                    
              9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                               
         15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1                                    
              12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1                               
                   11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                          
              14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1                               
                   13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1                          
         21 FILTER                                    
              16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49                               
              20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1                               
                   18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1                          
                        17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                     
                   19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1                          
         23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1                                    
              22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1                               
         45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204                                    
              42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204                               
                   38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204                          
                        34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925                     
                             30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699                
                                  26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18          
                                       25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18     
                                            24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
                                  29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32           
                                       28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32      
                                            27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
                             33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35                
                                  32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35           
                                       31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35      
                        37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38                     
                             36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2               
                                  35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2          
                   41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41                          
                        40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2                    
                             39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2               
              44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1                               
                   43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1

    damorgan wrote:
    Tuning is NOT about reducing the cost of i/o.
    i/o is only one of many contributors to cost and only one of many contributors to waits.
    Any time you would like to explore this further run this code:
    SELECT 1 FROM dual
    WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
    And when I say "extreme" I mean "EXTREME!"
    You've been warned.I think you just need a faster server.
    SQL> set autotrace traceonly statistics
    SQL> set timing on
    SQL> select 1 from dual
      2  where
      3  regexp_like   (' ','^*[ ]*a');
    no rows selected
    Elapsed: 00:00:00.00
    Statistics
              1  recursive calls
              0  db block gets
              0  consistent gets
              0  physical reads
              0  redo size
            243  bytes sent via SQL*Net to client
            349  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processedRepeated from an Oracle 10.2.0.x instance:
    SQL> SELECT DISTINCT SID FROM V$MYSTAT;
           SID
           310
    SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    Session altered.
    SQL> select 1 from dual
      2  where
      3  regexp_like   (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
    COLUMN STAT_NAME FORMAT A35 TRU
    SET PAGESIZE 200
    SELECT
      STAT_NAME,
      VALUE
    FROM
      V$SESS_TIME_MODEL
    WHERE
      SID=310;
    STAT_NAME                                VALUE
    DB time                                   9247
    DB CPU                                    9247
    background elapsed time                      0
    background cpu time                          0
    sequence load elapsed time                   0
    parse time elapsed                        6374
    hard parse elapsed time                   5997
    sql execute elapsed time                  2939
    connection management call elapsed        1660
    failed parse elapsed time                    0
    failed parse (out of shared memory)          0
    hard parse (sharing criteria) elaps          0
    hard parse (bind mismatch) elapsed           0
    PL/SQL execution elapsed time               95
    inbound PL/SQL rpc elapsed time              0
    PL/SQL compilation elapsed time              0
    Java execution elapsed time                  0
    repeated bind elapsed time                  48
    RMAN cpu time (backup/restore)               0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
    STAT_NAME                                VALUE
    DB time                                   9247
    DB CPU                                    9247
    background elapsed time                      0
    background cpu time                          0
    sequence load elapsed time                   0
    parse time elapsed                        6374
    hard parse elapsed time                   5997
    sql execute elapsed time                  2939
    connection management call elapsed        1660
    failed parse elapsed time                    0
    failed parse (out of shared memory)          0
    hard parse (sharing criteria) elaps          0
    hard parse (bind mismatch) elapsed           0
    PL/SQL execution elapsed time               95
    inbound PL/SQL rpc elapsed time              0
    PL/SQL compilation elapsed time              0
    Java execution elapsed time                  0
    repeated bind elapsed time                  48
    RMAN cpu time (backup/restore)               0The session is not reporting additional CPU usage or parse time.
    Let's check one of the session's statistics:
    SELECT
      SS.VALUE
    FROM
      V$SESSTAT SS,
      V$STATNAME SN
    WHERE
      SN.NAME='consistent gets'
      AND SN.STATISTIC#=SS.STATISTIC#
      AND SS.SID=310;
         VALUE
           163Not many consistent gets after 20+ minutes.
    Let's take a look at the plan:
    SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
    al%';
    SQL_ID        CHILD_NUMBER
    04mpgrzhsv72w            0
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
    select 1 from dual where regexp_like   (' ','^*[ ]*a')
    NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
          Please verify value of SQL_ID and CHILD_NUMBER;
          It could also be that the plan is no longer in cursor cache (check v$sql_p
    lan)No plan...
    Let's take a look at the 10053 trace file:
    Registered qb: SEL$1 0x19157f38 (PARSER)
      signature (): qb_name=SEL$1 nbfros=1 flg=0
        fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
    Predicate Move-Around (PM)
    PM: Considering predicate move-around in SEL$1 (#0).
    PM:   Checking validity of predicate move-around in SEL$1 (#0).
    CBQT: Validity checks failed for 7uqx4guu04x3g.
    CVM: Considering view merge in query block SEL$1 (#0)
    CBQT: Validity checks failed for 7uqx4guu04x3g.
    Subquery Unnest
    SU: Considering subquery unnesting in query block SEL$1 (#0)
    Set-Join Conversion (SJC)
    SJC: Considering set-join conversion in SEL$1 (#0).
    Predicate Move-Around (PM)
    PM: Considering predicate move-around in SEL$1 (#0).
    PM:   Checking validity of predicate move-around in SEL$1 (#0).
    PM:     PM bypassed: Outer query contains no views.
    FPD: Considering simple filter push in SEL$1 (#0)
    FPD:   Current where clause predicates in SEL$1 (#0) :
              REGEXP_LIKE (' ','^*[ ]*a')
    kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
    predicates with check contraints:  REGEXP_LIKE (' ','^*[ ]*a')
    after transitive predicate generation:  REGEXP_LIKE (' ','^*[ ]*a')
    finally:  REGEXP_LIKE (' ','^*[ ]*a')
    apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
    kkoqbc-start
                : call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
    kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
    I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Same query, same dataset, same ddl setup, but wildly different explain plan

    Hello o fountains of oracle knowledge!
    We have a problem that caused us a full stop when rolling out a new version of our system to a customer and a whole Sunday to boot.
    The scenario is as follows:
    1. An previous version database schema
    2. The current version database schema
    3. A migration script to migrate the old schema to the new
    So we perform the following migration:
    1. Export the previous version database schema
    2. Import into a new schema called schema_old
    3. Create a new schema called schema_new
    4. Run migration script which creates objects, copies data, creates indexes etc etc in schema_new
    The migration runs fine in all environments (development, test and production)
    In our development and test environments performance is stellar, on the customer production server the performance is terrible.
    This using the exact same export file (from the production environment) and performing the exact same steps with the exact same migration script.
    Database version is 10.2.0.1.0 EE on all databases. OS is Microsoft Windows Server 2003 EE SP2 on all servers.
    The system is not in any sense under a heavy load (we have tested with no other load than ourselves).
    Looking at the explain plan for a query that is run frequently and does not use bind variables we see wildly different explain plans.
    The explain plan cost on our development and test servers is estimated to *7* for this query and there are no full table scans.
    On the production server the cost is *8433* and there are two full table scans of which one is on the largest table.
    We have tried to run analyse on all objects with very little effect. The plan changed very slightly, but still includes the two full table scans on the problem server and the cost is still the same.
    All tables and indexes are identical (including storage options), created from the same migration script.
    I am currently at loss for where to look? What can be causing this? I assume this could be caused by some parameter that is set on the server, but I don't know what to look for.
    I would be very grateful for any pointers.
    Thanks,
    Håkon

    Thank you for your answer.
    We collected statistics only after we determined that the production server where not behaving according to expectations.
    In this case we used TOAD and the tool within to collect statistics for all objects. We used 'Analyze' and 'Compute Statistics' options.
    I am not an expert, so sorry if this is too naive an approach.
    Here is the query:SELECT count(0)  
    FROM score_result sr, web_scorecard sc, product p
    WHERE sr.score_final_decision like 'VENT%'  
    AND sc.CREDIT_APPLICATION_ID = sr.CREDIT_APPLICATION_ID  
    AND sc.application_complete='Y'   
    AND p.product = sc.web_product   
    AND p.inactive_product = '2' ;I use this as an example, but the problem exists for virtually all queries.
    The output from the 'good' server:
    | Id  | Operation                      | Name                  | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT               |                       |     1 |    39 |     7   (0)|
    |   1 |  SORT AGGREGATE                |                       |     1 |    39 |            |
    |   2 |   NESTED LOOPS                 |                       |     1 |    39 |     7   (0)|
    |   3 |    NESTED LOOPS                |                       |     1 |    30 |     6   (0)|
    |   4 |     TABLE ACCESS BY INDEX ROWID| SCORE_RESULT          |     1 |    17 |     4   (0)|
    |   5 |      INDEX RANGE SCAN          | SR_FINAL_DECISION_IDX |     1 |       |     3   (0)|
    |   6 |     TABLE ACCESS BY INDEX ROWID| WEB_SCORECARD         |     1 |    13 |     2   (0)|
    |   7 |      INDEX UNIQUE SCAN         | WEB_SCORECARD_PK      |     1 |       |     1   (0)|
    |   8 |    TABLE ACCESS BY INDEX ROWID | PRODUCT               |     1 |     9 |     1   (0)|
    |   9 |     INDEX UNIQUE SCAN          | PK_PRODUCT            |     1 |       |     0   (0)|
    ---------------------------------------------------------------------------------------------The output from the 'bad' server:
    | Id  | Operation                 | Name                  | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT          |                       |     1 |    32 |  8344   (3)|
    |   1 |  SORT AGGREGATE           |                       |     1 |    32 |            |
    |   2 |   HASH JOIN               |                       | 10887 |   340K|  8344   (3)|
    |   3 |    TABLE ACCESS FULL      | PRODUCT               |     6 |    42 |     3   (0)|
    |   4 |    HASH JOIN              |                       | 34381 |   839K|  8340   (3)|
    |   5 |     VIEW                  | index$_join$_001      | 34381 |   503K|  2193   (3)|
    |   6 |      HASH JOIN            |                       |       |       |            |
    |   7 |       INDEX RANGE SCAN    | SR_FINAL_DECISION_IDX | 34381 |   503K|   280   (3)|
    |   8 |       INDEX FAST FULL SCAN| SCORE_RESULT_PK       | 34381 |   503K|  1371   (2)|
    |   9 |     TABLE ACCESS FULL     | WEB_SCORECARD         |   489K|  4782K|  6137   (4)|
    ----------------------------------------------------------------------------------------I hope the formatting makes this readable.
    Stats (from SQL Developer), good table:NUM_ROWS     489716
    BLOCKS     27198
    AVG_ROW_LEN     312
    SAMPLE_SIZE     489716
    LAST_ANALYZED     15.12.2009
    LAST_ANALYZED_SINCE     15.12.2009Stats (from SQL Developer), bad table:
    NUM_ROWS     489716
    BLOCKS     27199
    AVG_ROW_LEN     395
    SAMPLE_SIZE     489716
    LAST_ANALYZED     17.12.2009
    LAST_ANALYZED_SINCE     17.12.2009I'm unsure what would cause the difference in average row length.
    I could obviously try to tune our sql-statements to work on the server not behaving better, but I would rather understand why they are different and make sure that we can expect similar behaviour between environments.
    Thank you again for trying to help me.
    Håkon
    Edited by: ergates on 17.des.2009 05:57
    Edited by: ergates on 17.des.2009 06:02

  • How to change the explain plan for currently running query?

    Hi All,
    I am using Oracle enterprise 9i edition. I have a query which frames dynamically and running in the database. I noticed a table with 31147758 rows
    in the query which has no indexes and taking more time to process. I tried to create an INdex on that table. I know the query is already running with a FULL table scan. Is it possible to change the explain plan for the current running query to consider the INDEX?
    [code]
    SELECT /*+ USE_HASH (c,e,b,a) */
    d.att_fcc extrt_prod_dim_id,
    d.att_fcc compr_prod_dim_id,
      a.glbl_uniq_id glbl_uniq_id,
      to_date(c.dit_code,'RRRRMMDD')STRT_DT,
      (to_date(c.dit_code,'RRRRMMDD')+150)END_DT,
      a.pat_nbr pat_id,
      a.rxer_id       rxer_id,
      e.rxer_geog_id  rxer_geog_id,
      a.pharmy_id pharmy_id,
      a.pscr_pack_id pscr_pack_id,
      a.dspnsd_pack_id dspnsd_pack_id,
      DENSE_RANK () OVER (PARTITION BY a.pat_nbr ORDER BY c.dit_code) daterank,
      COUNT( DISTINCT d.att_fcc ) OVER (PARTITION BY a.pat_nbr, c.dit_code) event_cnt
      DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
    d.att_fcc
      ORDER BY c.dit_code) prodrank,
      DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
    d.att_fcc
      ORDER BY c.dit_code DESC) stoprank
      FROM
      pd_dimitems c,
       pd_pack_attribs   d ,
        lrx_tmp_rxer_geog e,
        lrx_tmp_pat_daterank p,
        lrx_tmp_valid_fact_link     a
        WHERE c.dit_id = a.tm_id
        AND   e.rxer_id = a.rxer_id
        AND   a.glbl_uniq_id = p.glbl_uniq_id
        AND   p.daterank > 1
      AND   a.pscr_pack_id = d.att_dit_id
    [/code]
    The table lrx_tmp_pat_daterank is having that 31147758 rows. So I am wondering how to make the query to use the newly created index on the table?

    Why do you think using Indexes will improve the performance of the query? How many rows this query is returning? Optimizer might chose a Full table scan when it finds out that Index plan might not be useful. Why are you using /*+ USE_HASH (c,e,b,a) */ hint? This Hint will force oracle to use Full table scan instead of using the index. Try removing it and see if the plan changes.
    Regards,

  • How to create an explain plan with rowsource statistics for a complex query that include multiple table joins ?

    1. How to create an explain plan with rowsource statistics for a complex query that include multiple table joins ?
    When multiple tables are involved , and the actual number of rows returned is more than what the explain plan tells. How can I find out what change is needed  in the stat plan  ?
    2. Does rowsource statistics gives some kind of  understanding of Extended stats ?

    You can get Row Source Statistics only *after* the SQL has been executed.  An Explain Plan midway cannot give you row source statistics.
    To get row source statistics either set STATISTICS_LEVEL='ALL'  in the session that executes theSQL OR use the Hint "gather_plan_statistics"  in the SQL being executed.
    Then use dbms_xplan.display_cursor
    Hemant K Chitale

  • Explain Plan query

    I just changed the hint to pick different indexes inside the same SQL and they have significant different performance. SQL1 is much faster than SQL2 and the explain plain is very different. I found that there is some values like :Q1003, :Q1004 and :Q1005 under Object Code in the explain plan of SQL1. May I know how to interpret this?
    Thanks.
    Edited by: 843672 on Mar 11, 2011 3:42 AM

    Welcome to the forum.
    Before you even think of posting another 'question', first read:
    http://tkyte.blogspot.com/2005/06/how-to-ask-questions.html
    and secondly, when it comes to tuning requests, read:
    When your query takes too long ...
    HOW TO: Post a SQL statement tuning request - template posting
    and there's also a FAQ and a SQL and PL/SQL FAQ....
    http://forums.oracle.com/forums/ann.jspa?annID=1535

Maybe you are looking for

  • Material com múltipla utilização - Determinação do CFOP

    Olá experts! Gostaria de validar aqui a solução na qual chegamos para determinação automática do CFOP para material de venda para múltipla utilização. Ocorre que na empresa em que trabalho, o mesmo produto pode ser vendido: 1)   para consumo final e

  • Getting list of all users present in SIM

    Hi, I would like to update all the users (attributes of users) in SIM . Right now I am thinking to get list of all users present in SIM and get the view of each user and then update the particular attribute and chekin the view. and imp point to note

  • Cenvat Hold Account

    I have a problem pertaining to excise. 1,  I have done GR  and have filled up all the excise related details.During GR RG 23 A PART I is updated. 2.Capture Excise invoice(J1IEX)During this step i  am posting vendor excise invoice with a rejection cod

  • Airport basics for my iBook

    Dear Mac gurus, I have a problem with my iBook ethernet port. Basically, the port is not working and one of the options for me is to go wireless. I need pointers on the airport card to use and the model of the base station. Please note that I am on O

  • Getting error with word wrap

    So this is the error im getting: Error: Error #1502: A script has executed for longer than the default timeout period of 15 seconds.           at flashx.textLayout.elements::FlowElement/getAbsoluteStart()[C:\Vellum\branches\v1\1.0\dev\ output\openSou