INDEX UNIQUE SCAN instead of   INDEX FULL SCAN or TABLE ACCESS FULL

I have calculated statistics in all tables and indexes
I have a table and a view and when I put it
SELECT *
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID          
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN (FIELD_A_TABLE_A_PK)
It’s OK. I NEED IT (INDEX UNIQUE SCAN)
But If I put
SELECT A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID          
WHERE (B.FK_ID_XXX = 1)
In table A make a TABLE ACCESS FULL.
Then If I put:
SELECT /*+ INDEX(A FIELD_A_TABLE_A_PK) */ A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID          
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN (FIELD_A_TABLE_A_PK)
It’s OK. I NEED IT (INDEX UNIQUE SCAN)
Finally, If I put other tables and views in the query (I NEED IT)
For example:
SELECT /*+ INDEX(A FIELD_A_TABLE_A_PK) */ A.Field_1, A.Field_2, A.Field_3, A.Field_4
FROM TABLE_A A
INNER JOIN VIEW_B B ON A.KEY_ID = B.PFK_KEY_ID          
INNER JOIN TABLE_C….
LEFT JOIN VIEW_D….
WHERE (B.FK_ID_XXX = 1)
If I see the execution plan:
In TABLE_A make a
TABLE ACCESS BY INDEX ROWID
INDEX FULL SCAN (FIELD_A_TABLE_A_PK)
I need INDEX UNIQUE SCAN instead of INDEX FULL SCAN or TABLE ACCESS FULL.
How can obtain it?
What happens???
Thanks!

