Full fast scan limited index

Similar Questions

• Reg - full scan limited index

  Hi Experts/gurus,
  I read Oracle http://docs.oracle.com/cd/B19306_01/server.102/b14211/optimops.htm#i52044 docs, i.e. the difference between the range index scans, full scan and full scan index restricts index. Here is the description of 'Fast Full Index Scans'
  
  Full index scans are an alternative to a full table scan when the index contains all the columns needed for the query, and at least one column in the index key has the NOT NULL constraint. A full scan accesses the data in the index itself, without access to the table. It can be used to eliminate a sort operation, because the data are not classified by the index key. It reads the entire index using multiblock bed, unlike a full index scan and can be parallelized.
  
  Therefore, the document says, the optimizer to choose index FFS, 'at least in the index key column a NOT NULL constraint', but I see less test cases is in complete contrast to what I've read.
  
  I created a table without constraints "NOT NULL".
  

  SQL> create table r_dummy(a number,b varchar2(10));
  
  Table created.
  
  SQL> insert into r_dummy select level,'hi' from dual connect by level<=20;
  
  20 rows created.
  
  SQL> commit;
  
  Commit complete.
  
  SQL> exec dbms_stats.gather_table_stats('HLODS','R_DUMMY');
  
  PL/SQL procedure successfully completed.
  
  SQL> select * from r_dummy where a <= 10;
  
           A B
  ---------- ----------
           1 hi
           2 hi
           3 hi
           4 hi
           5 hi
           6 hi
           7 hi
           8 hi
           9 hi
          10 hi
  
  10 rows selected.
  
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 2533004807
  
  -----------------------------------------------------------------------------
  | Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
  -----------------------------------------------------------------------------
  |   0 | SELECT STATEMENT  |         |    10 |    60 |     3   (0)| 00:00:01 |
  |*  1 |  TABLE ACCESS FULL| R_DUMMY |    10 |    60 |     3   (0)| 00:00:01 |
  -----------------------------------------------------------------------------
  
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  
     1 - filter("A"<=10)
  
  
  Statistics
  ----------------------------------------------------------
            0  recursive calls
            0  db block gets
            8  consistent gets
            0  physical reads
            0  redo size
          329  bytes sent via SQL*Net to client
          238  bytes received via SQL*Net from client
            2  SQL*Net roundtrips to/from client
            0  sorts (memory)
            0  sorts (disk)
           10  rows processed

  As expected under its weight "Full Table Scan", now if I have an index on columns (a, b), if my interpretation is correct, according to the docs, the optimizer should not do a "full Index scan", but Interestingly, it obeys the indication of index_ffs and did a full scan index
  

  SQL> create index r_dummy_idx on r_dummy(a,b);
  
  Index created.
  
  SQL> exec dbms_stats.gather_index_stats('HLODS','R_DUMMY_IDX');
  
  PL/SQL procedure successfully completed.
  
  SQL> select /*+index_ffs(r)*/ * from r_dummy r where a <= 10;
  
           A B
  ---------- ----------
           1 hi
           2 hi
           3 hi
           4 hi
           5 hi
           6 hi
           7 hi
           8 hi
           9 hi
          10 hi
  
  10 rows selected.
  
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 3219236618
  
  ------------------------------------------------------------------------------------
  | Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
  ------------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT     |             |    10 |    60 |     2   (0)| 00:00:01 |
  |*  1 |  INDEX FAST FULL SCAN| R_DUMMY_IDX |    10 |    60 |     2   (0)| 00:00:01 |
  ------------------------------------------------------------------------------------
  
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  
     1 - filter("A"<=10)
  
  
  Statistics
  ----------------------------------------------------------
            1  recursive calls
            0  db block gets
            4  consistent gets
            0  physical reads
            0  redo size
          330  bytes sent via SQL*Net to client
          238  bytes received via SQL*Net from client
            2  SQL*Net roundtrips to/from client
            0  sorts (memory)
            0  sorts (disk)
           10  rows processed

  This clearly shows the optimizer chooses 'INDEX FAST FULL SCAN' even though none of the indexed columns have 'NOT NULL' constraint.
  
  And there is another statement that talks about the results of the COMMAND.
  
  + "May not be used to eliminate a sort operation, because data are not classified by the index key ' +.
  
  He eliminated the sort operation, I see my results in ascending order.
  

  SQL> drop table r_dummy;
  
  Table dropped.
  
  SQL> create table r_Dummy(a number);
  
  Table created.
  
  SQL> insert into r_dummy values(10);
  
  1 row created.
  
  SQL> insert into r_dummy values(3);
  
  1 row created.
  
  SQL> insert into r_dummy values(1);
  
  1 row created.
  
  SQL> insert into r_dummy values(9);
  
  1 row created.
  
  SQL> insert into r_dummy values(5);
  
  1 row created.
  
  SQL> insert into r_dummy values(4);
  
  1 row created.
  
  SQL> insert into r_dummy values(2);
  
  1 row created.
  
  SQL> insert into r_dummy values(6);
  
  1 row created.
  
  SQL> insert into r_dummy values(7);
  
  1 row created.
  
  SQL> commit;
  
  Commit complete.
  
  SQL> select * from r_dummy;
  
           A
  ----------
          10
           3
           1
           9
           5
           4
           2
           6
           7
  
  9 rows selected.
  
  SQL> create index r_dummy_idx on r_dummy(a);
  
  Index created.
  
  SQL> set autotrace on;
  SQL> exec dbms_stats.gather_table_stats('HLODS','R_DUMMY');
  
  PL/SQL procedure successfully completed.
  
  SQL> exec dbms_stats.gather_index_stats('HLODS','R_DUMMY_IDX');
  
  PL/SQL procedure successfully completed.

  Below you can see the results in ascending order.
  

  SQL> select /*+index_ffs(r)*/ * from r_dummy r where a<=10;
  
           A
  ----------
           1
           2
           3
           4
           5
           6
           7
           9
          10
  
  9 rows selected.
  
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 3219236618
  
  ------------------------------------------------------------------------------------
  | Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
  ------------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT     |             |     9 |    27 |     2   (0)| 00:00:01 |
  |*  1 |  INDEX FAST FULL SCAN| R_DUMMY_IDX |     9 |    27 |     2   (0)| 00:00:01 |
  ------------------------------------------------------------------------------------
  
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  
     1 - filter("A"<=10)
  
  
  Statistics
  ----------------------------------------------------------
            1  recursive calls
            0  db block gets
            4  consistent gets
            0  physical reads
            0  redo size
          291  bytes sent via SQL*Net to client
          238  bytes received via SQL*Net from client
            2  SQL*Net roundtrips to/from client
            0  sorts (memory)
            0  sorts (disk)
            9  rows processed
  
  SQL>

  I am not sure if the docs are wrong or I'm reading wrong. Please help / correct me if my interpretation is poor.

  RUSSO says:
  Nicosa salvation,
  First of all, thank you for your elaborate explanation.

  Nicosa wrote:
  Will rely on data to order no order by clause and your app will be one day or the other have a bug. + (which, in fact, will not one, as the app has been designed in this way!) +

  I don't really do this, I know that even in parallel the same query may return also rows without a prescription. But was surprised to see my results neatly on INDEX NORMAL (non-partitioned). However, I make sure that I have use 'order by' when I want my results to order.

  But still I'm not sure, how the absence of constraint column 'NOT NULL' in the index would stop optimizer to do a full scan limited index

  Oracle does not index lines where all coluumns in the index are null. So, in your first example it could be possible that there is a line wiith the two a and b null. Oracle could not return this line using an index full assessment because it would not be in the index. However, by adding a predicate on a indexed columns say you actually column is not null.

  In the table, that I used in my example above, all three columns are nullable. Take into account:

  SQL> select acctno, count(*) from pttrans
    2  group by acctno;
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 3294770776
  
  --------------------------------------------------------------------------------------
  | Id  | Operation          | Name    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
  --------------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT   |         |   532K|  6239K|       | 48143   (2)| 00:09:38 |
  |   1 |  HASH GROUP BY     |         |   532K|  6239K|   107M| 48143   (2)| 00:09:38 |
  |   2 |   TABLE ACCESS FULL| PTTRANS |  5081K|    58M|       | 37895   (1)| 00:07:35 |
  --------------------------------------------------------------------------------------
  
  SQL> select acctno, count(*) from pttrans
    2  where acctno is not null
    3  group by acctno;
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 3737827862
  
  ------------------------------------------------------------------------------------------
  | Id  | Operation             | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
  ------------------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT      |          |   532K|  6239K|       | 20641   (4)| 00:04:08 |
  |   1 |  HASH GROUP BY        |          |   532K|  6239K|   107M| 20641   (4)| 00:04:08 |
  |*  2 |   INDEX FAST FULL SCAN| PTTRANS1 |  5081K|    58M|       | 10393   (2)| 00:02:05 |
  ------------------------------------------------------------------------------------------
  
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  
     2 - filter("ACCTNO" IS NOT NULL)
  

  The first query must examine acctno null to get the correct number, but the second, because I asked explicitly not null can use the index.

  John

