calculate vs believe the index statistics

Hello

No one knows what criteria can be used to evaluate when it is necessary to calculate statistics vs statistical estimate on an index?

I'm in a situation where I'd like to collect statistics on all indexes of production DB. The indexes are on the tables that vary considerably in size from very small (< 10 records) to the very large (> 150 million records). Based on previous experience, I think stats estimate would be appropriate on the index of the largest tables and computer stats would be appropriate on the indexes of smaller tables. The reason to be here, it is that when I tried to compute statistics on major indexes, it took several hours to complete each. It was not ideal because I have a small window to calculate the index statistics. Alternatively, there are some indexes of average size that is currently estimated, and I'm fairly certain they would benefit calculation of stats.

I thought that I had read a few Oracle somewhere documentation that explains how to evaluate when it is appropriate to calculate the estimate of the vs, but I can't seem to find it.

EDIT: I should mention that it's in a DB 10 gr 2 (10.2.0.3)

Advice or assistance in this matter would be greatly appreciated.

Thank you very much.

Published by: x94qvi on November 14, 2010 19:02

Hello

Please read these articles by Tom, who will give you a clear understanding between calculation vs estimate for any object can be a table or index

http://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:432169917482

http://download.Oracle.com/docs/CD/B19306_01/server.102/b14211/stats.htm

Thank you

Published by: CKPT November 15, 2010 08:21

Tags: Database