Notice the difference in cardinality between your two select statements:
SELECT STATEMENT, GOAL = ALL_ROWS Cost=5 Cardinality=1
SELECT STATEMENT, GOAL = ALL_ROWS Cost=10450 Cardinality=472161Apparently since the optimizer believed the first statement was going to return one row, it used an index. But in the second statement it believed it was going to return nearly the whole table (didn't you say it had around 500k rows?). Hence full table scan.

Similar Messages

  • Oracle 9.2 prefers Table Access Full over Local Index by rowid access

    There's this table that has phone call records (30 million per day) that is partitioned by month (using the date column) and stores the last 6 months.
    The primary key is date (varchar2 in yymmdd format) + call_id (a varchar2(18) with a format like this yyyymmdd+<3letters>+<sequentialnumber>)
    The partition is by range like this:
    PARTITION BY RANGE (FECHA)
    PARTITION P200804 VALUES LESS THAN ('080501')
    LOGGING
    NOCOMPRESS,
    If I run this query I get this plan
    SELECT FECHA, SENTIDOTRAFICO,GEOGRAFIAID,SWITCHID,TIPOTRAFICOID,COUNT(*)
    FROM GES_CDRS_RCNG_NEW
    WHERE FECHA BETWEEN '080801' AND '080825'
         AND TASACION IS NULL
         AND BORRADO IS NULL
    GROUP BY FECHA, SENTIDOTRAFICO,GEOGRAFIAID,SWITCHID,TIPOTRAFICOID
    Plan
    SELECT STATEMENT CHOOSECost: 78 K Bytes: 24 K Cardinality: 1 K           
         2 SORT GROUP BY Cost: 78 K Bytes: 24 K Cardinality: 1 K      
              1 TABLE ACCESS FULL GESTION.GES_CDRS_RCNG_NEW Cost: 43 K Bytes: 625 M Cardinality: 31 M Partition #: 2 Partitions accessed #5
    If I hint the primary key index using /*+INDEX(GES_CDRS_RCNG_NEW PK_CDRS_RCNG_NEW)*/
    I get a different plan
    Plan
    SELECT STATEMENT CHOOSECost: 954 K Bytes: 24 K Cardinality: 1 K                
         3 SORT GROUP BY Cost: 954 K Bytes: 24 K Cardinality: 1 K           
              2 TABLE ACCESS BY LOCAL INDEX ROWID GESTION.GES_CDRS_RCNG_NEW Cost: 918 K Bytes: 625 M Cardinality: 31 M Partition #: 2 Partitions accessed #5     
                   1 INDEX RANGE SCAN UNIQUE GESTION.PK_CDRS_RCNG_NEW Cost: 137 K Cardinality: 31 M Partition #: 3 Partitions accessed #5
    Looking at the cost, the full scan is way better, but this is obviously not the case. Why does this happen?
    This problem forces many querys on this table to use hints or force the index use by adding conditions to the where clause like this
    where fecha = '080801'
    and clave like '20080801%'
    when just by stating the date would be enough to choose the correct partition. It also messes up joins with other tables.
    The table is analized every month, it has statistics that claim: 237,981,000 rows, 3,222,677 blocks, GLOBAL STATS: YES, LAST ANALYZED: 15/10/2008 21:05:26, Average row length: 213.
    The partition envolved in this query has this stats: 32,520,520 rows, 442,715 blocks, analized on 27/08/2008 20:43:40
    The index has this stats: analized on 15/10/2008 21:35:32, Blevel: 3, leaf blocks: 1,056,410, distinct keys: 238,484,510.
    It is a local index and each partition has its own statistics.

    If I don't understand incorrectly the plan and the Predicater information, it seems the full scan version that costs less is actually doing a full scan from the biggining of the table (6 months) up to the 080825 date and the one using an index (hinted) does a better scan.
    without hint
    | Id  | Operation            |  Name              | Rows  | Bytes | Cost  | Pstart| Pstop |
    |   0 | SELECT STATEMENT     |                    |  1170 | 24570 | 78443 |       |       |
    |   1 |  SORT GROUP BY       |                    |  1170 | 24570 | 78443 |       |       |
    |*  2 |   TABLE ACCESS FULL  | GES_CDRS_RCNG_NEW  |    31M|   625M| 42579 |     5 |     5 |
    Predicate Information (identified by operation id):
       2 - filter("GES_CDRS_RCNG_NEW"."FECHA"<='080825')
    Note: cpu costing is offWith the hint:
    | Id  | Operation                          |  Name              | Rows  | Bytes | Cost  | Pstart| Pstop |
    |   0 | SELECT STATEMENT                   |                    |  1170 | 24570 |   953K|       |       |
    |   1 |  SORT GROUP BY                     |                    |  1170 | 24570 |   953K|       |       |
    |   2 |   TABLE ACCESS BY LOCAL INDEX ROWID| GES_CDRS_RCNG_NEW  |    31M|   625M|   918K|     5 |     5 |
    |*  3 |    INDEX RANGE SCAN                | PK_CDRS_RCNG_NEW   |    31M|       |   136K|     5 |     5 |
    Predicate Information (identified by operation id):
       3 - access("GES_CDRS_RCNG_NEW"."FECHA">='080801' AND "GES_CDRS_RCNG_NEW"."FECHA"<='080825')
    Note: cpu costing is off

  • Problem with Table Access Full

    Hi,
    Please help me how to resolve the problem of table access full, when i am executing query i facing a problem with these. all though i have create index on these is queru but execution time taking too late.
    Also please help if there any syntax to run faster execution.
    Thanks in Advance
    Sreenivas

    Hi,
    Please try to analyze your tables once with DBA's help.
    If the above does not work, try to use hints which will force use the index created on the column.
    Do not use any conversion functions on that column, in the where clause while checking any condition.
    If you are storing numbers in a character column, try to have the conditional value as character value in where clause instead of number type.
    Thanks and Regards,
    Sridhar.

  • Why does my query do full scan on table ...?

    I have a query with sub-query that should narrow down a search of triples:
    DELETE FROM XPROCESS_TPL  t WHERE t.triple.rdf_s_id
    IN
    ( SELECT r.value_id FROM mdsys.rdf_value$ r
      WHERE  r.value_type='UR'   AND  r.vname_suffix LIKE  'ProcessAggregate_Lens Fab%' )
    the inner SELECT returns 122707 rows in 41.914 seconds
    However, the outer query takes ~6 hours all together...
    What I thought would happen was it should first do the sub-query,get all value_id's and then use index to find data in XPROCESS_TPL
    Why is that not happening and how can I optimize this query?
    I created index on rdf_s_id:
    CREATE INDEX "SEMANTIC"."XPROCESS_SUB_IDX" ON "SEMANTIC"."XPROCESS_TPL" ("TRIPLE"."RDF_S_ID")

    The query plan is the execution plan generated by the query optimizer. One way of viewing the query plan is using explain plan through SQL*Plus:
    SQL> explain plan for
    select empno, ename, dname, loc
    from emp e, dept d
    where e.deptno = d.deptno;
      2    3    4
    Explained.
    Elapsed: 00:00:00.05
    SQL> select plan_table_output from table(dbms_xplan.display('plan_table',null,'basic,parallel,partition,predicate'));
    PLAN_TABLE_OUTPUT
    Plan hash value: 2219294842
    | Id  | Operation          | Name |
    |   0 | SELECT STATEMENT   |      |
    |*  1 |  HASH JOIN         |      |
    |   2 |   TABLE ACCESS FULL| DEPT |
    |   3 |   TABLE ACCESS FULL| EMP  |
    Predicate Information (identified by operation id):
       1 - access("E"."DEPTNO"="D"."DEPTNO")
    15 rows selected.
    Elapsed: 00:00:00.47
    SQL>

  • Query takes 5 min when using Indexes and 1 Second without Indexes !!

    Hi,
    We have been using indexes on all tables until recently when we faced problems with queries like the one below:
    SELECT a.std_id FROM students a, student_degree b, student_course c, course d
    WHERE b.std_id = a.std_id
    AND c.std_id = a.std_id
    AND d.crn = c.crn
    AND b.in_progress = 'Y'
    AND b.major_code = 'ABTC'
    AND a.program_code = 'DP'
    AND a.level_code = 'S2'
    AND a.campus_code = '05'
    AND a.termcode = '200702';
    This query takes more than 5 minutes to return a result, but as soon as we remove indexes on the columns termcode and campus_code,it shows result in 1 second.
    What could be the problem ?, Is there an attribute that need to be set when creating these indexes ?
    Thanks in advance
    Madani

    Thank you Karthik for your reply.Here are the explain plan report (as shown on Oracle 9i Enterprise Manager)
    *1-Explain plan without Indexes:*
    Execution Steps:
    Step # Step Name
    11 SELECT STATEMENT
    10 MERGE JOIN
    7 SORT [JOIN]
    6 NESTED LOOPS
    4 NESTED LOOPS
    1 ERMS.STUDENT_DEGREE TABLE ACCESS [FULL]
    3 ERMS.STUDENTS TABLE ACCESS [BY INDEX ROWID]
    2 ERMS.SYS_C006642 INDEX [UNIQUE SCAN]
    5 ERMS.SYS_C007065 INDEX [RANGE SCAN]
    9 SORT [JOIN]
    8 ERMS.COURSE TABLE ACCESS [FULL]
    Step # Description
    1 This plan step retrieves all rows from table STUDENT_DEGREE.
    2 This plan step retrieves a single ROWID from the B*-tree index SYS_C006642.
    3 This plan step retrieves rows from table STUDENTS through ROWID(s) returned by an index.
    4 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
    5 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SYS_C007065.
    6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
    7 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
    8 This plan step retrieves all rows from table COURSE.
    9 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
    10 This plan step accepts two sets of rows sorted on the join key. By walking both sets of rows in the order of the join key, every distinct pair of rows satisfying the join condition in the WHERE clause is found through a single pass of the row sets.
    11 This plan step designates this statement as a SELECT statement.
    *2-Explain plan with Indexes:* (I added index on column campus_code which is a varchar2 column)
    Execution Steps:
    Step # Step Name
    11 SELECT STATEMENT
    10 MERGE JOIN
    7 SORT [JOIN]
    6 NESTED LOOPS
    4 NESTED LOOPS
    1 ERMS.COURSE TABLE ACCESS [FULL]
    3 ERMS.STUDENTS TABLE ACCESS [BY INDEX ROWID]
    2 ERMS.INDEX_STUDENTS_CAMPUS_CODE INDEX [RANGE SCAN]
    5 ERMS.SYS_C007065 INDEX [RANGE SCAN]
    9 SORT [JOIN]
    8 ERMS.STUDENT_DEGREE TABLE ACCESS [FULL]
    Step # Description
    1 This plan step retrieves all rows from table COURSE.
    2 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index INDEX_STUDENTS_CAMPUS_CODE.
    3 This plan step retrieves rows from table STUDENTS through ROWID(s) returned by an index.
    4 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
    5 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SYS_C007065.
    6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
    7 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
    8 This plan step retrieves all rows from table STUDENT_DEGREE.
    9 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
    10 This plan step accepts two sets of rows sorted on the join key. By walking both sets of rows in the order of the join key, every distinct pair of rows satisfying the join condition in the WHERE clause is found through a single pass of the row sets.
    11 This plan step designates this statement as a SELECT statement.

  • The plan doesn't use the index but the cost of INDEX FULL SCAN looks better

    Hi,
    Well, I'm sure I miss the boat... and if the question is pretty tricky, the answer is probably :"You're stupid Greg!". Well anyway, you'll probably be interested in trying to answer it as I've spent some times on it without any result ! I use Oracle XE on Windows...
    1) Below is my query and its plan. You'll find the full schema generation script at the end of this email. Look at the cost (468) of the plan and the cost of the same query when you force the use of the index (116). Why is this ?
    select count(distinct col5)
      2    from demo
      3      where col1 between 1 and 50000
      4        and col2=col1
      5        and col3=col1
      6        and col4=col1;
    Plan d'execution
    Plan hash value: 2072716547
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |   116 |   468   (2)| 00:00:06 |
    |   1 |  SORT GROUP BY     |      |     1 |   116 |            |          |
    |*  2 |   TABLE ACCESS FULL| DEMO |     1 |   116 |   468   (2)| 00:00:06 |
    Predicate Information (identified by operation id):
       2 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
                  "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=50000 AND
                  "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)2) When I force the use of an index (with a Hint), You'll see the cost of the plan is 116 which is definitly better than the TABLE ACCESS FULL (468) :
    SQL> l
      1  select /*+ index(demo demo_idx)*/ count(distinct col5)
      2    from demo
      3      where col1 between 1 and 50000
      4        and col2=col1
      5        and col3=col1
      6*       and col4=col1
    SQL> /
    Plan d'execution
    Plan hash value: 189561699
    | Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |          |     1 |   116 |   437   (2)| 00:00:06 |
    |   1 |  SORT GROUP BY               |          |     1 |   116 |            |          |
    |   2 |   TABLE ACCESS BY INDEX ROWID| DEMO     |     1 |   116 |   437   (2)| 00:00:06 |
    |*  3 |    INDEX FULL SCAN           | DEMO_IDX |     1 |       |   436   (2)| 00:00:06 |
    Predicate Information (identified by operation id):
       3 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
                  "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=50000 AND
                  "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)3) My question is why is plan1 used while plan2 should be considered better by the optimizer regarding the cost (to make the case even more complex, plan1 is actually more efficient but this is out of the scope of my question. I know that and I know why !).
    You'll find a script to generate the structures and data below. I can send you the 10053 traces if you what to go furthermore. Take care the index is a REVERSE index (Don't know if query rewrite should be enabled in order to take advantage of this type of index but it is set to "true" (and "trusted") :
    drop table demo;
    create table demo (col1 number not null,
        col2 number,
        col3 number,
        col4 number,
        col5 varchar2(500));
    begin
      for i in 1..100000 loop
        insert into demo values (i,i,i,i,'This column is used to raise the High Water Mark and '||
                                 ' the cost of an TABLE ACCESS FULL operation');
      end loop;
    end;
    commit;
    create index demo_idx on demo(col1,col2,col3,col4) reverse;
    exec dbms_stats.gather_table_stats(USER, 'DEMO', cascade=>true, -
      method_opt=>'FOR ALL COLUMNS SIZE 254', no_invalidate=>false) Any comments are welcome ! Best Regards,
    Gregory
    Message was edited by:
    arkzoyd... I've added the "pre" tags

    I suspect this has something to do with db_file_multiblock_read_count
    After running provided creation statements by you I got following results:
    SQL> show parameter multiblock
    NAME                                 TYPE        VALUE
    db_file_multiblock_read_count        integer     16
    SQL> set autotrace on
    SQL> select count(distinct col5)
      2   from demo
      3   where col1 between 1 and 50000
      4   and col2=col1
      5   and col3=col1
      6   and col4=col1
      7  /
    COUNT(DISTINCTCOL5)
                      1
    Execution Plan
    Plan hash value: 2072716547
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |   116 |   375   (1)| 00:00:05 |
    |   1 |  SORT GROUP BY     |      |     1 |   116 |            |          |
    |*  2 |   TABLE ACCESS FULL| DEMO |     1 |   116 |   375   (1)| 00:00:05 |
    Predicate Information (identified by operation id):
       2 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
                  "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
    0 AND
                  "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
    Statistics
            196  recursive calls
              0  db block gets
           1734  consistent gets
            850  physical reads
              0  redo size
            422  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              7  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> select /*+ index(demo demo_idx)*/ count(distinct col5)
      2   from demo
      3   where col1 between 1 and 50000
      4   and col2=col1
      5   and col3=col1
      6   and col4=col1
      7  /
    COUNT(DISTINCTCOL5)
                      1
    Execution Plan
    Plan hash value: 189561699
    | Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| T
    ime     |
    |   0 | SELECT STATEMENT             |          |     1 |   116 |   431   (1)| 0
    0:00:06 |
    |   1 |  SORT GROUP BY               |          |     1 |   116 |            |
            |
    |   2 |   TABLE ACCESS BY INDEX ROWID| DEMO     |     1 |   116 |   431   (1)| 0
    0:00:06 |
    |*  3 |    INDEX FULL SCAN           | DEMO_IDX |     1 |       |   430   (1)| 0
    0:00:06 |
    Predicate Information (identified by operation id):
       3 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
                  "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
    0 AND
                  "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
    Statistics
              1  recursive calls
              0  db block gets
          50426  consistent gets
            428  physical reads
              0  redo size
            422  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
              1  rows processedNow I modify multiblock_read_count and full scan cost is going up although anyway Oracle by default chooses full scan instead of index access.
    SQL> alter session set db_file_multiblock_read_count = 8;
    Session altered.
    SQL> select count(distinct col5)
      2   from demo
      3   where col1 between 1 and 50000
      4   and col2=col1
      5   and col3=col1
      6   and col4=col1
      7  /
    COUNT(DISTINCTCOL5)
                      1
    Execution Plan
    Plan hash value: 2072716547
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |   116 |   463   (1)| 00:00:06 |
    |   1 |  SORT GROUP BY     |      |     1 |   116 |            |          |
    |*  2 |   TABLE ACCESS FULL| DEMO |     1 |   116 |   463   (1)| 00:00:06 |
    Predicate Information (identified by operation id):
       2 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
                  "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
    0 AND
                  "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
    Statistics
              1  recursive calls
              0  db block gets
           1697  consistent gets
            850  physical reads
              0  redo size
            422  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> select /*+ index(demo demo_idx)*/ count(distinct col5)
      2   from demo
      3   where col1 between 1 and 50000
      4   and col2=col1
      5   and col3=col1
      6   and col4=col1
      7  /
    COUNT(DISTINCTCOL5)
                      1
    Execution Plan
    Plan hash value: 189561699
    | Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| T
    ime     |
    |   0 | SELECT STATEMENT             |          |     1 |   116 |   431   (1)| 0
    0:00:06 |
    |   1 |  SORT GROUP BY               |          |     1 |   116 |            |
            |
    |   2 |   TABLE ACCESS BY INDEX ROWID| DEMO     |     1 |   116 |   431   (1)| 0
    0:00:06 |
    |*  3 |    INDEX FULL SCAN           | DEMO_IDX |     1 |       |   430   (1)| 0
    0:00:06 |
    Predicate Information (identified by operation id):
       3 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
                  "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
    0 AND
                  "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
    Statistics
              1  recursive calls
              0  db block gets
          50426  consistent gets
              0  physical reads
              0  redo size
            422  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
              1  rows processedSo I don't know what is the default value of dbfmbrc in XE and not gone too deep to understand how for example system statistics may change your situation.
    Gints Plivna
    http://www.gplivna.eu
    P.S. BTW I used Oracle Database 10g Enterprise Edition Release 10.2.0.1.0.
    Message was edited by:
    gintsp
    listened to Williams suggestion :)

  • How oracle decide whetehr to use index or full scan (statistics)

    Hi Guys,
    Let say i have a index on a column.
    The table and index statistics has been gathered. (without histograms).
    Let say i perform a select * from table where a=5;
    Oracle will perform a full scan.
    But from which statistics it will be able to know indeed most of the column = 5? (histograms not used)
    After analyzing, we get the below:
    Table Statistics :
    (NUM_ROWS)
    (BLOCKS)
    (EMPTY_BLOCKS)
    (AVG_SPACE)
    (CHAIN_COUNT)
    (AVG_ROW_LEN)
    Index Statistics :
    (BLEVEL)
    (LEAF_BLOCKS)
    (DISTINCT_KEYS)
    (AVG_LEAF_BLOCKS_PER_KEY)
    (AVG_DATA_BLOCKS_PER_KEY)
    (CLUSTERING_FACTOR)
    thanks
    Index Column (A)
    ======
    1
    1
    2
    2
    5
    5
    5
    5
    5
    5

    I have prepared some explanation and have not noticed that the topic has been marked as answered.
    This my sentence is not completely true.
    A column "without histograms" means that the column has only one bucket. More correct: even without histograms there are data in dba_tab_histograms which we can consider as one bucket for whole column. In fact these data are retrieved from hist_head$, not from histgrm$ as usual buckets.
    Technically there is no any buckets without gathered histograms.
    Let's create a table with skewed data distribution.
    SQL> create table t as
      2  select least(rownum,3) as val, '*' as pad
      3    from dual
      4  connect by level <= 1000000;
    Table created
    SQL> create index idx on t(val);
    Index created
    SQL> select val, count(*)
      2    from t
      3   group by val;
           VAL   COUNT(*)
             1          1
             2          1
             3     999998So, we have table with very skewed data distribution.
    Let's gather statistics without histograms.
    SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for all columns size 1', cascade => true);
    PL/SQL procedure successfully completed
    SQL> select blocks, num_rows  from dba_tab_statistics
      2   where table_name = 'T';
        BLOCKS   NUM_ROWS
          3106    1000000
    SQL> select blevel, leaf_blocks, clustering_factor
      2    from dba_ind_statistics t
      3   where table_name = 'T'
      4     and index_name = 'IDX';
        BLEVEL LEAF_BLOCKS CLUSTERING_FACTOR
             2        4017              3107
    SQL> select column_name,
      2         num_distinct,
      3         density,
      4         num_nulls,
      5         low_value,
      6         high_value
      7    from dba_tab_col_statistics
      8   where table_name = 'T'
      9     and column_name = 'VAL';
    COLUMN_NAME  NUM_DISTINCT    DENSITY  NUM_NULLS      LOW_VALUE      HIGH_VALUE
    VAL                     3 0,33333333          0           C102            C104So, Oracle suggests that values between 1 and 3 (raw C102 and C104) are distributed uniform and the density of the distribution is 0.33.
    Let's try to explain plan
    SQL> explain plan for
      2  select --+ no_cpu_costing
      3         *
      4    from t
      5   where val = 1
      6  ;
    Explained
    SQL> @plan
    | Id  | Operation         | Name | Rows  | Cost  |
    |   0 | SELECT STATEMENT  |      |   333K|   300 |
    |*  1 |  TABLE ACCESS FULL| T    |   333K|   300 |
    Predicate Information (identified by operation id):
       1 - filter("VAL"=1)
    Note
       - cpu costing is off (consider enabling it)Below is an excerpt from trace 10053
    BASE STATISTICAL INFORMATION
    Table Stats::
      Table:  T  Alias:  T
        #Rows: 1000000  #Blks:  3106  AvgRowLen:  5.00
    Index Stats::
      Index: IDX  Col#: 1
        LVLS: 2  #LB: 4017  #DK: 3  LB/K: 1339.00  DB/K: 1035.00  CLUF: 3107.00
    SINGLE TABLE ACCESS PATH
      BEGIN Single Table Cardinality Estimation
      Column (#1): VAL(NUMBER)
        AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 0.33333 Min: 1 Max: 3
      Table:  T  Alias: T
        Card: Original: 1000000  Rounded: 333333  Computed: 333333.33  Non Adjusted: 333333.33
      END   Single Table Cardinality Estimation
      Access Path: TableScan
        Cost:  300.00  Resp: 300.00  Degree: 0
          Cost_io: 300.00  Cost_cpu: 0
          Resp_io: 300.00  Resp_cpu: 0
      Access Path: index (AllEqRange)
        Index: IDX
        resc_io: 2377.00  resc_cpu: 0
        ix_sel: 0.33333  ix_sel_with_filters: 0.33333
        Cost: 2377.00  Resp: 2377.00  Degree: 1
      Best:: AccessPath: TableScan
             Cost: 300.00  Degree: 1  Resp: 300.00  Card: 333333.33  Bytes: 0Cost of FTS here is 300 and cost of Index Range Scan here is 2377.
    I have disabled cpu costing, so selectivity does not affect the cost of FTS.
    cost of Index Range Scan is calculated as
    blevel + (leaf_blocks * selectivity + clustering_factor * selecivity) = 2 + (4017*0.33333 + 3107*0.33333) = 2377.
    Oracle considers that it has to read 2 root/branch blocks of the index, 1339 leaf blocks of the index and 1036 blocks of the table.
    Pay attention that selectivity is the major component of the cost of the Index Range Scan.
    Let's try to gather histograms:
    SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for columns val size 3', cascade => true);
    PL/SQL procedure successfully completedIf you look at dba_tab_histograms you will see following
    SQL> select endpoint_value,
      2         endpoint_number
      3    from dba_tab_histograms
      4   where table_name = 'T'
      5     and column_name = 'VAL'
      6  ;
    ENDPOINT_VALUE ENDPOINT_NUMBER
                 1               1
                 2               2
                 3         1000000ENDPOINT_VALUE is the column value (in number for any type of data) and ENDPOINT_NUMBER is cumulative number of rows.
    Number of rows for any ENDPOINT_VALUE = ENDPOINT_NUMBER for this ENDPOINT_VALUE - ENDPOINT_NUMBER for the previous ENDPOINT_VALUE.
    explain plan and 10053 trace of the same query:
    | Id  | Operation                   | Name | Rows  | Cost  |
    |   0 | SELECT STATEMENT            |      |     1 |     4 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T    |     1 |     4 |
    |*  2 |   INDEX RANGE SCAN          | IDX  |     1 |     3 |
    Predicate Information (identified by operation id):
       2 - access("VAL"=1)
    Note
       - cpu costing is off (consider enabling it)
    BASE STATISTICAL INFORMATION
    Table Stats::
      Table:  T  Alias:  T
        #Rows: 1000000  #Blks:  3106  AvgRowLen:  5.00
    Index Stats::
      Index: IDX  Col#: 1
        LVLS: 2  #LB: 4017  #DK: 3  LB/K: 1339.00  DB/K: 1035.00  CLUF: 3107.00
    SINGLE TABLE ACCESS PATH
      BEGIN Single Table Cardinality Estimation
      Column (#1): VAL(NUMBER)
        AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 5.0000e-07 Min: 1 Max: 3
        Histogram: Freq  #Bkts: 3  UncompBkts: 1000000  EndPtVals: 3
      Table:  T  Alias: T
        Card: Original: 1000000  Rounded: 1  Computed: 1.00  Non Adjusted: 1.00
      END   Single Table Cardinality Estimation
      Access Path: TableScan
        Cost:  300.00  Resp: 300.00  Degree: 0
          Cost_io: 300.00  Cost_cpu: 0
          Resp_io: 300.00  Resp_cpu: 0
      Access Path: index (AllEqRange)
        Index: IDX
        resc_io: 4.00  resc_cpu: 0
        ix_sel: 1.0000e-06  ix_sel_with_filters: 1.0000e-06
        Cost: 4.00  Resp: 4.00  Degree: 1
      Best:: AccessPath: IndexRange  Index: IDX
             Cost: 4.00  Degree: 1  Resp: 4.00  Card: 1.00  Bytes: 0Pay attention on selectivity, ix_sel: 1.0000e-06
    Cost of the FTS is still the same = 300,
    but cost of the Index Range Scan is 4 now: 2 root/branch blocks + 1 leaf block + 1 table block.
    Thus, conclusion: histograms allows to calculate selectivity more accurate. The aim is to have more efficient execution plans.
    Alexander Anokhin
    http://alexanderanokhin.wordpress.com/

  • Why a table full scan when I've got the PK in the WHERE clause?

    There is a very complex query that I need to optimize in an Oracle 10gR2 environment. I am deconstructing it into layers to see what is causing the first bottleneck. The innermost portion is fine, with an explain plan cost of 54. With a typical value for the bind variable, it returns 125 zero_id values. There are over 100,000 rows in table T_ONE in my test database, but my customer has over one million rows in their production instance.
                  WITH t_merged_id AS (SELECT DISTINCT zero_id FROM t_zero WHERE NVL(column2, zero_id) = :i_id)
                  SELECT   t_one.one_id
                      FROM t_one
                          INNER JOIN t_two
                              ON t_one.column1 = t_two.two_id
                          INNER JOIN t_merged_id
                              ON t_two.column10 = t_merged_id.zero_id
                  UNION ALL
                  SELECT   t_one.one_id
                      FROM t_one
                          INNER JOIN t_two
                              ON t_one.column2 = t_two.two_id
                          INNER JOIN t_merged_id
                              ON t_two.column10 = t_merged_id.zero_id
                  UNION ALL
                  SELECT   t_one.one_id
                      FROM t_one
                          INNER JOIN t_three
                              ON t_one.column3 = t_three.three_id
                          INNER JOIN t_merged_id
                              ON t_three.column10 = t_merged_id.zero_id
                  UNION ALL
                  SELECT   t_one.one_id
                      FROM t_one
                          INNER JOIN t_four
                              ON t_one.column4 = t_four.four_id
                          INNER JOIN t_two
                              ON t_four.column1 = t_two.two_id
                          INNER JOIN t_merged_id
                              ON t_two.two_id = t_merged_id.zero_id
                  UNION ALL
                  SELECT   t_one.one_id
                      FROM t_one INNER JOIN t_merged_id ON t_one.column5 = t_merged_id.zero_id
                  UNION
                  SELECT   t_one.one_id
                      FROM t_one INNER JOIN t_merged_id ON t_one.column6 = t_merged_id.zero_idHowever, the next step is to obtain a bunch of columns from T_ONE for each of those ONE_ID values. Adding that looks like the following, which causes a table full scan on T_ONE (and an explain plan cost over 1,500 for this query in my test system) and it takes far too long to return the results.
    SELECT   t_one.*
        FROM     t_one
             INNER JOIN
                 (--This is the start of the query shown above
                  WITH t_merged_id AS (SELECT DISTINCT zero_id FROM t_zero WHERE NVL(column2, zero_id) = :i_id)
                  SELECT   t_one.one_id
                      FROM t_one
                          INNER JOIN t_two
                              ON t_one.column1 = t_two.two_id
                          INNER JOIN t_merged_id
                              ON t_two.column10 = t_merged_id.zero_id
                  UNION ALL
                  SELECT   t_one.one_id
                      FROM t_one
                          INNER JOIN t_two
                              ON t_one.column2 = t_two.two_id
                          INNER JOIN t_merged_id
                              ON t_two.column10 = t_merged_id.zero_id
                  UNION ALL
                  SELECT   t_one.one_id
                      FROM t_one
                          INNER JOIN t_three
                              ON t_one.column3 = t_three.three_id
                          INNER JOIN t_merged_id
                              ON t_three.column10 = t_merged_id.zero_id
                  UNION ALL
                  SELECT   t_one.one_id
                      FROM t_one
                          INNER JOIN t_four
                              ON t_one.column4 = t_four.four_id
                          INNER JOIN t_two
                              ON t_four.column1 = t_two.two_id
                          INNER JOIN t_merged_id
                              ON t_two.two_id = t_merged_id.zero_id
                  UNION ALL
                  SELECT   t_one.one_id
                      FROM t_one INNER JOIN t_merged_id ON t_one.column5 = t_merged_id.zero_id
                  UNION
                  SELECT   t_one.one_id
                      FROM t_one INNER JOIN t_merged_id ON t_one.column6 = t_merged_id.zero_id
                   --This is the end of the query shown above
                   ) t_list
             ON t_one.one_id = t_list.one_idMy question is, why wouldn’t Oracle use the existing index PK_T_ONE, which is keyed on T_ONE.ONE_ID? I tried refactoring the query using a “WHERE t_one.one_id IN” construct instead of the INNER JOIN but it didn’t make any difference. Neither did adding an index hint, which I hoped would force the use of the PK index.
    Any ideas?

    I was able to completely resolve my problem, but I still want to understand why the original query wouldn't use an index.
    (My solution was to move all the joins and where clauses from the query that wrapped the one we've been discussing and put them into each SELECT in the UNION, so there is no longer any inner subquery. So instead of trying to first get a list of ID values from the subquery, get the full records for the IDs from an outer query, and then joining to the outer query, I made SELECT in the UNION contain the full logic. This makes the query a lot more verbose, because all the joins and wheres are repeated six times, but it does use the index and returns in 0.04 seconds instead of over nine minutes in my test database.)
    hoek wrote:
    Values for optimizer_index_caching and optimizer_index_cost_adj are not the defaults. Any reasons for that?I am not a DBA and have no idea. However, I did a Google search and found this: http://decipherinfosys.wordpress.com/2007/02/13/optimizer_index_cost_adj-and-optimizer_index_caching/. Apparently Tom Kyte would approve more of our settings than the defaults.
    hoek wrote:
    Any chance to get a realistic dataset on your test server?Unfortunately, not for quite some time. The customer won't provide any real data, and generating data for testing is complex because of all the interrelationships. I have someone working on that. However, I was able to get back on the primary test server that has 136k records in the main table instead of only 2k. So far as I know, the Oracle configuration between the test server and the customer's server is the same. However, they have much more serious hardware that I do (more processors, more RAM, more platters). On the other hand, they have 10 times as much data.
    hoek wrote:
    Your second execution plan contains differents stats, they're not the 'common ones'. (E-rows etc.)The predicates are the same as the first. The 2nd plan was generated by the 10g-specific portion of Randolph's script using the command "select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));".
    This is the result from running the script on the main test server:
    NAME                                 TYPE                             VALUE
    _optimizer_cost_based_transformation string                           OFF
    optimizer_dynamic_sampling           integer                          2
    optimizer_features_enable            string                           10.2.0.4
    optimizer_index_caching              integer                          95
    optimizer_index_cost_adj             integer                          10
    optimizer_mode                       string                           CHOOSE
    optimizer_secure_view_merging        boolean                          TRUE
    db_file_multiblock_read_count        integer                          32
    db_block_size                        integer                          8192
    cursor_sharing                       string                           FORCE
    SNAME                PNAME                     PVAL1 PVAL2
    SYSSTATS_INFO        STATUS                          COMPLETED
    SYSSTATS_INFO        DSTART                          04-04-2008 07:02
    SYSSTATS_INFO        DSTOP                           04-04-2008 07:02
    SYSSTATS_INFO        FLAGS                         1
    SYSSTATS_MAIN        CPUSPEEDNW            646.57331
    SYSSTATS_MAIN        IOSEEKTIM                    10
    SYSSTATS_MAIN        IOTFRSPEED                 4096
    SYSSTATS_MAIN        SREADTIM
    SYSSTATS_MAIN        MREADTIM
    SYSSTATS_MAIN        CPUSPEED
    SYSSTATS_MAIN        MBRC
    SYSSTATS_MAIN        MAXTHR
    SYSSTATS_MAIN        SLAVETHR
    SQL> SELECT st.*
      2    FROM t_senttsk st INNER JOIN (WITH t_mrgdusr AS (SELECT DISTINCT usr_id
      3                                                       FROM t_usr
      4                                                      WHERE NVL(usr_mrgemstr, usr_id) = 10000002                    /* i_payer_id */
      5                                                                                                )
      6                                  SELECT t_senttsk.setk_id
      7                                    FROM t_senttsk INNER JOIN t_mrgdusr
      8                                             ON t_senttsk.setk_affn_memb = t_mrgdusr.usr_id
      9                                  UNION
    10                                  SELECT t_senttsk.setk_id
    11                                    FROM t_senttsk INNER JOIN t_mrgdusr
    12                                             ON t_senttsk.setk_ownr = t_mrgdusr.usr_id) t_affil
    13             ON st.setk_id = t_affil.setk_id;
    no rows selected
    Elapsed: 00:13:14.54
    Execution Plan
    Plan hash value: 1241660758
    | Id  | Operation                         | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                  |                             |   169K|    64M|  1403   (3)| 00:00:17 |
    |   1 |  NESTED LOOPS                     |                             |   169K|    64M|  1403   (3)| 00:00:17 |
    |   2 |   TABLE ACCESS FULL               | T_SENTTSK                   |   136K|    51M|  1400   (3)| 00:00:17 |
    |   3 |   VIEW                            |                             |     1 |     6 |     1   (0)| 00:00:01 |
    |   4 |    TEMP TABLE TRANSFORMATION      |                             |       |       |            |          |
    |   5 |     LOAD AS SELECT                |                             |       |       |            |          |
    |   6 |      TABLE ACCESS BY INDEX ROWID  | T_USR                       |     1 |     8 |     1   (0)| 00:00:01 |
    |*  7 |       INDEX RANGE SCAN            | IX_NVL_USR_MRGEMSTR_USR_ID  |     1 |       |     1   (0)| 00:00:01 |
    |   8 |     SORT UNIQUE                   |                             |       |       |            |          |
    |   9 |      UNION-ALL PARTITION          |                             |       |       |            |          |
    |  10 |       NESTED LOOPS                |                             |     1 |    25 |     3   (0)| 00:00:01 |
    |  11 |        TABLE ACCESS BY INDEX ROWID| T_SENTTSK                   |     1 |    12 |     1   (0)| 00:00:01 |
    |* 12 |         INDEX UNIQUE SCAN         | PK_T_SENTTSK                |     1 |       |     1   (0)| 00:00:01 |
    |* 13 |        VIEW                       |                             |     1 |    13 |     2   (0)| 00:00:01 |
    |  14 |         TABLE ACCESS FULL         | SYS_TEMP_0FD9D6608_399116CE |     1 |     6 |     2   (0)| 00:00:01 |
    |  15 |       NESTED LOOPS                |                             |     1 |    22 |     3   (0)| 00:00:01 |
    |* 16 |        TABLE ACCESS BY INDEX ROWID| T_SENTTSK                   |     1 |     9 |     1   (0)| 00:00:01 |
    |* 17 |         INDEX UNIQUE SCAN         | PK_T_SENTTSK                |     1 |       |     1   (0)| 00:00:01 |
    |* 18 |        VIEW                       |                             |     1 |    13 |     2   (0)| 00:00:01 |
    |  19 |         TABLE ACCESS FULL         | SYS_TEMP_0FD9D6608_399116CE |     1 |     6 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       7 - access(NVL("USR_MRGEMSTR","USR_ID")=10000002)
      12 - access("T_SENTTSK"."SETK_ID"="ST"."SETK_ID")
      13 - filter("T_SENTTSK"."SETK_AFFN_MEMB"="T_MRGDUSR"."USR_ID")
      16 - filter("T_SENTTSK"."SETK_OWNR" IS NOT NULL)
      17 - access("T_SENTTSK"."SETK_ID"="ST"."SETK_ID")
      18 - filter("T_SENTTSK"."SETK_OWNR"="T_MRGDUSR"."USR_ID")
    Statistics
            349  recursive calls
         275041  db block gets
        1239881  consistent gets
             26  physical reads
       52730252  redo size
           3312  bytes sent via SQL*Net to client
            240  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
         136835  sorts (memory)
              0  sorts (disk)
              0  rows processed
    SQL> SELECT /*+ gather_plan_statistics */ st.*
      2    FROM t_senttsk st INNER JOIN (WITH t_mrgdusr AS (SELECT DISTINCT usr_id
      3                                                       FROM t_usr
      4                                                      WHERE NVL(usr_mrgemstr, usr_id) = 10000002                    /* i_payer_id */
      5                                                                                                )
      6                                  SELECT t_senttsk.setk_id
      7                                    FROM t_senttsk INNER JOIN t_mrgdusr
      8                                             ON t_senttsk.setk_affn_memb = t_mrgdusr.usr_id
      9                                  UNION
    10                                  SELECT t_senttsk.setk_id
    11                                    FROM t_senttsk INNER JOIN t_mrgdusr
    12                                             ON t_senttsk.setk_ownr = t_mrgdusr.usr_id) t_affil
    13             ON st.setk_id = t_affil.setk_id;
    no rows selected
    Elapsed: 00:09:15.90
    SQL>
    SQL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
    PLAN_TABLE_OUTPUT
    SQL_ID  2rc9d2c83a7ak, child number 0
    SELECT /*+ gather_plan_statistics */ st.*   FROM t_senttsk st INNER JOIN (WITH t_mrgdusr AS (SELECT DISTINCT usr_id
                               FROM t_usr                                                     WHERE NVL(usr_mrgemstr, usr_id) = :"SYS_B_0"
                /* i_payer_id */                                                                                               )
                   SELECT t_senttsk.setk_id                                   FROM t_senttsk INNER JOIN t_mrgdusr
               ON t_senttsk.setk_affn_memb = t_mrgdusr.usr_id                                 UNION                                 SELECT
    t_senttsk.setk_id                                   FROM t_senttsk INNER JOIN t_mrgdusr                                            ON
    t_senttsk.setk_ownr = t_mrgdusr.usr_id) t_affil            ON st.setk_id = t_affil.setk_id
    Plan hash value: 1065206678
    | Id  | Operation                         | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
    |   1 |  NESTED LOOPS                     |                             |      1 |    169K|      0 |00:09:02.47 |    1514K|       |       |          |
    |   2 |   TABLE ACCESS FULL               | T_SENTTSK                   |      1 |    136K|    136K|00:00:01.64 |    7062 |       |       |          |
    |   3 |   VIEW                            |                             |    136K|      1 |      0 |00:09:00.54 |    1507K|       |       |          |
    |   4 |    TEMP TABLE TRANSFORMATION      |                             |    136K|        |      0 |00:09:00.12 |    1507K|       |       |          |
    |   5 |     LOAD AS SELECT                |                             |    136K|        |      0 |00:08:24.31 |     548K|  1024 |  1024 |          |
    |   6 |      TABLE ACCESS BY INDEX ROWID  | T_USR                       |    136K|      1 |      0 |00:00:06.12 |     410K|       |       |          |
    |*  7 |       INDEX RANGE SCAN            | IX_NVL_USR_MRGEMSTR_USR_ID  |    136K|      1 |      0 |00:00:05.41 |     410K|       |       |          |
    |   8 |     SORT UNIQUE                   |                             |    136K|        |      0 |00:00:19.10 |     822K|  1024 |  1024 |          |
    |   9 |      UNION-ALL PARTITION          |                             |    136K|        |      0 |00:00:17.40 |     822K|       |       |          |
    |  10 |       NESTED LOOPS                |                             |    136K|      1 |      0 |00:00:08.02 |     411K|       |       |          |
    |  11 |        TABLE ACCESS BY INDEX ROWID| T_SENTTSK                   |    136K|      1 |    136K|00:00:06.36 |     411K|       |       |          |
    |* 12 |         INDEX UNIQUE SCAN         | PK_T_SENTTSK                |    136K|      1 |    136K|00:00:03.68 |     273K|       |       |          |
    |* 13 |        VIEW                       |                             |    136K|      1 |      0 |00:00:01.03 |       0 |       |       |          |
    |  14 |         TABLE ACCESS FULL         | SYS_TEMP_0FD9D6609_399116CE |    136K|      1 |      0 |00:00:00.67 |       0 |       |       |          |
    |  15 |       NESTED LOOPS                |                             |    136K|      1 |      0 |00:00:06.54 |     411K|       |       |          |
    |* 16 |        TABLE ACCESS BY INDEX ROWID| T_SENTTSK                   |    136K|      1 |  34256 |00:00:05.87 |     411K|       |       |          |
    |* 17 |         INDEX UNIQUE SCAN         | PK_T_SENTTSK                |    136K|      1 |    136K|00:00:03.46 |     273K|       |       |          |
    |* 18 |        VIEW                       |                             |  34256 |      1 |      0 |00:00:00.25 |       0 |       |       |          |
    |  19 |         TABLE ACCESS FULL         | SYS_TEMP_0FD9D6609_399116CE |  34256 |      1 |      0 |00:00:00.16 |       0 |       |       |          |
    Predicate Information (identified by operation id):
       7 - access("T_USR"."SYS_NC00127$"=:SYS_B_0)
      12 - access("T_SENTTSK"."SETK_ID"="ST"."SETK_ID")
      13 - filter("T_SENTTSK"."SETK_AFFN_MEMB"="T_MRGDUSR"."USR_ID")
      16 - filter("T_SENTTSK"."SETK_OWNR" IS NOT NULL)
      17 - access("T_SENTTSK"."SETK_ID"="ST"."SETK_ID")
      18 - filter("T_SENTTSK"."SETK_OWNR"="T_MRGDUSR"."USR_ID")
    hoek wrote:Does rewriting 'the heart of the issue' into like below make any difference?
    select a.*
    from   foo a
    where  exists ( select null
    from   bar b
    where  a.foo_pk_id = b.foo_pk_id
    and    b.some_col = :bind_var
    The UNION in the subquery seems to make that difficult.

  • How can I avoid a full scan when ...

    Hello
    How can I avoid a full scan with I apply the aggregate function "MIN"
    SQL> select min(c1) from hh;
       MIN(C1)
             1
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE
       1    0   SORT (AGGREGATE)
       2    1     TABLE ACCESS (FULL) OF 'HH'Regards
    James King

    The table 'hh' does not have statistics. Assuming that there is an index on the column c1, statistics are computed on the table and its indexes, you may see a
    INDEX (FULL SCAN (MIN/MAX)) of the index on column 'c1'.

  • How to make single full scan

    Hi, ALL
    I have this query like below and I see that it produced 3 <TABLE ACCESS FULL> for each Unioin, how to make it work with single Scan? It's simple table 2 colums, not indexes or PK, just for sample.
    explain plan for
    select count(*) from tt where amt between 0 and 100  union all
    select       count(*) from tt where amt between 100 and 200  union all
    select       count(*) from tt where amt >200 
    | Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     |                                                                                                                                                                                                                                
    |   0 | SELECT STATEMENT    |      |     3 |    39 |     9  (67)| 00:00:01 |                                                                                                                                                                                                                                
    |   1 |  UNION-ALL          |      |       |       |            |          |                                                                                                                                                                                                                                
    |   2 |   SORT AGGREGATE    |      |     1 |    13 |            |          |                                                                                                                                                                                                                                
    |*  3 |    TABLE ACCESS FULL| TT   |     2 |    26 |     3   (0)| 00:00:01 |                                                                                                                                                                                                                                
    |   4 |   SORT AGGREGATE    |      |     1 |    13 |            |          |                                                                                                                                                                                                                                
    |*  5 |    TABLE ACCESS FULL| TT   |     3 |    39 |     3   (0)| 00:00:01 |                                                                                                                                                                                                                                
    |   6 |   SORT AGGREGATE    |      |     1 |    13 |            |          |                                                                                                                                                                                                                                
    |*  7 |    TABLE ACCESS FULL| TT   |     3 |    39 |     3   (0)| 00:00:01 |                                                                                                                                                                                                                                
    Predicate Information (identified by operation id):                                                                                                                                                                                                                                                         
       3 - filter("AMT">=0 AND "AMT"<=100)                                                                                                                                                                                                                                                                      
       5 - filter("AMT">=100 AND "AMT"<=200)                                                                                                                                                                                                                                                                    
       7 - filter("AMT">200)                                                                                                                                                                                                                                                                                    
    Note                                                                                                                                                                                                                                                                                                        
       - dynamic sampling used for this statement                                                                                                                                                                                                                                                               

    SQL> explain plan for
      2  select count(*) from emp where sal between 0 and 100  union all
      3  select       count(*) from emp where sal between 100 and 200  union all
      4  select       count(*) from emp where sal > 200
      5  /
    Explained.
    SQL> @?\rdbms\admin\utlxpls
    PLAN_TABLE_OUTPUT
    Plan hash value: 3840822464
    | Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |          |     3 |    12 |     3  (67)| 00:00:01 |
    |   1 |  UNION-ALL        |          |       |       |            |          |
    |   2 |   SORT AGGREGATE  |          |     1 |     4 |            |          |
    |*  3 |    INDEX FULL SCAN| EMP_IDX3 |     1 |     4 |     1   (0)| 00:00:01 |
    |   4 |   SORT AGGREGATE  |          |     1 |     4 |            |          |
    |*  5 |    INDEX FULL SCAN| EMP_IDX3 |     1 |     4 |     1   (0)| 00:00:01 |
    PLAN_TABLE_OUTPUT
    |   6 |   SORT AGGREGATE  |          |     1 |     4 |            |          |
    |*  7 |    INDEX FULL SCAN| EMP_IDX3 |    14 |    56 |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - access("SAL">=0 AND "SAL"<=100)
           filter("SAL"<=100 AND "SAL">=0)
       5 - access("SAL">=100 AND "SAL"<=200)
           filter("SAL"<=200 AND "SAL">=100)
    PLAN_TABLE_OUTPUT
       7 - access("SAL">200)
           filter("SAL">200)
    24 rows selected.
    SQL> explain plan for
      2  with t as (
      3             select  count(case when sal between 0 and 100 then 1 end) cnt1,
      4                     count(case when sal between 100 and 200 then 1 end) cnt2,
      5                     count(case when sal > 200 then 1 end) cnt3
      6               from  emp
      7            )
      8  select cnt1 from t  union all
      9  select cnt2 from t  union all
    10  select cnt3 from t
    11  /
    Explained.
    SQL> @?\rdbms\admin\utlxpls
    PLAN_TABLE_OUTPUT
    Plan hash value: 2586840053
    | Id  | Operation                  | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT           |                             |     3 |    39 |     6  (67)| 00:00:01 |
    |   1 |  TEMP TABLE TRANSFORMATION |                             |       |       |            |          |
    |   2 |   LOAD AS SELECT           |                             |       |       |            |          |
    |   3 |    SORT AGGREGATE          |                             |     1 |     4 |            |          |
    |   4 |     TABLE ACCESS FULL      | EMP                         |    14 |    56 |     3   (0)| 00:00:01 |
    |   5 |   UNION-ALL                |                             |       |       |            |          |
    PLAN_TABLE_OUTPUT
    |   6 |    VIEW                    |                             |     1 |    13 |     2   (0)| 00:00:01 |
    |   7 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D662A_D5091620 |     1 |     4 |     2   (0)| 00:00:01 |
    |   8 |    VIEW                    |                             |     1 |    13 |     2   (0)| 00:00:01 |
    |   9 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D662A_D5091620 |     1 |     4 |     2   (0)| 00:00:01 |
    |  10 |    VIEW                    |                             |     1 |    13 |     2   (0)| 00:00:01 |
    |  11 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D662A_D5091620 |     1 |     4 |     2   (0)| 00:00:01 |
    18 rows selected.
    SQL> SY.

  • What is mean by index range scan and fast full scan

    What is mean by the following execution plans
    1)Table access by index rowid
    2) Index range scan
    3) Index fast full scan
    4) global index by rowid
    ..etc
    where i can get this information.In what situation CBO take these paths.Can you pls give me a link where i can find all these.I read these long time ago but not able to recollect
    Thanks
    Anand

    Oracle® Database Performance Tuning Guide
    10g Release 2 (10.2)
    Part Number B14211-01
    13.5 Understanding Access Paths for the Query Optimizer
    http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#sthref1281

  • Index vs Full Scan - Parallelism

    Hi everyone, i have an problem my scenario is a plataform Linux x64 bits in RAC 10gR2 (10.2.0.5) and we are migrating to RAC 11gR2 (11.2.0.3.3) in AIX 7.1 and my query: Update movimientos set ESTADOENCOLADO = :"SYS_B_0" where tipoproceso = :"SYS_B_1" and ESTADOENCOLADO = :"SYS_B_2"; in my Oracle 10g uses an index in the table MOVIMIENTOS and in the Oracle 11g the optimizer takes a FULL SCAN.
    In both database server the statistics are updated with estimate 100% even the system statistics, fixed tables and data dictionary are taken its statistics.
    I review the cost in both plans in Oracle 11g (with a full scan and other using a hint to index) and the full scan plan has less cost that the index. My db_file_multiblock_read_count is not set up, but in the Oracle 10g i see a value of 16 and in the 11g i see a value dinamic of 192. Understand that it too helps an uses a full scan.
    The problem is that the query taken in Oracle 10g 20 minutes, but in the Oracle 11g with full scan 1.4 h whereas with a hint takes too 20 minutes.
    I use the advisor tuning and no recommendations.
    So basicaly i fix it modifily my parameter optimizer_index_cost_adj to 80 and it works well.
    My doubt is why Oracle11gR2 says me that a full scan is faster than take an index when in the real live it is not working in this mode. I need some posible reasons please.
    Thank you very much if somebody can help me with some tip or idea.
    Regards

    >
    My doubt is why Oracle11gR2 says me that a full scan is faster than take an index when in the real live it is not working in this mode. I need some posible reasons please.
    >
    Well if you can't figure it out by looking at the plans what makes you think anyone can figure it out without looking at them?
    We have no idea what the plans contain. Post the plans, record counts for the table(s) involved, record counts for any filter predicates and the other information needed. See the FAQ for how to post a tuning request and the information needed.

  • Why "full scans are not evil, indexes are not good"

    in this article inside asktom page
    http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:9422487749968
    tell about "full scans are not evil, indexes are not good"
    someone tell me why for this select mentioned index are not good?

    ...and if you read next post, nothing is black or white, it is all shades of grey .
    This is not because your query will use index that it would be faster, and the example which Tom gave is really explicit :
    With index usage 60127 consistent gets, and without index usage 92 consistent gets
    Nicolas.
    Message was edited by:
    N. Gasparotto

  • Nested Tables and Full Table Scans

    Hello,
    I am hoping someone help can help me as I am truly scratching my head.
    I have recently been introduced to nested tables due to the fact that we have a poor running query in production. What I have discovered is that when a table is created with a column that is a nested table a unique index is automatically created on that column.
    When I do an explain plan on this table A it states that a full scan is being doine on Table A and on the nested table B. I can add an index to the offending columns to remove the full scan on Table A but the explain plan still identifies that a full scan is being done on the nested table B. Bare in mind that the column with the nested table has a cardinality of 27.
    What can I do? As I stated, there is an index on this nested table column but clearly it is being ignored.The query bombed out after 4 hours and when I ran a query to see what the record count was it was only 2046.
    Any suggestions would be greatly appreciated.
    Edited by: user11887286 on Sep 10, 2009 1:05 PM

    Hi and welcome to the forum.
    Since your question is in fact a tuning request, you need to provide us some more insights.
    See:
    [How to post a SQL statement tuning request|http://forums.oracle.com/forums/thread.jspa?threadID=863295&tstart=0]
    and also
    [When your query takes too long|http://forums.oracle.com/forums/thread.jspa?threadID=501834]
    In short:
    - database version
    - the actual queries you're executing
    - the execution plans (explain plans)
    - trace/tkprof output if available, or ask your DBA for it
    - utopiamode a small but concisive testcase would be ideal (create table + insert statements). +/utopiamode+

  • Using index in a query return few records than full table access

    Today we have an issue with a query, when it use the ok index the returned are not all records that apply to where clause condition.
    See bellow
    explain plan for
    select * from movdb.zan_m03 where
    M00AF = TO_DATE('11/01/28','YY/MM/DD') AND
    M00za = 10 AND
    m00AC = 50 AND
    M00AD between 136906 and 136999
    SELECT * FROM TABLE(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 1882720105
    | Id | Operation | Name |
    | 0 | SELECT STATEMENT | |
    | 1 | TABLE ACCESS BY INDEX ROWID| ZAN_M03 |
    |* 2 | INDEX RANGE SCAN | PK_ZAN_M03 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
    2 - access("M00AF"=TO_DATE('11/01/28','YY/MM/DD') AND "M00ZA"=10 AND
    "M00AC"=50 AND "M00AD">=136906 AND "M00AD"<=137141)
    filter("M00AD"<=137141 AND "M00AD">=136906)
    Note
    - rule based optimizer used (consider using cbo)
    20 rows selected.
    The query above return only one row insted 1579 record that apply to this conditions.
    When forcing a full table acess with a hint, the query return all records that apply, the 1579 record.
    select /*+ FULL(zan_m03) */ M00AF, M00za, m00AC , M00AD from movdb.zan_m03 where
    M00AF = TO_DATE('11/01/28','YY/MM/DD') AND
    M00za = 10 AND
    m00AC = 50 AND
    M00AD between 136906 and 137141
    Can you help me to identify what's happening?
    I am with Oracle 10g R2 10.2.0.4 standard edition
    the statistics are up to date
    the opitimizer_mode are rule, but altering in session level to all_rows happens the same issue.
    Nothing about corruption in the alert log.
    Thanks in advance
    Regards
    Cristiano

    Yes the query are the same and correct restriction for where clause are M00AD between 136906 and 137141.
    I've pasted, by mistake, another test query
    The corrects are:
    select M00AF, M00za, m00AC , M00AD from movdb.zan_m03 where
    M00AF = TO_DATE('11/01/28','YY/MM/DD') AND
    M00za = 10 AND
    m00AC = 50 AND
    M00AD between 136906 and 137141
    This use pk index and return one row
    select /*+ FULL(zan_m03) */ M00AF, M00za, m00AC , M00AD from movdb.zan_m03 where
    M00AF = TO_DATE('11/01/28','YY/MM/DD') AND
    M00za = 10 AND
    m00AC = 50 AND
    M00AD between 136906 and 137141
    This does a full table access and return 1579 records
    I´ve been searching for wrong results bugs on my oracle support, but not found one that mentions something like our issue.
    I checked the dba_tables and dba indexes and the number of rows are different, and I think this would be the same because it's is a pk.
    Look this
    SQL> select NUM_ROWS from dba_tables where table_name = 'ZAN_M03'
    2 /
    NUM_ROWS
    228527878
    select NUM_ROWS from dba_indexes where index_name = 'PK_ZAN_M03';
    SQL> select NUM_ROWS from dba_indexes where index_name = 'PK_ZAN_M03';
    NUM_ROWS
    217510185
    Is normal a index for pk having much fewer rows than table? I think not, but not sure.
    Again
    Thanks in advance
    Regards
    Cristiano

Maybe you are looking for