• The doc is correct on the constraint not null and scan limited index full?

  Gave birth to the large [url http://forums.oracle.com/forums/thread.jspa?messageID=9313643] another thread:
  

  Jonathan Lewis wrote:
  >
  

  I wasn't expecting to see because the doc said about scan limited index full "...". and at least one column in the index key has the NOT NULL constraint,"which would be foolish to say if the rowid was what filled that. There are currently only 2 factory codes and code 1 company (not nulls - Oracle does know that?), so I was kind of expected Oracle to reorder the predicates with an index skip scan. Take a fresh look on the doc, I wonder if I should not specify the company code in the query and maybe spend employee and job_number in the index. I hope it's obvious that this index has been added for other queries. This request could be taken out a change in the requirements of anyway, but I don't know when.

  If you wear it as a separate thread, I'll take a look.
  Can you give a reference to the manual - the comment you quoted may not be correct.

  Just below where Hemant pointed to in the other thread, http://download.oracle.com/docs/cd/E11882_01/server.112/e16508/indexiot.htm#sthref314
  
  (Somehow I have the feeling that we had this conversation before, perhaps in a forum that no longer exists. "(Or was it all just a dream)."
  
  Edit: Also seen in
  http://download.Oracle.com/docs/CD/B28359_01/server.111/b28274/optimops.htm#i52044
  http://download.Oracle.com/docs/CD/B14117_01/server.101/b10752/optimops.htm#51111
  http://download.Oracle.com/docs/CD/F49540_01/doc/server.815/a67781/c20b_ops.htm#11004
  http://download.Oracle.com/docs/CD/B19306_01/server.102/b14211/optimops.htm#i52044
  
  and everything on the net.
  
  Edited by: jgarry 26 January 2011 17:41
  2nd edition: link fix that edit may 1 have ransacked.
  
  Edited by: jgarry January 27, 2011 10:40

  Joel,

  I just had this 'already seen' (new) sense to speak of it.

  Mentioning the reference 11.1 gave you:
  

  
  + "Index full scans are an alternative to a full table scan when the index contains all the columns needed for the query, and at least in the index key column has the constraint NOT NULL. A full scan can access the data of the index itself, without access to the table ' + '.
  

  This so obviously must be bad that I couldn't decide if I was proven wrong or was amazed to find that I couldn't he show the falsity. (Just because something is obvious, it does not mean it is true – Terry Pratchett.)

  However, here is the obvious counter-example - that I came across 8.1.7.4 because it's the oldest version of Oracle that I have now:

  create table t1
  as
  select
       rownum               id1,
       rownum               id2,
       rownum               id3,
       lpad(rownum,10,'0')     small_vc,
       rpad('x',100)          padding
  from
       all_objects
  where
       rownum <= 10000
  ;
  
  create index t1_i1 on t1(id1, id2, id3);
  
  begin
       dbms_stats.gather_table_stats(
            ownname           => user,
            tabname           =>'T1',
            cascade           => true
  
       );
  end;
  /
  
  set autotrace traceonly explain
  
  select
       /*+ index_ffs(t1) */
       id1, id3
  from
       t1
  where
       id2 = 99
  ;
  

  No 'NOT NULL columns". But any line I will have a (non-null) value for id2, then it should be in the index - then Oracle should be able to do a full scan and get the right answer. Here is the map (I have no need of Council - but your configuration may be different):

  Execution Plan
  ----------------------------------------------------------
     0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=4 Card=1 Bytes=12)
     1    0   INDEX (FAST FULL SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=4 Card=1 Bytes=12)
  

  If you change the predicate to: "id2 is zero", then the only legal path is an analysis.

  Concerning
  Jonathan Lewis
  http://jonathanlewis.WordPress.com
  http://www.jlcomp.demon.co.UK

  + "I believe in the evidence. I believe in observation, measurement and reasoning, confirmed by independent observers. I'll believe anything, no matter how wild and ridiculous, if there is evidence for it. The wildest and most ridiculous something is, however, the firmer and more solid, the evidence should be. » +
  Isaac Asimov

• index range scan and full scan limited index

  Hi master,
  
  I always think to what is the difference between index scan and scan of comprehensive systematic index range...
  
  
  comprehensive index analysis applied to the full index sheet, block and root structure.
  
  How systematic index scan range works internally? How is it different from complete systematic index scan? When to use the scan of the index systematic range? which is expensive?
  
  I like what internals discuss some docs on these, but nobody... someone knows about any link lewis j. wrote about these scans?
  
  will be useful
  
  Thanks and greetings
  VD

  Vikrant dixit says:
  I always think to what is the difference between index scan and scan of comprehensive systematic index range...

  There is essentially no difference.

  Based on a seed value, Oracle checks the root block using the partial keys stored to select which block from the next down level (typically a layer of blocks of branch) to go to.

  Since the relevant branch block, she uses the partial keys to identify which block in the level down to go to (usually a block of sheets).

  When he reached a block of sheets, it can find the first relevant key value, then scroll through the list of keys to jump to the table. If it reaches the end of the block of sheets, it uses the "next" pointer to reach the next block of relevant leaves.

  Because the optimizer has enough information to establish a baseline and a final value for the analysis, the runtime can keep journal journal moving until it hits the sheet "stop".

  The only difference between the full analysis and analysis of the range is the full scan down through the branches to the first sheet of the index and traverses the index to the last sheet. (Indeed, the starting value is less "Infinity" and the end value is "more Infinity".)

  Concerning
  Jonathan Lewis
  http://jonathanlewis.WordPress.com
  http://www.jlcomp.demon.co.UK

  "Science is more than a body of knowledge; It's a way of thinking"Carl Sagan

• Difference between Index Full Scan, and Scan select Index Full

  Quick Index Full Scan is an example of Index Full Scan, then what are the differences between Fast Full Index Scan and Index Full Scan. I have traveled the official documentation, but found it a bit complex, that no simple explanation will be great. Thanks in advance!

  Go to http://tahiti.oracle.com, select database Oracle 11g Release 2 (11.2) enter fast full scan small index in the 'Search' box, you may decide to read the results of three or four, but the fourth is setting performance Guide: the query optimizer

  Repeat the process for the analysis of comprehensive index of search term.

  Concerning

  Jonathan Lewis

• FULL TABLE SCAN even with the index, but why?

  Could someone please explain why I'd get FULL TABLE SCAN explain plan results when joining 2 tables on columns that already have clues about them? For example,.
  consider this fictional scenario:
  
  employee table with columns:
  employee # (primary key column)
  name
  
  address table with columns:
  employee # (foreign key to employee.employee #)
  subscription_type
  address
  
  Select Employee.Name since it is, address.address_type, address.address
  where employee.employee # = address.employee #.
  
  This query shows a full table scan in terms of the explain command.

  Full scan of the table is not necessarily slow and index access is not necessarily fast.

  You will recover, no doubt, most if not all the ranks on both sides. The fastest way to retrieve each row in a table is to do a table scan. Using an index, and a single block of reading for each row in a table is much less effective than to do a table scan.

  Justin

• Path to XML index table is full table scan

  Hi all

  I have a version of oracle 11.2.0.4.6 database

  Try to implement partitioning on XML indexes.

  Creates a table and index partitioned by time stamp as below.

  Whenever I'm trying to find the path table makes a full table scan.

  I have applied the fix as indicated ( Doc ID 13522189.8 ).

  So the recovery is quite slow and partition pruning does not not on XML indexes.

  Wondering if anyone has experienced the same problem?

  CREATE TABLE INCIDENT

  (

  INCIDENT_PK NUMBER (14.5).

  INCIDENTGROUPING_PK NUMBER (14.5).

  INCIDENTTYPE_PK NUMBER (14.5).

  SECURITYCLASS_PK NUMBER (14.5).

  STAMP OF INCIDENT_DATE,

  SYS INCIDENT_DETAIL. XMLTYPE

  )

  TABLESPACE DATA_TBS_INCIDENT

  PCTUSED 0

  PCTFREE 10

  INITRANS 1

  MAXTRANS 255

  STORAGE)

  64K INITIALS

  MINEXTENTS 1

  MAXEXTENTS UNLIMITED

  PCTINCREASE 0

  DEFAULT USER_TABLES

  )

  LOGGING

  NOCOMPRESS

  PARTITION BY RANGE (INCIDENT_DATE)

  (PARTITION SEP2013_WEEK1 VALUES LESS THAN (to_timestamp (' 00:00:00.00 2013-09-08 ',' YYYY-MM-DD HH24:MI:SS.))) FF2')),

  PARTITION SEP2013_WEEK2 VALUES LESS THAN (to_timestamp ('2013-09-15 00:00:00.00 ',' YYYY-MM-DD HH24:MI:SS.)) FF2')),

  PARTITION SEP2013_WEEK3 VALUES LESS THAN (to_timestamp ('2013-09-22 00:00:00.00 ',' YYYY-MM-DD HH24:MI:SS.)) FF2')),

  ..........);

  CREATE the INDEX INCIDENTxdb_idx

  ON corpaudlive. INCIDENT (INCIDENT_detail) INDEXTYPE IS XDB. LOCAL XMLINDEX 10 PARALLEL

  PARAMETERS (' PATH TABLE INCIDENT_PATHTABLE (TABLESPACE DATA_TBS_INCIDENT))

  PIKEY INDEX INCIDENT_PATHTABLE_PIKEY_IX (TABLESPACE IDX_TBS_INCIDENT)

  PATH ID INDEX INCIDENT_PATHTABLE_ID_IX (TABLESPACE IDX_TBS_INCIDENT)

  INCIDENT_PATHTABLE_VALUE_IX VALUE INDEX (TABLESPACE IDX_TBS_INCIDENT)

  ORDER KEY INDEX INCIDENT_PATHTABLE_KEY_IX (TABLESPACE IDX_TBS_INCIDENT)

  Paths (INCLUDE (//forename //surname //postcode //dateofbirth //street //town))');

  SQL > explain the plan for

  2 Select INCIDENT_pk in INCIDENT where XMLEXISTS ('/ / name [text () = 'john']' by the way of INCIDENT_detail)

  3 and XMLEXISTS ("/ / name [text () 'clark' =]' by the way of INCIDENT_detail")

  4 and a.INCIDENT_date between TO_TIMESTAMP (January 10, 2014 ',' DD/MM/YYYY "")

  5 and TO_TIMESTAMP (September 10, 2014 ',' DD/MM/YYYY ');

  He explained.

  Elapsed time: 00:00:02.77

  SQL > select * from table (dbms_xplan.display);

  PLAN_TABLE_OUTPUT

  --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  Hash value of plan: 123057549

  -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  | ID | Operation                                       | Name                           | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |    TQ | IN-OUT | PQ Distrib.

  -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  |   0 | SELECT STATEMENT |                                |     1.    70.  1803 (5) | 00:00:22 |       |       |        |      |            |

  |   1.  COORDINATOR OF PX |                                |       |       |            |          |       |       |        |      |            |

  |   2.   PX SEND QC (RANDOM). : TQ10003 |     1.    70.  1803 (5) | 00:00:22 |       |       |  Q1, 03 | P > S | QC (RAND) |

  |   3.    SEMI NESTED LOOPS.                                |     1.    70.  1803 (5) | 00:00:22 |       |       |  Q1, 03 | SVCP |            |

  |   4.     NESTED LOOPS |                                |     1.    57.  1800 (5) | 00:00:22 |       |       |  Q1, 03 | SVCP |            |

  |   5.      VIEW                                       | VW_SQ_1                        |   239.  5975 |  1773 (5) | 00:00:22 |       |       |  Q1, 03 | SVCP |            |

  PLAN_TABLE_OUTPUT

  --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  |   6.       UNIQUE HASH |                                |   239. 25334 |            |          |       |       |  Q1, 03 | SVCP |            |

  |   7.        RECEIVE PX |                                |   239. 25334 |            |          |       |       |  Q1, 03 | SVCP |            |

  |   8.         PX SEND HASH | : TQ10002 |   239. 25334 |            |          |       |       |  Q1, 02 | P > P | HASH |

  |   9.          UNIQUE HASH |                                |   239. 25334 |            |          |       |       |  Q1, 02 | SVCP |            |

  | * 10 |           HASH JOIN |                                |   239. 25334 |  1773 (5) | 00:00:22 |       |       |  Q1, 02 | SVCP |            |

  |  11.            KIND OF BUFFER.                                |       |       |            |          |       |       |  Q1, 02 | ISSUE |            |

  |  12.             RECEIVE PX |                                |     1.    22.     3 (0) | 00:00:01 |       |       |  Q1, 02 | SVCP |            |

  |  13.              PX SEND BROADCAST | : TQ10000 |     1.    22.     3 (0) | 00:00:01 |       |       |        | S > P | BROADCAST |

  |  14.               TABLE ACCESS BY INDEX ROWID | X$ PT74MSS0WBH028JE0GUCLBK0LHM4 |     1.    22.     3 (0) | 00:00:01 |       |       |        |      |            |

  | * 15 |                INDEX RANGE SCAN | X$ PR74MSS0WBH028JE0GUCLBK0LHM4 |     1.       |     2 (0) | 00:00:01 |       |       |        |      |            |

  | * 16.            HASH JOIN |                                | 12077 |   990K |  1770 (5) | 00:00:22 |       |       |  Q1, 02 | SVCP |            |

  PLAN_TABLE_OUTPUT

  --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  |  17.             RECEIVE PX |                                |   250K |    10 M |    39 (0) | 00:00:01 |       |       |  Q1, 02 | SVCP |            |

  |  18.              PX SEND BROADCAST | : TQ10001 |   250K |    10 M |    39 (0) | 00:00:01 |       |       |  Q1, 01 | P > P | BROADCAST |

  |  19.               SYSTEM PARTITION ALL |                                |   250K |    10 M |    39 (0) | 00:00:01 |     1.   112.  Q1, 01 | ISSUE |            |

  | * 20.                TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE |   250K |    10 M |    39 (0) | 00:00:01 |     1.   112.  Q1, 01 | SVCP |            |

  | * 21.                 INDEX RANGE SCAN | INCIDENT_PATHTABLE_VALUE_IX |   161.       |    25 (0) | 00:00:01 |     1.   112.  Q1, 01 | SVCP |            |

  |  22.             ITERATOR BLOCK PX |                                |   221 M |  8865M |  1671 (1) | 00:00:21 |    53.    54.  Q1, 02 | ISSUE |            |

  | * 23.              TABLE ACCESS FULL | INCIDENT_PATHTABLE |   221 M |  8865M |  1671 (1) | 00:00:21 |    53.    54.  Q1, 02 | SVCP |            |

  | * 24.      TABLE ACCESS BY ROWID USER | INCIDENT |     1.    32.     1 (0) | 00:00:01 | ROWID | ROWID |  Q1, 03 | SVCP |            |

  | * 25.     SEE PUSHED PREDICATE. VW_SQ_2                        |     1.    13.    20 (0) | 00:00:01 |       |       |  Q1, 03 | SVCP |            |

  |  26.      NESTED LOOPS |                                |     1.   106.    20 (0) | 00:00:01 |       |       |  Q1, 03 | SVCP |            |

  |  27.       NESTED LOOPS |                                |     4.   106.    20 (0) | 00:00:01 |       |       |  Q1, 03 | SVCP |            |

  PLAN_TABLE_OUTPUT

  --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  |  28.        NESTED LOOPS |                                |     4.   256.     8 (0) | 00:00:01 |       |       |  Q1, 03 | SVCP |            |

  |  29.         TABLE ACCESS BY INDEX ROWID | X$ PT74MSS0WBH028JE0GUCLBK0LHM4 |     1.    22.     3 (0) | 00:00:01 |       |       |  Q1, 03 | SVCP |            |

  | * 30 |          INDEX RANGE SCAN | X$ PR74MSS0WBH028JE0GUCLBK0LHM4 |     1.       |     2 (0) | 00:00:01 |       |       |  Q1, 03 | SVCP |            |

  |  31.         ITERATOR SYSTEM PARTITION.                                |     4.   168.     5 (0) | 00:00:01 |    53.    54.  Q1, 03 | SVCP |            |

  | * 32 |          TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE |     4.   168.     5 (0) | 00:00:01 |    53.    54.  Q1, 03 | SVCP |            |

  | * 33 |           INDEX RANGE SCAN | INCIDENT_PATHTABLE_PIKEY_IX |     4.       |     4 (0) | 00:00:01 |    53.    54.  Q1, 03 | SVCP |            |

  |  34.        ITERATOR SYSTEM PARTITION.                                |     1.       |     2 (0) | 00:00:01 |   KEY |   KEY |  Q1, 03 | SVCP |            |

  | * 35 |         INDEX RANGE SCAN | INCIDENT_PATHTABLE_KEY_IX |     1.       |     2 (0) | 00:00:01 |   KEY |   KEY |  Q1, 03 | SVCP |            |

  | * 36 |       TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE |     1.    42.     3 (0) | 00:00:01 |     1.     1.  Q1, 03 | SVCP |            |

  -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  PLAN_TABLE_OUTPUT

  --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  Information of predicates (identified by the operation identity card):

  ---------------------------------------------------

  10 - access("SYS_P9".") PATHID '=' ID')

  Access (SYS_PATH_REVERSE ("PATH") 15 - > = HEXTORAW ('02582E') AND SYS_PATH_REVERSE ("PATH") < HEXTORAW ('02582EFF'))

  16 - access("SYS_P11".") RID "IS 'SYS_P9'." GET RID OF"AND TBL$ OR$ IDX$ PART$ NUM ("CORPAUDLIVE". "THE INCIDENT", 0,7,65535, "SYS_P9" "." " "RID") = TBL$ OR$ IDX$ PART$ NUM ("CORPAUDLIVE". "INCIDENT_PATHTAB

  THE', 0,7,65535, ROWID))

  filter ("SYS_P9". "ORDER_KEY" < = 'SYS_P11' "." " ORDER_KEY' AND 'SYS_P11 '. "" ORDER_KEY "< SYS_ORDERKEY_MAXCHILD ("SYS_P9". "ORDER_KEY")) "

  20 filter (SYS_XMLI_LOC_ISTEXT ("SYS_P11". "LOCATOR", "SYS_P11" "." " PATHID') = 1)

  21 - access("SYS_P11".") The VALUE "= 'John')

  23 filter (SYS_XMLI_LOC_ISNODE ("SYS_P9". "LOCATOR") = 1 AND SYS_OP_BLOOM_FILTER (: BF0000, "SYS_P9".) " PATHID'))

  PLAN_TABLE_OUTPUT

  --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  24 - filter("A".") INCIDENT_DATE' > = TIMESTAMP' 2014 - 10 - 01 00:00:00.000000000 "AND"A"". "" INCIDENT_DATE"< = TIMESTAMP' 2014 - 10 - 09 00:00:00.000000000' AND

  "ITEM_2" = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT", 0,7,65535, "A". ROWID))

  25 filter ("ITEM_4" = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT", 0,7,65535, "A".) ROWID))

  30 - access (SYS_PATH_REVERSE ("PATH") > = HEXTORAW('027FF9') AND SYS_PATH_REVERSE ("PATH") < HEXTORAW ('027FF9FF'))

  32 filter (SYS_XMLI_LOC_ISNODE ("SYS_P2". "LOCATOR") = 1) "

  33 - access("SYS_P2".") GET RID OF"="A ". ROWID AND 'SYS_P2 '. ("' PATHID '=' ID ')

  35 - access("SYS_P4".") GET RID OF"="A ". ROWID AND 'SYS_P2 '. "" ORDER_KEY "< ="SYS_P4. " "" ORDER_KEY "AND"SYS_P4 ". "" ORDER_KEY "< SYS_ORDERKEY_MAXCHILD ("SYS_P2". "ORDER_KEY")) "

  filter ("SYS_P4". "RID"IS "SYS_P2"." GET RID OF"AND TBL$ OR$ IDX$ PART$ NUM("INCIDENT",0,7,65535,"SYS_P2".") "RID") = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT_PATHTABL

  E «(, 0,7,65535, ROWID)).

  36 - filter("SYS_P4".") The VALUE '= 'clark' AND SYS_XMLI_LOC_ISTEXT ("SYS_P4".' LOCATOR', 'SYS_P4 '. (("" PATHID ') = 1).

  PLAN_TABLE_OUTPUT

  --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  Note

  -----

  -dynamic sample used for this survey (level = 6)

  69 selected lines.

  Elapsed time: 00:00:00.47

  SQL > spool off

  Thank you

  CenterB

  You must create a XMLIndex with two groups:

  create table actionnew)

  number of action_pk

  action_date timestamp

  action_detail xmltype

  )

  partition by (range (action_date)

  partition values before_2015 less (timestamp ' 2015-01-01 00:00:00 ')

  , partition values jan_2015 less (timestamp ' 2015-02-01 00:00:00 ')

  , partition values feb_2015 less (timestamp ' 2015-03-01 00:00:00 ')

  );

  create index actionnew_sxi on actionnew (action_detail)

  indexType is xdb.xmlindex

  local

  parameters (q'~)

  Group my_group_1

  XMLTable actionnew_xt1

  "/ audit/action_details/screen_data/tables/table/row.

  path of varchar2 (100) the columns "name".

  , path of surname varchar2 (100) "first name".

  Group my_group_2

  XMLTable actionnew_xt2

  "/ audit/action_details/fields.

  path of varchar2 (100) the columns "name".

  , path of surname varchar2 (100) "first name".

  ~'

  );

  Select x.*

  to actionnew t

  xmltable)

  "/ audit/action_details/screen_data/tables/table/row.

  in passing t.action_detail

  path of varchar2 (100) the columns "name".

  , path of surname varchar2 (100) "first name".

  ) x

  where t.action_date between timestamp ' 2015-02-01 00:00:00 '

  and timestamp ' 2015-03-01 00:00:00 '

  and x.forename = 'anwardo. '

  and x.surname = 'gram '.

  ;

• Index on non unique values in order to avoid the full table scan

  I have a table with > 100 k records. The table is updated only during the race every night. All columns except one have non - unique values and I am querying the table with this request.
  
  COL3 - non - unique values - only 40 distinct values
  unique values - no - COL4 - 1000 distinct values
  last_column - 100 k unique values
  
  Select last_column in the table_name where in (...) col3 or col4 (...)
  
  I tried to create a Bitmap index individually on col3 and col4 and also combined. However, in both cases, it performs a full table scan.
  
  Please, help me optimize this query as it is used in the term altogether the system and the cost of the query is very high around 650.
  
  I don't have much experience with popular indexes then all tracks.
  
  Thank you
  Sensey
  
  Published by: user13312817 on November 7, 2011 11:32

  An alternative might be to use a union instead and the 2 index:

  create index my_index1 on my_table (col3, last_column) compress 1;
  create index my_index2 on my_table (col4, last_column) compress 1;

  Select last_column from my_table
  where col3 in (...)
  Union
  Select last_column from my_table
  where col4 (...)

  In other words, if the UNION would apply here whereas in double values for last_column will be deleted.

• CBO: full instead of bitmap index use, why table scan?

  I have a query in which it is clearly benefitial to use the bitmap index, rather oracle goes for the full table scan. Could you please shed some light on this? Because even a hint does not help, I guess that something prevents oracle (11.1.0.7.0) to use it in a sort of range index scan pass.
  
  installation program:

  create table test_distance (
  x_display number,
  y_display number,
  x_rough number(5,2) as (trunc(x_display,2)),
  y_rough number(5,2) as (trunc(y_display,2)));
  
  insert into test_distance (x_display,y_display) 
  (select dbms_random.value(-180,180), dbms_random.value(-90,90) from dual connect by level < 200000);
  
  create bitmap index test_bm_xrough on test_distance(x_rough);
  create bitmap index test_bm_yrough on test_distance(y_rough);
  
  create or replace function  western_bbox_longitude(x binary_double, y binary_double, radius binary_double) return number
  is
  begin
    --simplified
   return x - 0.0001*radius;
  end;
  /
  
  exec dbms_stats.gather_table_stats(user,'TEST_DISTANCE',cascade=>true,estimate_percent=>100);

  several select statements:

  --remember x and y values and use them in the subsequent queries.
  select * from test_distance where rownum = 1;
  
  alter session set statistics_level = all;
  
  --no bind variable, no function call -> proper plan
  select * from test_distance where x_rough = 16.14 and y_rough = -35.53;
  select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
  
  --with bind variable, no function call -> still proper plan
  select * from test_distance where x_rough = :xin and y_rough = :yin;
  select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
  
  --using between, bind variable, no function call -> proper plan
  select * from test_distance where x_rough between :xin-0.01 and :xin and y_rough between :yin-0.01 and :yin;
  select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
  
  
  --full table scan, why?
  select td.*,
  trunc(western_bbox_longitude(:xin,:yin,:radius),2)
  from test_distance td 
  where x_rough = trunc(
  western_bbox_longitude(:xin,:yin,:radius),2);
  select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
  
  --forcing oracle to use the index results in bitmap index full instead of range scan, why?
  select /*+ index( td test_bm_xrough) */ td.*,
  trunc(western_bbox_longitude(:xin,:yin,:radius),2)
  from test_distance td 
  where x_rough = trunc(
  western_bbox_longitude(:xin,:yin,:radius),2);
  select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
  
  --guessing it might be related to the selectivity of the function doesn't change the plan either
  associate statistics with functions western_bbox_longitude default selectivity 0.001;

  Ah sorry, I somehow read the wrong line in your initial statement where it between the function has been used.

  Yes it is possible that the selectivity of the function plays a role here. More likely may be the order of execution for the undeterministic functions is then different for literals. However, you can try to work around this problem by using a few different approaches.

  encapsulate the function inside a double subseelct

  select /*+ index( td test_bm_xrough) */ td.*,
     (select trunc(western_bbox_longitude(:xin,:yin,:radius),2))
  from test_distance td
  where x_rough = (select trunc(western_bbox_longitude(:xin,:yin,:radius),2) from dual);
  

  This should allow to cache the result of the function to a certain extent. Otherwise, the result of the function may be recalculated for each row in the test_distance table.

  The same can be achieved with a WITH clause
  not tested

  with wboxlong as (select trunc(western_bbox_longitude(:xin,:yin,:radius),2) xrough from dual)
  select /*+ index( td test_bm_xrough) */ td.*,
     x.xrough
  from test_distance td
  join wboxlong x on td.x_rough = x.xrough
  

  Also note that your tip worked. Oracle uses the bitmap indexes to access the data. Index indicator indicates to the CBO to use this index if possible, but is not on the path. If you want a different plan, you can try to apply also the path combined with a suspicion as NO_INDEX_FFS (http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements006.htm#SQLRF50413).

  Published by: Sven w. on January 3, 2011 18:57

• Tuning sql insert that inserts 1 million lines makes a full table scan

  Hi Experts,

  I'm on Oracle 11.2.0.3 on Linux. I have a sql that inserts data into a table of History/Archives of a table main application based on the date. The application table has 3 million lines. and all the lines that are more then 6 months old must go in a table of History/Archives. This was decided recently, and we have 1 million rows that meet this criterion. This insertion in table archive takes about 3 minutes. Plan of the explain command shows a full table scan on the main Board - which is the right thing, because we are pulling 1 million rows in the main table in the history table.

  My question is that, is it possible that I can do this sql go faster?

  Here's the query plan (I changed the names of table etc.)

     INSERT INTO EMP_ARCH
     SELECT *
  FROM EMP M
  where HIRE_date < (sysdate - :v_num_days);
  call     count       cpu    elapsed       disk      query    current        rows
  ------- ------  -------- ---------- ---------- ---------- ----------  ----------
  Parse        2      0.00       0.00          0          0          0           0
  Execute      2     96.22     165.59      92266     147180    8529323     1441230
  Fetch        0      0.00       0.00          0          0          0           0
  ------- ------  -------- ---------- ---------- ---------- ----------  ----------
  total        4     96.22     165.59      92266     147180    8529323     1441230
  Misses in library cache during parse: 1
  Misses in library cache during execute: 1
  Optimizer mode: FIRST_ROWS
  Parsing user id: 166
  Rows     Row Source Operation
  -------  ---------------------------------------------------
  1441401   TABLE ACCESS FULL EMP (cr=52900 pr=52885 pw=0 time=21189581 us)
  
  
  

  I heard that there is a way to use opt_param tip to increase the multiblock read County but did not work for me... I will be grateful for suggestions on this. can collections and this changing in pl/sql also make it faster?

  Thank you

  OrauserN

  (1) create an index on hire_date

  (2) tip 'additional' use in the 'select' query '

  (3) run ' alter session parallel DML'; before you run the entire statement

• Why "FULL TABLE SCAN?

  I have a table with 831 k lines and index:

  CREATE TABLE "ROGADM"."ROG_LOG" (
      "LOG_ID"       NUMBER(10,0),
      "LOG_OBK_TYP"  VARCHAR2(30 BYTE),
      "LOG_OBK_ID"   VARCHAR2(200 BYTE),
      "LOG_TYP"      VARCHAR2(30 BYTE),
      "LOG_RODZAJ"   VARCHAR2(30 BYTE),
      "LOG_R_OBK_ID" VARCHAR2(200 BYTE),
      "LOG_DATA_ZDARZENIA" DATE,
      "LOG_OPIS_ZDARZENIA" VARCHAR2(4000 BYTE),
      "LOG_UTWORZYL"       VARCHAR2(30 BYTE),
      "LOG_KIEDY_UTWORZYL" DATE,
      CONSTRAINT "LOG_PK" PRIMARY KEY ("LOG_ID")
  );
  CREATE INDEX "ROGADM"."LOG_I" ON "ROGADM"."ROG_LOG" (
      "LOG_OBK_ID",
      "LOG_OBK_TYP",
      "LOG_TYP",
      "LOG_RODZAJ"
  );
  CREATE INDEX "ROGADM"."LOG_I2" ON "ROGADM"."ROG_LOG" (
      "LOG_R_OBK_ID",
      "LOG_RODZAJ"
  );
  CREATE UNIQUE INDEX "ROGADM"."LOG_PK" ON "ROGADM"."ROG_LOG" (
      "LOG_ID"
  );

  When I run of EXPLAIN PLAN for the sql:

  SELECT log_obk_id FROM rog_log;

  the output is

  PLAN_TABLE_OUTPUT
  Plan hash value: 3822058985
   
  -----------------------------------------------------------------------------
  | Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
  -----------------------------------------------------------------------------
  |   0 | SELECT STATEMENT  |         |   831K|  8122K|  2240   (2)| 00:00:27 |
  |   1 |  TABLE ACCESS FULL| ROG_LOG |   831K|  8122K|  2240   (2)| 00:00:27 |
  -----------------------------------------------------------------------------

  Why?

  You have an index on the LOG_OBK_ID column. But when you select this column see you FULL TABLE SCAN and no index is used.

  This is because you have not set your column as NOT NULL value column. Oracle stores a NULL value in the index. And that is why when you query the table for LOG_OBK_ID he goes to the table and does not use the index.

  See the example below

  SQL> create table my_test ( object_id number not null, object_type varchar2(100), object_name varchar2(100));
  
  Table created.
  
  SQL> create index my_test_idx on my_test(object_id, object_type);
  
  Index created.
  
  SQL> insert into my_test
    2  select object_id, object_type, object_name
    3    from all_objects
    4   where rownum <= 100000
    5  /
  
  50058 rows created.
  
  SQL> commit
    2  /
  
  Commit complete.
  
  SQL> exec dbms_stats.gather_table_stats('KARTHICK_PATTABIRAMAN','MY_TEST',cascade=>true)
  
  PL/SQL procedure successfully completed.
  
  SQL> explain plan for select object_id from my_test
    2  /
  
  Explained.
  
  SQL> select * from table(dbms_xplan.display)
    2  /
  
  PLAN_TABLE_OUTPUT
  --------------------------------------------------------------------------------
  Plan hash value: 720752151
  ------------------------------------------------------------------------------------
  | Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time   |
  ------------------------------------------------------------------------------------
  PLAN_TABLE_OUTPUT
  --------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT     |             | 50058 |   244K|    36   (0)| 00:00:01 |
  |   1 |  INDEX FAST FULL SCAN| MY_TEST_IDX | 50058 |   244K|    36   (0)| 00:00:01 |
  ------------------------------------------------------------------------------------
  
  8 rows selected.
  

  See the index is used. Oracle considers the index as a Skinny table version and do a FULL scan on the INDEX and not on the TABLE.

  Now, let us remove the NOT NULL constraint and see what happens.

  SQL> alter table my_test modify object_id null
    2  /
  
  Table altered.
  
  SQL> desc my_test
   Name                                      Null?    Type
   ----------------------------------------- -------- ----------------------------
   OBJECT_ID                                          NUMBER
   OBJECT_TYPE                                        VARCHAR2(100)
   OBJECT_NAME                                        VARCHAR2(100)
  
  SQL> exec dbms_stats.gather_table_stats('KARTHICK_PATTABIRAMAN','MY_TEST',cascade=>true)
  
  PL/SQL procedure successfully completed.
  
  SQL> explain plan for select object_id from my_test
    2  /
  
  Explained.
  
  SQL> select * from table(dbms_xplan.display)
    2  /
  
  PLAN_TABLE_OUTPUT
  --------------------------------------------------------------------------------
  Plan hash value: 1615681525
  
  -----------------------------------------------------------------------------
  | Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
  -----------------------------------------------------------------------------
  |   0 | SELECT STATEMENT  |         | 50058 |   244K|    67   (0)| 00:00:01 |
  |   1 |  TABLE ACCESS FULL| MY_TEST | 50058 |   244K|    67   (0)| 00:00:01 |
  -----------------------------------------------------------------------------
  
  8 rows selected.
  
  SQL>
  

  See oracle now goes for FULL TABLE SCAN.

• Simple query in Oracle Table in MS Access causes a full table scan.

  I run a very simple query in MS ACCESS to an Oracle table attached as follows:
  
  Select *.
  EXPRESS_SERVICE_EVENTS-(EXPRESS is the name of the related table. SERVICE_EVENTS)
  When executed > MyDate()
  
  or
  
  Select *.
  EXPRESS_SERVICE_EVENTS-(EXPRESS is the name of the related table. SERVICE_EVENTS)
  When executed > [Forms]! [MyForm]! [Date1]
  
  We have more than 50 machines and this query works well on more than half of them, using an Oracle Index on the field "run." Exactly the same thing running on other machines results in a full table scan, so regardless of the index (the DB access even access all machines).
  
  Strangely, if we write the query as follows:
  
  Select *.
  Of EXPRESS_SERVICE_EVENTS
  When executed > # 2009-09-04 08:00 #.
  
  It works fast everywhere!
  
  Any help with this "phenominon" would be appreciated.
  
  We did the things:
  Check the locale settings of the ODBC driver, MS Access settings (as in tools-> Options), we have the latest XP and Office service packs and re-related all the Access Tables on the slow and fast machines independently).

  All machines use the same version of the ODBC driver?

  If you have access to Metalink, check the following note:
  Note.257828.1 Scan of Table full Ext/Pub while seeking the DATE columns using the ODBC Oracle driver:

  In a Word, try "bind timestamp date" option in the dsn configuration and do not forget to update the links in the table.

  It will be useful,
  Greg

• How to remove a Trojan horse, full system scan detectected Essentials: Rougue.Win32/winweb

  I have Win. Vista, 32-bit & very limited computer. My MS Essentials full system scan detectected: Rougue.Win32/winweb. Catagory: Trojan, Alert: serious, recommended Action: Remove. In Histrory , he shows the action is: ADMITTED.  Why is this? How can I remove this?

  Hello

  Download update and scan with the free version of malwarebytes anti-malware

  http://www.Malwarebytes.org/MBAM.php

  You should also download and run rkill to stop the process of problem before you download and scan with malwarebytes

  http://www.bleepingcomputer.com/download/anti-virus/rkill

  If it does not remove the problem and or work correctly in normal mode do work above in safe mode with networking

  Windows Vista

  Using the F8 method:

  1. Restart your computer.
  2. When the computer starts, you will see your computer hardware are listed. When you see this information begins to tap theF8 key repeatedly until you are presented with theBoot Options Advanced Windows Vista.
  3. Select the Safe Mode with networking with the arrow keys.
  4. Then press enter on your keyboard to start mode without failure of Vista.
  5. To start Windows, you'll be a typical logon screen. Connect to your computer and Vista goes into safe mode.
  6. Do whatever tasks you need and when you are done, reboot to return to normal mode.

• How do full table scan

  Hi all

  I have a table which is accesed by application every 5 seconds. Now, this table has several delete insert updates current. The table size is aprox 200 MB (high tide) and there is say 5 ranks, which will be a sentence of 20 to 30 KB. My CMS is say 2 GB. So now the stats are not met and there is no index in this table. Now I see full table scan as his wait event. Now, I want to know.

  How a scan full of tabel happens Oracle load the entire 200MB of data in the SGA and then do a table scan or should just the actual size used by the table IE 20 to 30 KB.

  Thank you

  A

  Hello

  high waters is precisely the limit up to which Oracle must read to be sure that all the data has been seen, so if you have only about 30 KB of data in the table, even if the data is in the first a few blocks from the table, a complete analysis must read the 200 MB (which is not so good but takes more time to read a few blocks). (the reason is that it was once the data written in this block and it triggered the HWM),

  You can reorganize the table (alter table mytable move or use DBMS_REDEFINITION so that you can do this, the application uses the table) to reset the HWM. ("If the current small" size used"is transient and if you expect the table to increase again to use 200 MB or more, don't need to reorg; do it if you are confident that the table will remain very weak)

  Best regards

  Brno Vroman.

• Is it reasonable to require a Full table Scan (Direct path read) on a large Table

  Hello

  I have an Oracle 11.2.0.3 on a Sun Solaris 10 sparc with SGA 25 GB machine

  One of my made SQL an analysis of indexes on the table to 45 GB where the size of the index is 14FR and the thourghput for the sequential read is 2MBPS.

  so now (Index) 14 000 Mo, 14 GB / 2 MB = dry 7000 = 2 hours to scan the index.

  Flow of the direct path read is 500 Mbps for an another SQL and reads assimilate them all live.

  and because of this flow, a read (FTS) of direct path on the table of 7 GB out in 12-13 seconds. So in my case, it probably takes 100 seconds to scan the entire table. It is a monthly report and does not often.

  Should I try to use a trick to force sql to do a full scan and exploit the possibilities of direct reading and is done in a few minutes? Assuming it to do a FTS (direct play)

  Of course, it will be tested and verified, but the question is, is this a sensible apprioach? is - anyone has experience by forcing it?

  Any suggestions would be helpful... I'll test this on a different machine tomorrow.

  Best regards

  Maran

  82million lines and a grouping of 18million factor?  And really 17million from lines to recover?  However, your result set after the hash join is 3500 lines, although the optimizer expects 16 lines.

  I would say that the statistics are not representative or not in use for this SQL.  Certainly, the index does not match query predicates.

  The fact that the index is also using the virtual columns only adds to confusion.

  Hemant K Collette