Similar Questions

  • DBMS_STATS can. COPY_TABLE_STATS cause of index statistics be NEWLYgatered?

    Hi all

    The BP is 11.2.0.3 on a linux machine.

    In my production DB, I published the following command to copy table statistics / index between partitions.

    = > EXEC DBMS_STATS. COPY_TABLE_STATS (OWNNAME = > 'AA', TABNAME = > AA_TABLE, SRCPARTNAME = > 'P201302', DSTPARTNAME = > 'P201303');

    The command above cause the index statistics to collect 'NEWLY' instead of copying the table statistics / index?
    After that I issued the command, some of the index partitions'statistics are newly collected (last_analyzed).

    I'm still not sure that two things are between the relationship of cause and effect.

    Thanks in advance.
    Best regards.

    Please check below doc

    http://oracledoug.com/Serendipity/index.php?/archives/1596-statistics-on-partitioned-tables-part-6a-COPY_TABLE_STATS.html

    Hope this helps,

    Concerning
    ORA-01031: insufficient privileges
    http://www.oracleracexpert.com
    http://www.oracleracexpert.com/2013/02/ora-01031-insufficient-privileges.html
    How to change the Oracle DBNAME and DBID
    http://www.oracleracexpert.com/2013/02/how-to-change-Oracle-dbname-and-dbid.html

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

    Hi guys,.

    Let's say I have an index on a column.
    Tables and index statistics were collected. (without the histograms).

    Let's say I have run a select * from table where a = 5;
    Oracle will perform a complete analysis.
    But what statistics, it will be able to know indeed the greater part of the column = 5? (histograms do not used)

    After analysis, we get the following:
    Statistical table:
    (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)

    Thank you





    Index of column (A)
    ======
    1
    1
    2
    2
    5
    5
    5
    5
    5
    5

    I have prepared a few explanations and did not notice that the topic has been marked as answer.

    My sentence is not quite true.

    A column "without histograms' means that the column has only a bucket.

    More correct: even without the histogram there are data in dba_tab_histograms which can be considered a bucket for the whole column. In fact, these data are extracted from hist_head$, not from $ histgrm as usual buckets.
    Technically there are no buckets without combined histograms.

    Let's create a table with the asymmetric 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     999998
    

    So, we have table with the very uneven distribution of the data.
    We collect 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            C104
    

    Therefore, Oracle suggests that the values between 1 and 3 (raw C102 C104) are distributed uniform and the density of the distribution is 0.33.
    We will try to explain the 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)
    

    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: 0
    

    FTS here costs 300 and Index Range Scan here costs 2377.
    I disabled cpu cost, so the selectivity does not affect the cost of FTS.
    cost of the Index Range Scan is calculated as
    blevel + (leaf_blocks * selectivity + clustering_factor * selecivity) = 2 + (4017 * 0.33333 + 3107 * 0.33333) = 2377.
    Oracle believes that he must read 2 blocks root/branch index, 1339 the index leaf blocks and 1036 blocks in the table.
    Pay attention that the selectivity is the main component of the cost of the Index Range Scan.

    We will try to collect 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 completed
    

    If you look at dba_tab_histograms you can see more

    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         1000000
    

    ENDPOINT_VALUE is the value of the column (in number for any type of data) and ENDPOINT_NUMBER is the cumulative number of lines.
    Number of lines for any ENDPOINT_VALUE = ENDPOINT_NUMBER for this ENDPOINT_VALUE - ENDPOINT_NUMBER to the previous ENDPOINT_VALUE.

    explain the plan and track 10053 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: 0
    

    Be careful on selectivity, ix_sel: 1.0000e - 06
    Cost of the FTS is always the same = 300,
    but the cost of the Index Range Scan is now 4: 2 blocks from root/branch + block 1 sheet + 1 table blocks.

    So, conclusion: histograms to calculate more accurate selectivity. The goal is to have more efficient execution plans.

    Alexander Anokhin
    http://alexanderanokhin.WordPress.com/

  • Calculate the disk space required for the INDEX

    Hello

    How to calculate the disk space required to create an INDEX? Please tell me where I can get the details of resources.

    For example:
    I need to create a non-UNIQUE INDEX on the columns, an approximate size would do.

    < PRE >
    NOT NULL DATE EVENT_DATE
    APPT_DATE_SLOT VARCHAR2 (15)
    EVENT_STATUS VARCHAR2 (4)
    < / PRE >

    The table has some 7 300 000 rows. I would like to know how to calculate too.

    All AIDS are very much appreciated.

    A rough estimate of the index space will need is possible by

    adding the actual length expected from each column, plus 6 for the rowid, 2 for the number of the X-header of the rows in the table that will be so an entry

    Date are 7 bytes internal + 15 + 4 + 2 + 6 = 34 X 7.3 M = 248200000 X General fresh for the block header, initrans, etc...

    We will use 20% overhead block or 1.2 X 248200000 = 297840000, which is about 285 M

    The actual distribution will vary according to your method of range tablespace.

    HTH - Mark D Powell.

  • CVI 2013 SP1 - function calls repeated with pointer on a variable array parameter causes a shift of the index

    I have some functions will be pointers as parameter and CVI 2012 SP1, they work as before without problems but with CVI 2013 SP1 they are now incorrect.

    Here the description of what is happening - I found a cure, but a duty adopt the old code and I think it's clear that nobody don't "captures" all lines in a 'big old code' which are affected (maybe):

    I have functions

    'function_XYZ(int *p_paraArr) '.

    with 'p_paraArr' as pointers on a table (int).

    Suppose I have another function

    "fct_TOP (void)".

    where is a local array variable which is inizialized by

    "int TheArray [25] = {0};

    and inside of this "TOP"-function-body I call a function ".

    "function_XYZ (TheArray).

    There are no complains of the compiler (CVI 2012 or 2013) and the code works (but the CVI 2013 only once!).

    But if I put 'fct_TOP' loop I have a lag in the "TheArray' -memory.  (The loop surrounds the function "TOP"! "")

    This means that the result "TheArray" obtained from "function_XYZ (TheArray)" starts at index '1' not on the index '0' - as the first time that the function "function_XYZ (TheArray)" was performed. ".

    The solution is:

    I only replaced

    "function_XYZ (TheArray)" (<1>)

    by

    "function_XYZ (&(TheArray[0]))" (<2>)

    overall the program now works every time (in the whole loop)-the first time (in the loop).

    In the second version (<2>) everything is necessary to "work well":

    The '&' and parentheses "(...)", which contains the element that may be designated by the '& '.

    And I hope that you believe me: I've tested several times, it was only "little" change that solved the problem.

    So it seems that the ICB 2013 (SP1) is a kind of internal offset index by a repeated execution of the

    "function_XYZ (TheArray).

    but I don't know how or why but I see in debug mode by observing the expected against the values in the table received!

    At the first time the (implicit) internal index of 'TheArray' is '0', but the following times (during the execution of the loop) the internal index passes to '1' (seen in the debugger because that all the expected values were shiftet like that!).

    So there's an explicit index in the table ("function_XYZ (&(TheArray[0]))") necessary to make the first time of this clear code execution.

    There are some good improvements in 2013 CVI (SP1) and I like this environment more than the 2012 version - but:

    There are other "changes" also, in the compiler (or linker...?) that are more rigid than "in ancient times.

    The problem of this kind of error is always the 'old code '!

    It is expected of such behavior.

    The compiler/linker do not complain (a complaint would be good!) writing but he made this mistake (in a loop).

    By the way: my 'compilation Options' are set to 'Extended' (without change in the "..." ("- button - Options) and that all of the boxes, except the" OpenMP_support "-box are checked!"» So I think that I put the very rigid compiler - maybe there are some «...» ' - button - settings to get rid of this problem, but I have not found them/it.

    My request:

    -Check the stiffer compiler by the need of an explicit index

    - or switch to the 'old' behavior with "function_XYZ (TheArray)" always refers to implicit index '0' of the element "TheArray". "."

    Thank you for your messages, comments and suggestions.

    -As I wrote before - maybe it's the style of programming or error"self made"... maybe...
    .. But if I replace 'function_XYZ (TheArray)' by "function_XYZ (&(TheArray[0]))" and
    then it works... Why so and not, if bothe the same? ...

    But as long as I do not post sample code, nobody is going to accept - I accept it. So consider this post more as an allusion to the fact that of the LW/CVI 2012-2013 LW/CVI more changed than just the LW - GUI or certain features: the compiler changed its 'way to'... or almost.

    For this problem, I think that I will use the solution 'use no implicit and explicit pointers'.
    Who should be a good idea taking into account
        http://forums.NI.com/T5/LabWindows-CVI/fatal-run-time-error-dereference-of-out-of-bounds-pointer/TD-...

    mybe also only caused by wrong code... who knows... but for me it is a sufficient reason to act as I suggest above.

    Best regards,
    F.

  • The index is not used

    DB worm 11.2.03

    We have rebuillt a large table (229,952,143 lines) from a backup in our dev, test environments and living, then the table is about the same in all three. Same structure, indexes and data compression.

    However on the issue of the same query in all three envs, in that the index is ignored direct when used in dev and test.

    We have compared the structure of the table and the content using Toad and can see no difference.

    What do we lack?


    Have you checked the statistics on tables and indexes?

  • Partitioned global index on partitioned table range, but the index partition does not work

    Hello:

    I was creating an index partitioned on table partitioned and partitioned index does not work.

    create table table_range)

    CUST_FIRST_NAME VARCHAR2 (20).

    CUST_GENDER CHAR (1),

    CUST_CITY VARCHAR2 (30),

    COUNTRY_ISO_CODE CHAR (2),

    COUNTRY_NAME VARCHAR2 (40),

    COUNTRY_SUBREGION VARCHAR2 (30),

    PROD_ID NUMBER NOT NULL,

    CUST_ID NUMBER NOT NULL,

    TIME_ID DATE NOT NULL,

    CHANNEL_ID NUMBER NOT NULL,

    PROMO_ID NUMBER OF NON-NULL,

    QUANTITY_SOLD NUMBER (10.2) NOT NULL,

    AMOUNT_SOLD NUMBER (10.2) NOT NULL

    )

    partition by (range (time_id)

    lower partition p1 values (u01 tablespace to_date('2001/01/01','YYYY/MM/DD')),

    lower partition (to_date('2002/01/01','YYYY/MM/DD')) tablespace u02 p2 values

    );

    create index ind_table_range on table2 (prod_id)

    () global partition range (prod_id)

    values less than (100) partition p1,

    lower partition p2 values (maxvalue)

    );

    SQL > select TABLE_NAME, SUBPARTITION_COUNT, HIGH_VALUE, nom_partition NUM_ROWS of user_tab_partitions;

    TABLE_NAME NOM_PARTITION SUBPARTITION_COUNT HIGH_VALUE NUM_ROWS

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

    TABLE_RANGE P2 0 TO_DATE (' 2002-01-01 00:00:00 ',' SYYYY-MM-DD HH24:MI:SS ',' NLS_CALENDAR = GREGORIA 259418)

    TABLE_RANGE P1 0 TO_DATE (' 2001-01-01 00:00:00 ',' SYYYY-MM-DD HH24:MI:SS ',' NLS_CALENDAR = GREGORIA 659425)

    SQL > select INDEX_NAME, NUM_ROWS nom_partition, HIGH_VALUE user_ind_partitions;

    INDEX_NAME NOM_PARTITION HIGH_VALUE NUM_ROWS

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

    P1 IND_TABLE_RANGE 100 479520

    IND_TABLE_RANGE P2 MAXVALUE 439323

    SQL > EXECUTE DBMS_STATS. GATHER_TABLE_STATS (USER, 'TABLE_RANGE');

    SQL > EXECUTE DBMS_STATS. GATHER_TABLE_STATS (USER, 'TABLE_RANGE', GRANULARITY = > 'PARTITION');

    SQL > EXECUTE DBMS_STATS. GATHER_INDEX_STATS (USER, 'IND_TABLE_RANGE');

    SQL > EXECUTE DBMS_STATS. GATHER_INDEX_STATS (USER, 'IND_TABLE_RANGE', GRANULARITY = > 'PARTITION');

    SQL > set autotrace traceonly

    SQL > alter shared_pool RAS system;

    SQL > changes the system built-in buffer_cache;

    SQL > select * from table_range

    where prod_id = 127;

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

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

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

    |   0 | SELECT STATEMENT |             | 16469 |  1334K |  3579 (1) | 00:00:43 |       |       |

    |   1.  RANGE OF PARTITION ALL THE |             | 16469 |  1334K |  3579 (1) | 00:00:43 |     1.     2.

    |*  2 |   TABLE ACCESS FULL | TABLE_RANGE | 16469 |  1334K |  3579 (1) | 00:00:43 |     1.     2.

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

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

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

    2 - filter ("PROD_ID" = 127)

    Statistics

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

    320 recursive calls

    2 db block Gets

    13352 consistent gets

    11820 physical reads

    0 redo size

    855198 bytes sent via SQL * Net to client

    12135 bytes received via SQL * Net from client

    1067 SQL * Net back and forth to and from the client

    61 sorts (memory)

    0 sorts (disk)

    15984 rows processed

    Once the sentence you say ' does not ' and then you go to paste plans that seem to show that it "works".

    What gives?

    In fact, if you look at the plans - think Oracle you have 16 k rows in the table and he'll be back k 12 rows for your select statement. In this case, Oracle is picking up the right plan - full scan 16 ranks of k is a lot less work to digitize the index lines k 12 followed by the research of rank k 12 rowid.

  • Query took too much time when adding new column to the table and the index set on this

    I added a new column to the table that contains thousands of records. and created the composite index with three columns (those newly added + two existing column)

    for the specifics. TBL table there are two columns col1, col2

    I added the new column col3 to TBL and created composit index (col1, col2, col3).

    Now for all the records in col3 is NULL. When I choose on this table, it takes too long...

    Any idea what my I do bad., I have check the query plan, it is using the index

    It is solved using collection of statistics using the

    DBMS_STATS. GATHER_TABLE_STATS

    @Top.Gun thanks for your review...

  • The index used only when given Index indicator

    Hello

    Version of RDBMS - 11.2.0.3.0

    I have a situation where only when I use the Index indicator, index does is used.

    Use case: -.

    1. SELECT query on a table with about 100 KB of data.

    2. have the index on the column that is used in the WHERE clause of the SELECT query.

    CREATE TABLE him_entity (id NUMBER, him_val CHAR(1));
    
    
    INSERT INTO him_entity
    SELECT rownum,'1' FROM dual CONNECT BY level<=1000000;
    
    
    CREATE INDEX idx_him_val ON him_entity(him_val);
    
    
    
    
    
    

    Without using Index indicator, Explain plan: -.

    SELECT ID 
    FROM him_entity
    WHERE him_val='1';
    
    
    -----------------------------------------------------------------------------------
    | Id  | Operation         | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
    -----------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT  |               |  1000K|  4882K|   498   (5)| 00:00:06 |
    |*  1 |  TABLE ACCESS FULL| HIM_ENTITY    |  1000K|  4882K|   498   (5)| 00:00:06 |
    -----------------------------------------------------------------------------------
    
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
    
       1 - filter("HIM_VAL"='1')
    

    With the help of Index indicator, explain the plan: -.

    SELECT /*+ index(him_entity idx_him_val)*/ ID 
    FROM him_entity
    WHERE him_val='1';
    
    
    ---------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |               |  1000K|  4882K|  3485   (1)| 00:00:42 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| HIM_ENTITY    |  1000K|  4882K|  3485   (1)| 00:00:42 |
    |*  2 |   INDEX RANGE SCAN          | IDX_HIM_VAL   |  1000K|       |  1824   (1)| 00:00:22 |
    ---------------------------------------------------------------------------------------------
    
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
    
       2 - access("HIM_VAL"='1')
    

    (1) could you explain why Index was not be picked up without indicator Index for help?

    (2) I gathered statistics for the table before running the query.

    (3) is it fine / safe to use the FIRST_ROWS hint instead of Index indicator?

    Thank you...

    1. SELECT THE ID
    2. OF him_entity
    3. WHERE him_val = '1';

    You select all the rows in the table.

    As your query will extract all lines then the optimal trajectory IS FULL TABLE SCAN instead of using INDEXES

    If we let you use less than 5% of table rows, and then using index can be an optimal trajectory to go for the record.

    1. SELECT / * + index (him_entity idx_him_val) * / ID
    2. OF him_entity
    3. WHERE him_val = '1';

    Your strength of indicator Index to fetch the file by using the index of the query

  • update the indexed column

    I got a name emp table that holds at least 30000 lines and I had created an index on emp_city

    What happens if I update a value of emp_city? What effect will create it on the index or table?

    the index will be updated automatically?

    the index become invalid?

    the line in the journal in the index will be deleted and inserted?

    or updated in the journal will take place?

    According to the name of the field, I understand that the distribution is pretty sparse for normal index on emp_city.

    Will be better to create a bitmap index where you apply to this table with OLAP queries or not create an index on this field.

    I don't care

    If you have an index on emp_city or emp_city is a part of some regular index and you will upadate all value emp_city:

    the index will be automatically updated. (Yes)

    the index become invalid?  (No, but I suggest that you run statistics on index or table wole)

    the line in the journal in the index will be deleted and inserted? or updated in the journal will take place?

    It's block of sheets (not rank of petals). Entire block will be replaced.

    Best,

    Ark

  • doubt about the Index Skip Scan

    Hi all

    I read the setting of Oracle performance guide (Version 11.2 Chapter 11). I just want to see index skip scan with an example. I created a table called t and inserted the test data. When I asked the table optimizer did not use the index skip scan path.

    Can you please let me know what mistake I am doing here.

    Thanks a lot for your help in advance.

    SQL > create table t (empno number
    2, ename varchar2 (2000)
    3, varchar2 (1) sex
    4, email_id varchar2 (2000));

    Table created

    SQL >
    SQL >-test data
    SQL > insert into t
    2 level, select "suri" | (level), ','suri.king' | level | ' @gmail.com'
    3 double
    4. connect by level < = 20000
    5.

    20000 lines inserted

    SQL >
    SQL > insert into t
    2 Select level + 20000, 'surya ' | (level + 20000), 'F', 'surya.princess'. (level + 20000) : ' @gmail.com '
    3 double
    4. connect by level < = 20000
    5.

    20000 lines inserted

    SQL > create index t_gender_email_idx on t (gender, email_id);

    Index created

    SQL > explain the plan for
    2 Select
    3 t
    4 where email_id = "[email protected]";

    He explained.

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

    PLAN_TABLE_OUTPUT
    ----------------------------------------------------------------------------------------------------------------
    Hash value of plan: 1601196873

    --------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
    --------------------------------------------------------------------------


    |   0 | SELECT STATEMENT |      |     4.  8076 |   103 (1) | 00:00:02 |
    |*  1 |  TABLE ACCESS FULL | T    |     4.  8076 |   103 (1) | 00:00:02 |
    --------------------------------------------------------------------------

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

    1 - Filter ("EMAIL_ID"= "[email protected]")

    Note
    -----
    -dynamic sample used for this survey (level = 2)

    17 selected lines.

    See you soon,.

    Suri

    You have just demonstrated how your execution plan gets screwed up if you do not have your statistics

    SQL > create table t
    () 2
    3 empno number
    4, ename varchar2 (2000)
    5, varchar2 (1) sex
    6, email_id varchar2 (2000)
    7  );

    Table created.

    SQL > insert into t
    2 Select level, "suri" | (level), ', 'suri.king'| level | ' @gmail.com'
    3 double
    4. connect by level<=>
    5.

    20000 rows created.

    SQL > insert into t
    2 Select level + 20000, 'surya ' | (level + 20000), 'F', 'surya.princess'. (level + 20000) : ' @gmail.com'
    3 double
    4. connect by level<=>
    5.

    20000 rows created.

    SQL > create index t_gender_email_idx on t (gender, email_id);

    The index is created.

    SQL > set autotrace traceonly explain
    SQL >
    SQL > select *.
    2 t
    3 where email_id = "[email protected]";

    Execution plan
    ----------------------------------------------------------
    Hash value of plan: 2153619298

    --------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
    --------------------------------------------------------------------------
    |   0 | SELECT STATEMENT |      |     3.  6057.    79 (4) | 00:00:01 |
    |*  1 |  TABLE ACCESS FULL | T    |     3.  6057.    79 (4) | 00:00:01 |
    --------------------------------------------------------------------------

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

    1 - Filter ("EMAIL_ID"= "[email protected]")

    Note
    -----
    -dynamic sampling used for this statement

    SQL > exec dbms_stats.gather_table_stats (user, 't', cascade-online true)

    PL/SQL procedure successfully completed.

    SQL > select *.
    2 t
    3 where email_id = "[email protected]";

    Execution plan
    ----------------------------------------------------------
    Hash value of plan: 2655860347

    --------------------------------------------------------------------------------------------------
    | ID | Operation | Name               | Lines | Bytes | Cost (% CPU). Time |
    --------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT |                    |     1.    44.     1 (0) | 00:00:01 |
    |   1.  TABLE ACCESS BY INDEX ROWID | T                  |     1.    44.     1 (0) | 00:00:01 |
    |*  2 |   INDEX SKIP SCAN | T_GENDER_EMAIL_IDX |     1.       |     1 (0) | 00:00:01 |
    --------------------------------------------------------------------------------------------------

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

    2 - access ("EMAIL_ID"= '[email protected]')
    filter ("EMAIL_ID"= "[email protected]")

    SQL >

  • Rebuild the Index

    Hello
    the following query takes more than 3 hours.

    the wait event is a clue: PSCRECV_HDR. Should rebuild us this index? Or problem is something else?
    How can I check the health of the index?
    show parameter optimizer
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------
    optimizer_capture_sql_plan_baselines boolean     FALSE
    optimizer_dynamic_sampling           integer     2
    optimizer_features_enable            string      11.2.0.3
    optimizer_index_caching              integer     0
    optimizer_index_cost_adj             integer     100
    optimizer_mode                       string      ALL_ROWS
    optimizer_secure_view_merging        boolean     TRUE
    optimizer_use_invisible_indexes      boolean     FALSE
    optimizer_use_pending_statistics     boolean     FALSE
    optimizer_use_sql_plan_baselines     boolean     TRUE
    
    Explain plan for
    SELECT A.BUSINESS_UNIT, D.DESCR FROM PS_SP_RECV1_NONVW A, PS_SP_RCV1_NONVWLN D WHERE D.BUSINESS_UNIT LIKE 'I%' AND D.BUSINESS_UNIT=A.BUSINESS_UNIT AND D.LANGUAGE_CD='FRA' UNION SELECT  BUSINESS_UNIT, DESCR FROM PS_SP_RECV1_NONVW A WHERE BUSINESS_UNIT LIKE 'IF%' AND NOT EXISTS (SELECT 'X' FROM PS_SP_RCV1_NONVWLN D WHERE  D.BUSINESS_UNIT=A.BUSINESS_UNIT AND 
    
    explain plan succeeded.
    159 ms 
    PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                                            
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
                                                                                                                                                                                                                                                                                                                 
    -----------------------------------------------------------------------------------------------------                                                                                                                                                                                                        
    | Id  | Operation                         | Name               | Rows  | Bytes |TempSpc| Cost (%CPU)|                                                                                                                                                                                                        
    -----------------------------------------------------------------------------------------------------                                                                                                                                                                                                        
    |   0 | SELECT STATEMENT                  |                    |  9960M|   538G|       |   313M  (1)|                                                                                                                                                                                                        
    |   1 |  SORT ORDER BY                    |                    |  9960M|   538G|   410G|   313M  (1)|                                                                                                                                                                                                        
    |   2 |   SORT UNIQUE                     |                    |  9960M|   538G|   633G|   188M  (1)|                                                                                                                                                                                                        
    |   3 |    UNION-ALL                      |                    |       |       |       |            |                                                                                                                                                                                                        
    |*  4 |     HASH JOIN                     |                    |  9960M|   538G|  3944K| 31301  (98)|                                                                                                                                                                                                        
    |*  5 |      INDEX FAST FULL SCAN         | PSCRECV_HDR        |   201K|  1577K|       |   187   (2)|                                                                                                                                                                                                        
    |*  6 |      HASH JOIN                    |                    | 98659 |  4817K|       |   191   (2)|                                                                                                                                                                                                        
    |   7 |       NESTED LOOPS                |                    |       |       |       |            |                                                                                                                                                                                                        
    |   8 |        NESTED LOOPS               |                    |     1 |    42 |       |     3   (0)|                                                                                                                                                                                                        
    |   9 |         MERGE JOIN CARTESIAN      |                    |     1 |    12 |       |     2   (0)|                                                                                                                                                                                                        
    |* 10 |          INDEX RANGE SCAN         | PS_BUS_UNIT_TBL_FS |     1 |     6 |       |     1   (0)|                                                                                                                                                                                                        
    |  11 |          BUFFER SORT              |                    |     1 |     6 |       |     1   (0)|                                                                                                                                                                                                        
    |* 12 |           INDEX RANGE SCAN        | PS_BUS_UNIT_TBL_FS |     1 |     6 |       |     1   (0)|                                                                                                                                                                                                        
    |* 13 |         INDEX UNIQUE SCAN         | PS_BUS_UNIT_LANG   |     1 |       |       |     0   (0)|                                                                                                                                                                                                        
    |  14 |        TABLE ACCESS BY INDEX ROWID| PS_BUS_UNIT_LANG   |     1 |    30 |       |     1   (0)|                                                                                                                                                                                                        
    |* 15 |       INDEX FAST FULL SCAN        | PSCRECV_HDR        |   201K|  1577K|       |   187   (2)|                                                                                                                                                                                                        
    |* 16 |     FILTER                        |                    |       |       |       |            |                                                                                                                                                                                                        
    |* 17 |      HASH JOIN                    |                    |   100K|  3450K|       |   190   (2)|                                                                                                                                                                                                        
    |  18 |       TABLE ACCESS BY INDEX ROWID | PS_BUS_UNIT_TBL_FS |     1 |    27 |       |     2   (0)|                                                                                                                                                                                                        
    |* 19 |        INDEX RANGE SCAN           | PS_BUS_UNIT_TBL_FS |     1 |       |       |     1   (0)|                                                                                                                                                                                                        
    |* 20 |       INDEX FAST FULL SCAN        | PSCRECV_HDR        |   201K|  1577K|       |   187   (2)|                                                                                                                                                                                                        
    |  21 |      NESTED LOOPS                 |                    |  9178 |   215K|       |   681   (1)|                                                                                                                                                                                                        
    |  22 |       NESTED LOOPS                |                    |     1 |    16 |       |     0   (0)|                                                                                                                                                                                                        
    |* 23 |        INDEX UNIQUE SCAN          | PS_BUS_UNIT_LANG   |     1 |    10 |       |     0   (0)|                                                                                                                                                                                                        
    |* 24 |        INDEX UNIQUE SCAN          | PS_BUS_UNIT_TBL_FS |     1 |     6 |       |     0   (0)|                                                                                                                                                                                                        
    |* 25 |       INDEX RANGE SCAN            | PSCRECV_HDR        |  9178 | 73424 |       |   681   (1)|                                                                                                                                                                                                        
    -----------------------------------------------------------------------------------------------------                                                                                                                                                                                                        
                                                                                                                                                                                                                                                                                                                 
    Predicate Information (identified by operation id):                                                                                                                                                                                                                                                          
    ---------------------------------------------------                                                                                                                                                                                                                                                          
                                                                                                                                                                                                                                                                                                                 
       4 - access("A"."BUSINESS_UNIT"="A"."BUSINESS_UNIT" AND                                                                                                                                                                                                                                                    
                  "A"."BUSINESS_UNIT"="B"."BUSINESS_UNIT")                                                                                                                                                                                                                                                       
       5 - filter("A"."RECV_STATUS"<>'C' AND "A"."BUSINESS_UNIT" LIKE 'I%')                                                                                                                                                                                                                                      
       6 - access("A"."BUSINESS_UNIT"="B"."BUSINESS_UNIT")                                                                                                                                                                                                                                                       
      10 - access("B"."BUSINESS_UNIT" LIKE 'I%')                                                                                                                                                                                                                                                                 
           filter("B"."BUSINESS_UNIT" LIKE 'I%')                                                                                                                                                                                                                                                                 
      12 - access("B"."BUSINESS_UNIT" LIKE 'I%')                                                                                                                                                                                                                                                                 
           filter("B"."BUSINESS_UNIT" LIKE 'I%')                                                                                                                                                                                                                                                                 
      13 - access("B"."BUSINESS_UNIT"="C"."BUSINESS_UNIT" AND "C"."LANGUAGE_CD"='FRA')                                                                                                                                                                                                                           
           filter("C"."BUSINESS_UNIT" LIKE 'I%')                                                                                                                                                                                                                                                                 
      15 - filter("A"."RECV_STATUS"<>'C' AND "A"."BUSINESS_UNIT" LIKE 'I%')                                                                                                                                                                                                                                      
      16 - filter( NOT EXISTS (SELECT 0 FROM SYSADM."PS_BUS_UNIT_LANG"                                                                                                                                                                                                                                           
                  "C",SYSADM."PS_BUS_UNIT_TBL_FS" "B",SYSADM."PS_RECV_HDR" "A" WHERE                                                                                                                                                                                                                             
                  "A"."BUSINESS_UNIT"="B"."BUSINESS_UNIT" AND "A"."RECV_STATUS"<>'C' AND                                                                                                                                                                                                                         
                  "A"."BUSINESS_UNIT"=:B1 AND "B"."BUSINESS_UNIT"=:B2 AND                                                                                                                                                                                                                                        
                  "B"."BUSINESS_UNIT"="C"."BUSINESS_UNIT" AND "C"."LANGUAGE_CD"='FRA' AND                                                                                                                                                                                                                        
                  "C"."BUSINESS_UNIT"=:B3))                                                                                                                                                                                                                                                                      
      17 - access("A"."BUSINESS_UNIT"="B"."BUSINESS_UNIT")                                                                                                                                                                                                                                                       
      19 - access("B"."BUSINESS_UNIT" LIKE 'IF%')                                                                                                                                                                                                                                                                
           filter("B"."BUSINESS_UNIT" LIKE 'IF%')                                                                                                                                                                                                                                                                
      20 - filter("A"."RECV_STATUS"<>'C' AND "A"."BUSINESS_UNIT" LIKE 'IF%')                                                                                                                                                                                                                                     
      23 - access("C"."BUSINESS_UNIT"=:B1 AND "C"."LANGUAGE_CD"='FRA')                                                                                                                                                                                                                                           
      24 - access("B"."BUSINESS_UNIT"=:B1)                                                                                                                                                                                                                                                                       
           filter("B"."BUSINESS_UNIT"="C"."BUSINESS_UNIT")                                                                                                                                                                                                                                                       
      25 - access("A"."BUSINESS_UNIT"="B"."BUSINESS_UNIT")                                                                                                                                                                                                                                                       
           filter("A"."RECV_STATUS"<>'C' AND "A"."BUSINESS_UNIT"=:B1)                                                                                                                                                                                                                                            
                                                                                                                                                                                                                                                                                                                 
    Note                                                                                                                                                                                                                                                                                                         
    -----                                                                                                                                                                                                                                                                                                        
       - 'PLAN_TABLE' is old version                                                                                                                                                                                                                                                                             
    
    65 rows selected
    
    1 273 ms écoulées
    
    ==============================================================================================
    SQL> select sid, osuser,row_wait_obj#,program,event from v$session where program like '%Dev%' and osuser='myuser';
    
           SID OSUSER          ROW_WAIT_OBJ# PROGRAM         EVENT
    ---------- --------------- ------------- --------------- ---------------
            29 myuser                51715 SQL Developer   SQL*Net message
                                                              from client
    
    SQL> select  object_type, object_name, data_object_id
      2  from dba_objects
      3  where object_id = 51715;
    
    OBJECT_TYPE         OBJECT_NAME     DATA_OBJECT_ID
    ------------------- --------------- --------------
    INDEX               PSCRECV_HDR              51715
    Thank you.

    Are accurate statistics, the query returns about 10 billion lines, and if so how long you expect to take?
    Can send you a SQL trace with details of actual file?

  • The index used is not in the group by.

    Here's the scenario with examples. The big table 333 to 500 million in the table rows. Statistics are collected. Are there histograms. Index is not however be used. Why?
      CREATE TABLE "XXFOCUS"."some_huge_data_table" 
       (  "ORG_ID" NUMBER NOT NULL ENABLE, 
      "PARTNERID" VARCHAR2(30) NOT NULL ENABLE, 
      "EDI_END_DATE" DATE NOT NULL ENABLE, 
      "CUSTOMER_ITEM_NUMBER" VARCHAR2(50) NOT NULL ENABLE, 
      "STORE_NUMBER" VARCHAR2(10) NOT NULL ENABLE, 
      "EDI_START_DATE" DATE, 
      "QTY_SOLD_UNIT" NUMBER(7,0), 
      "QTY_ON_ORDER_UNIT" NUMBER(7,0), 
      "QTY_ON_ORDER_AMT" NUMBER(10,2), 
      "QTY_ON_HAND_AMT" NUMBER(10,2), 
      "QTY_ON_HAND_UNIT" NUMBER(7,0), 
      "QTY_SOLD_AMT" NUMBER(10,2), 
      "QTY_RECEIVED_UNIT" NUMBER(7,0), 
      "QTY_RECEIVED_AMT" NUMBER(10,2), 
      "QTY_REQUISITION_RDC_UNIT" NUMBER(7,0), 
         "QTY_REQUISITION_RDC_AMT" NUMBER(10,2), 
         "QTY_REQUISITION_RCVD_UNIT" NUMBER(7,0), 
         "QTY_REQUISITION_RCVD_AMT" NUMBER(10,2), 
         "INSERTED_DATE" DATE, 
         "UPDATED_DATE" DATE, 
         "CUSTOMER_WEEK" NUMBER, 
         "CUSTOMER_MONTH" NUMBER, 
         "CUSTOMER_QUARTER" NUMBER, 
         "CUSTOMER_YEAR" NUMBER, 
         "CUSTOMER_ID" NUMBER, 
         "MONTH_NAME" VARCHAR2(3), 
         "ORG_WEEK" NUMBER, 
         "ORG_MONTH" NUMBER, 
         "ORG_QUARTER" NUMBER, 
         "ORG_YEAR" NUMBER, 
         "SITE_ID" NUMBER, 
         "ITEM_ID" NUMBER, 
         "ITEM_COST" NUMBER, 
         "UNIT_PRICE" NUMBER, 
          CONSTRAINT "some_huge_data_table_PK" PRIMARY KEY ("ORG_ID", "PARTNERID", "EDI_END_DATE", "CUSTOMER_ITEM_NUMBER", "STORE_NUMBER")
      USING INDEX TABLESPACE "xxxxx"  ENABLE, 
          CONSTRAINT "some_huge_data_table_CK_START_DATE" CHECK (edi_end_date - edi_start_date = 6) ENABLE
       );
    
    SQL*Plus: Release 11.2.0.2.0 Production on Fri Sep 14 12:11:16 2012
    
    Copyright (c) 1982, 2010, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    
    SQL> SELECT num_rows FROM user_tables s WHERE s.table_name = 'some_huge_data_table';
    
      NUM_ROWS                                                                      
    ----------                                                                      
     333338434                                                                      
    
    SQL> SELECT MAX(edi_end_date)
      2    FROM some_huge_data_table p
      3   WHERE p.org_id = some_number
      4     AND p.partnerid = 'some_string';
    
    MAX(EDI_E                                                                       
    ---------                                                                       
    13-MAY-12                                                                       
    
    Elapsed: 00:00:00.00
    
    
    SQL> explain plan for
      2  SELECT MAX(edi_end_date)
      3    FROM some_huge_data_table p
      4   WHERE p.org_id = some_number
      5     AND p.partnerid = 'some_string';
    
    Explained.
    
    SQL> /
    
    PLAN_TABLE_OUTPUT                                                                                   
    ----------------------------------------------------------------------------------------------------
    Plan hash value: 2104157595                                                                         
                                                                                                        
    --------------------------------------------------------------------------------------------        
    | Id  | Operation                    | Name        | Rows  | Bytes | Cost (%CPU)| Time     |        
    --------------------------------------------------------------------------------------------        
    |   0 | SELECT STATEMENT             |             |     1 |    22 |     4   (0)| 00:00:01 |        
    |   1 |  SORT AGGREGATE              |             |     1 |    22 |            |          |        
    |   2 |   FIRST ROW                  |             |     1 |    22 |     4   (0)| 00:00:01 |        
    |*  3 |    INDEX RANGE SCAN (MIN/MAX)| some_huge_data_table_PK |     1 |    22 |     4   (0)| 00:00:01 |        
    --------------------------------------------------------------------------------------------        
    
    SQL> explain plan for
      2  SELECT MAX(edi_end_date),
      3         org_id,
      4         partnerid
      5    FROM some_huge_data_table
      6   GROUP BY org_id,
      7            partnerid;
    
    Explained.
    
    PLAN_TABLE_OUTPUT                                                                                   
    ----------------------------------------------------------------------------------------------------
    Plan hash value: 3950336305                                                                         
                                                                                                        
    -------------------------------------------------------------------------------                     
    | Id  | Operation          | Name     | Rows  | Bytes | Cost (%CPU)| Time     |                     
    -------------------------------------------------------------------------------                     
    |   0 | SELECT STATEMENT   |          |     2 |    44 |  1605K  (1)| 05:21:03 |                     
    |   1 |  HASH GROUP BY     |          |     2 |    44 |  1605K  (1)| 05:21:03 |                     
    |   2 |   TABLE ACCESS FULL| some_huge_data_table |   333M|  6993M|  1592K  (1)| 05:18:33 |                     
    -------------------------------------------------------------------------------                     
    Why is he would not use the index in the group by? If I write a loop to search for different partnerid (there are only three), things together takes less than a second. Any help is appreciated.

    BTW, I too gave the index indicator. Did not work. Version mentioned in the example.

    Published by: RPuttagunta on September 14, 2012 11:24

    Published by: RPuttagunta on September 14, 2012 11:26

    the actual names are 'cleaned' for obvious reasons. Don't worry, I don't have the name of the tables in different cases.

    RPuttagunta wrote:

    Looks like either I called index_ss asked Jonathan a bad indicator, or, I don't know if he used the 'skip scan ".

    You don't specify correctly, it should be: index_ss (table_alias) or index_ss (table_alias index_name) or index_ss (table_alias (list of columns to index)).

    But I just tried a quick test on 11.2.0.3, and he does not have what we would really like to do.

    Concerning
    Jonathan Lewis

  • SELECT on a table in the INSERT statement uses the INDEX

    Hello world

    I have a strange problem with EA Oracle 10 g (64-bit) running on a Linux system. The situation is, I developed a Java program to migrate one client system to another. One of the steps in the migration fills a new table with the data from the old system. Given that the data on the old system structure is fundamentally different from that new, I have to check each time I read a line from the old system, if I have already created an entity on the new table, and if so, update certain attributes. The WHERE clause of this audit uses a key of the company indexed on the new table. The problem is now, that Oracle does not use the index on the key attribute of the company, but it makes table scans complete to select the line. As you can imagine, the lines first thousand or so go fast, but the amount increases, the program becomes slower and slower.

    If I do a "scan" when executing the migration program, Oracle change the execution plan and use the index on the attribute key and everything works fast and smooth. However, if I do the analysis on the empty table first, nothing changes (which I understand it perfectly, since there is nothing to analyze, at this point). By integrating a hint of 'INDEX' (table) in the statement SELECT does not change the full implementation plan (also table scans).

    Is it possible to change this behavior, in order to SELECT it uses the index of key business from the beginning?

    Greetings from Cologne,

    Thorsten.

    Published by: thkitz on 13.03.2012 18:27

    thkitz wrote:

    SELECT STATEMENT  ALL_ROWSCost: 2  Bytes: 76  Cardinality: 2
         7 TABLE ACCESS BY INDEX ROWID TABLE AIDATINT.PRVVSSCHADENKORRESPONDENZ Cost: 2  Bytes: 76  Cardinality: 2
              6 BITMAP CONVERSION TO ROWIDS
                   5 BITMAP OR
                        2 BITMAP CONVERSION FROM ROWIDS
                             1 INDEX RANGE SCAN INDEX AIDATINT.I_PRVVSSCHADENKORRESPONDENZ_1 Cost: 1
                        4 BITMAP CONVERSION FROM ROWIDS
                             3 INDEX RANGE SCAN INDEX AIDATINT.I_PRVVSSCHADENKORRESPONDENZ_2 Cost: 1  
    

    I would have thought that as a plan as possible. It is not a concatenation, is a btree/bitmap conversion.
    Allude to this plan you need / * + index_combine (table_alias index1 index2) * /.
    For 10g and later the index can be specified by name or by description

    I'm a bit puzzled why the plan changes after truncate - but maybe my comment about not cleared statistics is no longer true. It is easy enough to check if I'm right or wrong on your version of Oracle.

    Concerning
    Jonathan Lewis
    http://jonathanlewis.WordPress.com
    Author: core Oracle

  • Display performance of resources by using the index of area XDBHI_IDX

    Hi all

    We have an application XMLDB home grown to make the validation of diagram against incoming messages. Enforcement issues several queries like below. I know, it analyzes the hard, which is very bad, but it's not where the real problem is at the moment. The problem is with the index of XDBHI_IDX field against xdb resource table $. We use a very specific way of results in the rows returned 0 or 1, but as you can see that the domain index has an intermediate result of 48041 lines, so the index is not effective here. Statistics are up to date, the index has been rebuild. Does anyone know what we can do with the index of the field to do what he must do: identify an xml document in this way?
    SELECT 0 
    FROM
     resource_view WHERE any_path=
      '/home/app/incoming/ARCH_IN/2012/01/592174'
    
    
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        2      0.02       0.02          0       1041          0           0
    Execute      2      0.00       0.00          0          0          0           0
    Fetch        2     81.26      85.43          0     202556     576158           0
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        6     81.28      85.45          0     203597     576158           0
    
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 67  (app)   (recursive depth: 3)
    
    Rows     Row Source Operation
    -------  ---------------------------------------------------
          0  TABLE ACCESS BY INDEX ROWID XDB$RESOURCE (cr=341531 pr=0 pw=0 time=60883725 us)
      48041   DOMAIN INDEX  XDBHI_IDX (cr=311030 pr=0 pw=0 time=1548774 us)
    Kind regards
    Rob.

    PS: The database version is 10.2.0.3.0

    Hi Rob,

    See EQUALS_PATH (and UNDER_PATH) conditions: http://docs.oracle.com/cd/B19306_01/server.102/b14200/conditions010.htm#i1051094

    SQL> select *
      2  from resource_view v
      3  where equals_path(v.res, '/office/excel/docs') = 1
      4  ;
    
    Execution Plan
    ----------------------------------------------------------
    Plan hash value: 3007404872
    
    --------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |              |    81 | 17172 |    32   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| XDB$RESOURCE |    81 | 17172 |    32   (0)| 00:00:01 |
    |*  2 |   DOMAIN INDEX              | XDBHI_IDX    |       |       |            |          |
    --------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("XDB"."EQUALS_PATH"(SYS_MAKEXML('8758D485E6004793E034080020B242C6',734
                  ,"XMLEXTRA","XMLDATA"),'/office/excel/docs',8888)=1)
    

Maybe you are looking for