Assigning variables using the index in a cfloop

I would like to make this code give each stp or alt the index
of it so with the #Stp#i## it would end up being #Stp@i# or
Stp1.

Not quite what I was thinking, I haven't tried to see if that
will work but it looks like it will set 7 different sets variables
and I just need to reset those variables 7 times. The variables
refer to other variables up above; I will post more of the code
below. I have changed some of the code from my last post so it
isn't the exact same thing but close. This code also dosn't
work.

Similar Messages

  • How to use the index method for pathpoints object in illustrator through javascripts

    hii...
    am using Illustrator CS2 using javascripts...
    how to use the index method for pathpoints object in illustrator through javascripts..

    Hi, what are you trying to do with path points?
    CarlosCanto

  • How do I use the Index Values property node with a multidimensional array.

    I am using a 2D array to store operator inputs on my front panel.  I only want to display one element to the operator at a time.  I am trying to use the Index Values property node to change the displayed element.  However, I can only get the Rows index to work.  How do I direct the Columns index as well?  The help says to use one per dimension.  I need clarification on what this is talking about.  I've tried adding a second element to the property node, 2 seperate property nodes, and diferent wiring techniques. (series, parallel)

    If you only wire up one of the inputs (col or row) what you get out is a 1D array of either the column or row. If you wire controls to both, then you will get one element out of the array. Getting a single element in a 2D array requires you to specify both a row and column.
    Message Edited by Dennis Knutson on 02-08-2007 08:34 AM
    Attachments:
    Index 2D Array.PNG ‏2 KB

  • Why is this query not using the index?

    check out this query:-
    SELECT CUST_PO_NUMBER, HEADER_ID, ORDER_TYPE, PO_DATE
    FROM TABLE1
    WHERE STATUS = 'N'
    and here's the explain plan:-
    1     
    2     -------------------------------------------------------------------------------------
    3     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    4     -------------------------------------------------------------------------------------
    5     | 0 | SELECT STATEMENT | | 2735K| 140M| 81036 (2)|
    6     |* 1 | TABLE ACCESS FULL| TABLE1 | 2735K| 140M| 81036 (2)|
    7     -------------------------------------------------------------------------------------
    8     
    9     Predicate Information (identified by operation id):
    10     ---------------------------------------------------
    11     
    12     1 - filter("STATUS"='N')
    There is already an index on this column, as is shown below:-
         INDEX_NAME INDEX_TYPE     UNIQUENESS     TABLE_NAME     COLUMN_NAME     COLUMN_POSITION
    1     TABLE1_IDX2 NORMAL     NONUNIQUE     TABLE1      STATUS     1
    2     TABLE1_IDX NORMAL     NONUNIQUE     TABLE1     HEADER_ID     1
    So why is this query not using the index on the 'STATUS' Column?
    I've already tried using optimizer hints and regathering the stats on the table, but the execution plan still remains the same, i.e. it still uses a FTS.
    I have tried this command also:-
    exec dbms_stats.gather_table_stats('GECS','GEPS_CS_SALES_ORDER_HEADER',method_opt=>'for all indexed columns size auto',cascade=>true,degree=>4);
    inspite of this, the query is still using a full table scan.
    The table has around 55 Lakh records, across 60 columns. And because of the FTS, the query is taking a long time to execute. How do i make it use the index?
    Please help.
    Edited by: user10047779 on Mar 16, 2010 6:55 AM

    If the cardinality is really as skewed as that, you may want to look at putting a histogram on the column (sounds like it would be in order, and that you don't have one).
    create table skewed_a_lot
    as
       select
          case when mod(level, 1000) = 0 then 'N' else 'Y' end as Flag,
          level as col1
       from dual connect by level <= 1000000;
    create index skewed_a_lot_i01 on skewed_a_lot (flag);
    exec dbms_stats.gather_table_stats(user, 'SKEWED_A_LOT', cascade => true, method_opt => 'for all indexed columns size auto');Is an example.

  • Does an 'in' clause use the index?

    In the following query:
    Select * from myTable where field_1 in ('thisfield', 'thatfield');
    Assuming there is an index on field_1, will this query use the index?
    Thanks,
    Sara

    In the following query:
    Select * from myTable where field_1 in ('thisfield', 'thatfield');
    Assuming there is an index on field_1, will this query use the index?It should use the index to find where the row you want is in the table and then access the table to return all colunms for that row.
    This can be easily verified by doing an explain plan on your SQL statement. The Oracle manuals should have information on how to
    run an explain plan if you're not familiar with it.

  • Query not using the index

    Query
    SELECT case.case_objid FROM [email protected] case, table_x_cwp_tickect_details_vw t WHERE CASE.case_condition_cd IN ('OPEN', 'OPEN-DISPATCH', 'OPEN-REJECT', 'OPEN-RETURNED') AND case.case_type_cd in ('CUSTOMER FAULT', 'CHRONIC','SCHEDULED ACTIVITY','PROBLEM') AND ROWNUM <= 500 AND case.case_objid = t.ticket_objid AND ( ( case.account_id = '672286' ) ) ORDER BY case.case_id DESC
    From PROD
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 2,629 Bytes: 221,500 Cardinality: 500
         37 SORT ORDER BY Cost: 2,629 Bytes: 221,500 Cardinality: 500
              36 COUNT STOPKEY
                   35 NESTED LOOPS OUTER Cost: 2,628 Bytes: 279,533 Cardinality: 631
                        33 HASH JOIN OUTER Cost: 2,627 Bytes: 275,116 Cardinality: 631
                             31 NESTED LOOPS OUTER Cost: 2,249 Bytes: 266,282 Cardinality: 631
                                  28 NESTED LOOPS Cost: 1,766 Bytes: 257,448 Cardinality: 631
                                       26 NESTED LOOPS Cost: 1,765 Bytes: 253,031 Cardinality: 631
                                            24 NESTED LOOPS Cost: 1,764 Bytes: 248,614 Cardinality: 631
                                                 22 NESTED LOOPS Cost: 1,763 Bytes: 244,197 Cardinality: 631
                                                      19 NESTED LOOPS Cost: 1,258 Bytes: 235,363 Cardinality: 631
                                                           17 NESTED LOOPS Cost: 1,257 Bytes: 230,946 Cardinality: 631
                                                                14 NESTED LOOPS OUTER Cost: 752 Bytes: 217,695 Cardinality: 631
                                                                     12 HASH JOIN Cost: 751 Bytes: 213,278 Cardinality: 631
                                                                          1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                          11 HASH JOIN Cost: 748 Bytes: 208,861 Cardinality: 631
                                                                               2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                               10 HASH JOIN Cost: 746 Bytes: 204,444 Cardinality: 631
                                                                                    3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                    9 HASH JOIN Cost: 743 Bytes: 200,027 Cardinality: 631
                                                                                         4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                         8 NESTED LOOPS Cost: 741 Bytes: 195,610 Cardinality: 631
                                                                                              5 REMOTE REMOTE CASE Cost: 235 Bytes: 156,488 Cardinality: 631
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                     13 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                16 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                     15 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                           18 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      21 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                           20 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                 23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                            25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                       27 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                  30 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                       29 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                             bold 32 TABLE ACCESS FULL TABLE SA.TABLE_MOD_LEVEL Cost: 376 Bytes: 1,442,084 Cardinality: 103,006 bold
                        34 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    From DEV platform
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 591 Bytes: 61,134 Cardinality: 138
         37 SORT ORDER BY Cost: 591 Bytes: 61,134 Cardinality: 138
              36 COUNT STOPKEY
                   35 HASH JOIN Cost: 590 Bytes: 61,134 Cardinality: 138
                        1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                        34 HASH JOIN Cost: 588 Bytes: 60,168 Cardinality: 138
                             2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                             33 HASH JOIN Cost: 585 Bytes: 59,202 Cardinality: 138
                                  3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                  32 HASH JOIN Cost: 583 Bytes: 58,236 Cardinality: 138
                                       4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                       31 NESTED LOOPS OUTER Cost: 580 Bytes: 57,270 Cardinality: 138
                                            29 NESTED LOOPS OUTER Cost: 579 Bytes: 56,304 Cardinality: 138
                                                 27 NESTED LOOPS OUTER Cost: 469 Bytes: 54,372 Cardinality: 138
                                                      24 NESTED LOOPS Cost: 363 Bytes: 52,440 Cardinality: 138
                                                           22 NESTED LOOPS Cost: 362 Bytes: 51,474 Cardinality: 138
                                                                20 NESTED LOOPS Cost: 361 Bytes: 50,508 Cardinality: 138
                                                                     18 NESTED LOOPS Cost: 360 Bytes: 49,542 Cardinality: 138
                                                                          15 NESTED LOOPS Cost: 249 Bytes: 47,610 Cardinality: 138
                                                                               13 NESTED LOOPS Cost: 248 Bytes: 46,644 Cardinality: 138
                                                                                    10 NESTED LOOPS OUTER Cost: 138 Bytes: 43,746 Cardinality: 138
                                                                                         8 NESTED LOOPS Cost: 137 Bytes: 42,780 Cardinality: 138
                                                                                              5 REMOTE REMOTE CASE Cost: 26 Bytes: 34,224 Cardinality: 138
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                                         9 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                                    12 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                                         11 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                                               14 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                          17 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                                               16 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                                     19 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                21 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                           23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      26 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                                           25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                                       bold           28 INDEX RANGE SCAN INDEX SA.IND_PART_INFO2PART_NUM Cost: 1 Bytes: 14 Cardinality: 1 bold
                                            30 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    Conclusion:
    IND_PART_INFO2PART_NUM is not in use in Production environment
    PROD
    1. SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR
    IND_PART_INFO2PART_NUM 103023 46488
    DEV environment
    SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR,table_name from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR TABLE_NAME
    IND_PART_INFO2PART_NUM 101982 45722 TABLE_MOD_LEVEL
    1. Index is rebuild
    2. stats are up to date
    3. Redef on table is done.
    Still no change in the plan .

    Osama-mustafa wrote:
    Aman.... wrote:
    Osama-mustafa wrote:
    alter index <index-name> rebuild ;Why?
    Aman....I faced this issue with query and indexes was need rebuildWhat issue Osama-that query wasn't using index and after rebuild it did start using it? Not just that this reply is wrong , this is OP has mentioned that he has done already. Please note that index rebuild is not the answer when the query is not using the index. There can be many reasons behind it. Have a look at Richard Foote's blog where he explains all of this in a very detailed way and in many posts.
    Aman....

  • Why is Oracle not using the index??

    Hi,
    I have a table called 'arc_errors' which has an index on 'member_number' as follows:- Create/Recreate indexes
    create index DWO.DW_ARC_CERRORS_MNO on DWO.DW_ARC_CERRORS (MEMBER_NUMBER);
    But surpisingly, when I execute the following query, it does not use the index.
    SELECT member_number,
    COUNT(*) error_count
    FROM arc_errors a
    WHERE member_number = 68534152 AND
    ( tx_type = 'SDIC' AND
    error_number IN (4, 7, 12, 13, 15, 17, 18, 705) )
    OR
    ( tx_type = 'AUTH' AND
    error_number IN (100, 104, 107, 111, 116) )
    OR
    ( tx_type = 'BHO' AND
    error_number IN (708,710) )
    OR
    ( tx_type = 'XLGN' AND
    ( error_number BETWEEN 102 AND 105 OR
    error_number BETWEEN 107 AND 120 OR
    error_number BETWEEN 300 AND 304 ) )
    OR
    ( tx_type = 'None' AND
    ( error_number IN (20, 112) OR
    error_number BETWEEN 402 AND 421 ) )
    OR
    ( tx_type = 'HYBR' AND
    error_number IN (303, 304) )
    GROUP BY member_number;
    This is what 'explain plan' tell me
    SELECT STATEMENT, GOAL = RULE               237907     502923     15087690     
    SORT GROUP BY               237907     502923     15087690     
    PARTITION RANGE ALL                              
    TABLE ACCESS FULL     DWO     DW_ARC_CERRORS     237209     502923     15087690     
    Can someone tell me why a 'table acess full' is required here?
    Thanks in advance,
    Rajesh

    Sorry, I just found the solution myself. I need to put an extra pair of braces around the set of conditions seperated by OR.

  • Why does it not use the index?

    L.S.,
    We are using a table called IT_RFC_REGISTRATION. It is a relatively big table for our application.
    Its primary key is RFCNR, each new RFCNR getting the next value.
    Now for my intranet report I am interested in the last 40 records. But when I execute:
    SELECT *
    FROM IT_RFC_REGISTRATION
    ORDER BY RFCNR DESC
    the query takes ages to execute.
    When I do this:
    SELECT RFCNR
    FROM IT_RFC_REGISTRATION
    ORDER BY RFCNR DESC
    the result comes instantaneous because this query uses the index on RFCNR.
    Why does the former query not use the index to execute? It should be much faster to fetch ROWIDs from the index end to start and use those to get the records, than to load all the records and then sort them.
    Is there a trick with which I can use a join of the latter query and the former query to speed up the result?
    Greetings,
    Philbert de Zwart,
    Utrecht, The Netherlands.

    The difference you see in query run time is based on the amount data being sorted, then returned. In the first query, a full table scan is faster since if the index was used, Oracle would have to do a lookup in the index, get the rowid's and go look up the data in the table (TWO disk i/o's). It's faster to just scan the entire table.
    Indexes will generally not be used unless you have a where clause. If you only need a few fields from the table, you could include them all in an index. For instance, if you only need RFCNR & DESC create a concatenated index on those two columns and then only a scan of the index is required (very fast).

  • How to find out if your query uses the indexes?

    How can one tell if the query being issued is using your indexes or doing full table scans?
    Thank you.

    Thank you.
    Ok, let me see if I understand it. So, having an
    index may not speed things up.True
    Full table scans are not bad at all -- as I have it
    in my head. The query I ran before was: select *
    from table1;In that case an index would only slow things down; you are asking it to get all the information from the table - it has to read all of the table ( a full scan).
    >
    So full table scans and index have to do with the db
    block size and the size of the row correct?
    Block size and row size don't have a huge amount to do with it, but they do play a role.
    Let me ask: How does one know the size of a row and
    then the best option for the db blocks? Block size is a global setting (at the tablespace level I think). You would not likely change the block size based on the average row length in any one table. It would be about the last thing you might look at in terms of tuning (though you might consider it up-front if you had a huge amount of very predictable data).
    >
    And if, I create indexes and queries have the where
    clause and the database uses full table scans then
    does it means that either:
    The database believes that the best execution plan is
    to either do FULL SCANS OR USE INDEXES -- ALL UPTO
    THE DATABASE?
    No. There is another piece of information that the database needs to make good decisions. If for example you have a WHERE clause "WHERE not_paid = 1" and you have an index on not_paid. To make a good decision the database needs to know about how many of the rows are likely to be not_paid =1. If it's 90% then a full table scan will be cheaper than looking up the addresses of 90% of the rows and then getting the data. If it's 10% using the index will be cheaper. You need to use Analyze Tables to get the database to store this information. Looks like you need to use a bit of time with the manuals.
    Jon
    -J

  • Why isn't my query using the index?

    I have a query that inserts values for engines in a grid; it uses a static date table to determine the day in week, or
    week in year (depending on different standards, the DBA can configure this table to their business's likings). I have
    two indexes on this table:
    create table d_date (
         date_key number(5) not null,
         sql_calendar_date timestamp(3) null,
         year_id number(5) null,
         month_id number(3) null,
         day_id number(3) null,
         year_end_biz_date timestamp(3) null,
         qtr_end_biz_date timestamp(3) null,
         month_end_biz_date timestamp(3) null,
         week_end_biz_date timestamp(3) null,
         quarter_id number(3) null,
         week_id number(3) null,
         day_in_year number(5) null,
         day_in_month number(3) null,
         day_in_week number(3) null,
         month_name char(3) null,
         day_in_week_name char(3) null,
         month_type_code char(1) null,
         week_type_code char(1) null,
         date_type_code char(1) null,
         weekend_flag char(1) null,
         holiday_flag char(1) null,
         from_datetime timestamp(3) null,
         to_datetime timestamp(3) null,
         current_flag char(1) null,
         constraint d_date_pkey primary key (date_key)
         ) tablespace dim;
    create index d_date_dy on d_date(year_id, day_in_year) tablespace_dim_idx;
    create index d_date_ww on d_date(year_id, week_id) tablespace_dim_idx;Now, when I run a query to insert the week id into a table based on two values, the year_key and day_in_year_key,
    it should use the d_date_dy index correct?
    Here is what the query looks like:
    INSERT INTO F_ENGINE (YEAR_KEY,MONTH_KEY,WEEK_IN_YEAR_KEY,DAY_IN_YEAR_KEY,DAY_IN_MONTH_KEY,HOUR_IN_DAY_KEY, Q_HOUR_IN_DAY_KEY,
      GRID_KEY,ENGINE_KEY,TIME_STAMP,ENGINE_CPU_UTIL,ENGINE_CPU_GRID_UTIL,MEMORY_TOTAL_BYTE, MEMORY_FREE_BYTE,DISK_FREE_MEGABYTE,
      PROCESS_COUNT,ENGINE_ID,GRID_ID,GRID_NAME,BATCH_ID,RECORD_VIEWABLE_F)
    SELECT EXTRACT(YEAR FROM START_DATETIME),EXTRACT(MONTH FROM START_DATETIME), DD.WEEK_ID,
      TO_NUMBER(TO_CHAR(START_DATETIME, 'DDD')), EXTRACT(DAY FROM START_DATETIME),EXTRACT(HOUR FROM START_DATETIME),
      FLOOR(EXTRACT(MINUTE FROM START_DATETIME)/15)*15,DG.GRID_KEY,DE.ENGINE_KEY, START_DATETIME,CPU_UTIL,DS_CPU,MEMORY,
      FREE_MEMORY,FREE_DISK,PROCESSES,ID,PE.GRID,DG.GRID_NAME,:B1 ,1
    FROM P_ENGINE PE, D_GRID DG, D_ENGINE DE, D_DATE DD
    WHERE PE.GRID = DG.GRID_ID AND DG.CURRENT_FLAG = 'Y' AND PE.ID = DE.ENGINE_ID AND DE.GRID_KEY = DG.GRID_KEY AND
      DE.CURRENT_FLAG = 'Y' AND PE.BATCH_ID = :B1 AND DD.YEAR_ID = EXTRACT(YEAR FROM START_DATETIME) AND
    DD.DAY_IN_YEAR = TO_NUMBER(TO_CHAR(START_DATETIME,'DDD'))
    ORDER BY EXTRACT(YEAR FROM START_DATETIME),EXTRACT(MONTH FROM START_DATETIME),
      EXTRACT(DAY FROM START_DATETIME),EXTRACT(HOUR FROM START_DATETIME),FLOOR(EXTRACT(MINUTE FROM START_DATETIME)/15)*15,
      DG.GRID_KEY,DE.ENGINE_KEY
    Here is the explain plan:
    Operation Object Object Type Order Rows Size (KB) Cost Time (sec) CPU Cost I/O Cost
    INSERT STATEMENT
    SORT ORDER BY
         HASH JOIN
           HASH JOIN
             HASH JOIN
              TABLE ACCESS FULL D_GRID TABLE 1 2 0.316 3 1 36887 3
              TABLE ACCESS FULL D_ENGINE TABLE 2 10 0.410 3 1 42607 3
             PARTITION LIST SINGLE   5 1434 344.496 9 1 2176890 9
              TABLE ACCESS FULL P_ENGINE TABLE 4 1434 344.496 9 1 2176890 9
                TABLE ACCESS FULL D_DATE TABLE 7 7445 283.550 19 1 3274515 18Now it is obviously not using the index for the d_date table since it is doing a full table access.
    Does this have something to do with the fact that I am using extract(), to_number(), to_char() functions in my WHERE clause that it is not allowing the use of the index?
    Any help would be greatly appreciated. Thanks.
    -Tim

    It's difficult to tell just from this. For one thing, you didn't post your query using the forum format tags, so it's hard to read and you didn't post your Oracle version.
    In the query, you don't always prefix columns with the table alias. That makes it impossible for us (and maintainers of this code) to know at a glance which table a column is in.
    It's possible that performing functions on a column will disable the index. Do your other tables have indexes? Do you have updated statistics on all the tables?
    The main reason the optimizer will not use an index is because it thinks it cheaper not to.

  • Rule-Based Optimizer doesn4t use the index

    Does anybody know why the rule-based optimizer doesn4t use the index of all columns in the where clause?
    I have a select that use the hint RULE to force the optimizer to work in rule mode and also one index to all columns used in the where clause. Analyzing the execution plan (EXPLAIN PLAN) I observed the optimizer accesses all tables, but one, using the index. There4s one table (the first of the execution plan) that is accessed using a Full Table Scan (FTS).
    I've rebuilt the index for this table, but the execution plan doesn4t change.
    Any suggestions?
    Thanks in advance.
    Eliane.

    Hi. Oracle may not use an index if it finds that a full table scan is quicker/more efficient. Try the hint /*+ INDEX (table index) */ and compare the query performance with that of the one without this hint. (As you know, if you force Rule-based approach, the COST column in EXPLAIN PLAN output will not be populated. You may have to use trace/tkprof.)

  • How to monitor perticuler sql statement using the INDEX or not?

    I am running on a long running quary, and the output is comming very late. So i want to know the sql quary is using the index or not? How to know that?

    If you want to check the real execution plan of a running query without waiting for query completion, you can try following steps that you should adapt to your query and your environment:
    1. start the query
    select
    count(*)
    from all_objects, all_objects;2. Retrieve in another session the SQL_ID and the CHILD_NUMBER of the running query:
    select sql_id, child_number, sql_text
    from v$sql
    where sql_text like '%all_objects%';3. use DBMS_XPLAN.DISPLAY_CURSOR to get the real execution plan from shared pool using SQL_ID and CHILD_NUMBER from step 2:
    select * from table(dbms_xplan.display_cursor(<sql_id>,<child_number>));Actually you don't need to restart the query if it is already running because the hint GATHER_PLAN_STATISTICS is only needed if you want to have current execution statistics.
    Edited by: P. Forstmann on 2 mars 2011 10:23

  • How can i know if my query is using the index ?

    Hello...
    How can i know if my query is using the index of the table or not?
    im using set autotrace on...but is there another way to do it?
    thanks!
    Alessandro Falanque.

    Hi,
    You can use Explain Plan for checking that your query is using proper index or not. First you need to check that Plan_table is installed in your database or not. If it is not there THEN THE SCRIPT WILL BE LIKE THIS:
    CREATE TABLE PLAN_TABLE (
    STATEMENT_ID VARCHAR2 (30),
    TIMESTAMP DATE,
    REMARKS VARCHAR2 (80),
    OPERATION VARCHAR2 (30),
    OPTIONS VARCHAR2 (30),
    OBJECT_NODE VARCHAR2 (128),
    OBJECT_OWNER VARCHAR2 (30),
    OBJECT_NAME VARCHAR2 (30),
    OBJECT_INSTANCE NUMBER,
    OBJECT_TYPE VARCHAR2 (30),
    OPTIMIZER VARCHAR2 (255),
    SEARCH_COLUMNS NUMBER,
    ID NUMBER,
    PARENT_ID NUMBER,
    POSITION NUMBER,
    COST NUMBER,
    CARDINALITY NUMBER,
    BYTES NUMBER,
    OTHER_TAG VARCHAR2 (255),
    PARTITION_START VARCHAR2 (255),
    PARTITION_STOP VARCHAR2 (255),
    PARTITION_ID NUMBER,
    OTHER LONG,
    DISTRIBUTION VARCHAR2 (30))
    TABLESPACE SYSTEM NOLOGGING
    PCTFREE 10
    PCTUSED 40
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 10240
    NEXT 10240
    PCTINCREASE 50
    MINEXTENTS 1
    MAXEXTENTS 121
    FREELISTS 1 FREELIST GROUPS 1 )
    NOCACHE;
    After that write the following command in the SQL prompt.
    Explain plan for (Select statement);
    Select level, SubStr( lpad(' ',2*(Level-1)) || operation || ' ' ||
    object_name || ' ' || options || ' ' ||
    decode(id, null , ' ', decode(position, null,' ', 'Cost = ' || position) ),1,100)
    || ' ' || nvl(other_tag, ' ') Operation
    from PLAN_TABLE
    start with id = 0
    connect by
    prior id = parent_id;
    This will show how the query is getting executed . What are all the indexes it is using etc.
    Cheers.
    Samujjwal Basu

  • Why my select is not using the index

    This is my index
    CREATE INDEX CONFIG_STATE_IDX ON IDENTIFIER
    (CONFIGURATION_ID, STATE)
    LOGGING
    TABLESPACE NII_INDEX
    PCTFREE 10
    INITRANS 2
    MAXTRANS 255
    STORAGE (
    INITIAL 64K
    MINEXTENTS 1
    MAXEXTENTS 2147483645
    PCTINCREASE 0
    FREELISTS 1
    FREELIST GROUPS 1
    BUFFER_POOL DEFAULT
    NOPARALLEL;
    This is my select statement:
    SELECT *
    FROM identifier i
    WHERE
         i.configuration_id = '89afead40a0c0b8d00628c59aa405ea4'
         AND i.state = 'QT'
    AND ROWNUM <6
    This is my exmplain plan result
    Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    SELECT STATEMENT Hint=CHOOSE          5           2128                     
    COUNT STOPKEY                                        
    TABLE ACCESS FULL     IDENTIFIER     133 K     19 M     2128                     
    Why it is not using the index on configuration_id and state.

    Possibility one: you didn't do an analyze statistics on the table and/or the index after index creation.
    Possibility two: The optimizer has determined that it can return the query result set with fewer I/Os if it does a FTS vs using the index (the optimizer is very keen on I/Os).

  • Select is not using the Index

    Hi,
    I have a Z-Table. The Primary key is:
    EQUNR and LFDNR
    I created now a new index with the field: EQUNR BSTNK .
    Now I entered 3 equnrs and bstnk like 07* in SE16n
    Normally what I thought should happen is that it uses the index to read the three equipments and than checks the field bstnk.
    Instead it does a sequentiel read of the hole table that contains 12mio entries!
    When I enter the bstnk more qualified like 0712354* the search is fast (1sec). Why is SAP bypassing the index and does a sequentiel read instead?!

    Hi I checked,
    ST05 the fast run was using an Index, the second didn't!
    Thanks to  John. After I started a runstat on this table it worked.
    But  the weird thing is when I use a inner join between my Z-Table and the EQUI table it doesn't use the index.
    When I first select all equnrs in EQUI and then select the data from my z-Table with for all entries it uses my new index!
    Example:
    EQUNR has Index on field SERNR
    Z-Table has Index on EQUNR + BSTNK
    in sernrs I have ~5 full qualified sernos
    in bstnk I have something like 07*
    3 of these serialnumbers are in a bstnk that begins with 07.
              select *
                into corresponding fields of table search_result
                from equi as a
                inner join z-table as b on b~equnr = a~equnr
                where   a~sernr     in sernrs
                  and   b~bstnk     in bstnks
    After 5 min I have to kill the process. in SM50 I can see sequential read...
    When I do this:
            select equnr
              from equi
              into corresponding fields of table lt_search_result
              where sernr in sernrs.
              select *
                from z_table
                into corresponding fields of table lt_search_result
                for all entries in lt_search_result
                where equnr = lt_search_result-equnr
                  and bstnk in bstnks.
    It takes 2sec and I got the result.
    Edited by: Daniel Winter on Apr 21, 2010 8:51 AM
    Edited by: Daniel Winter on Apr 21, 2010 8:51 AM

Maybe you are looking for

  • Change invoice status on old sales order?

    Hi, We are trying to archive old sales order but we got problem with some old sales orders. The sales orders aren't invoiced (for different reasons) so we can't archive them (Overall status: Being processed). Since the sale orders are very old we don

  • How to change order of network ports - unix command in Apple Remote Desktop

    I am trying to do a report of 130 machines and I want the IP addresses included in the report. When I do the report a bunch of them are missing because the only selection is "Primary Network IP" but on many of the machines the order of the network co

  • Dns server and client in java

    Hello! Im trying to code a dns server and client in java. It`s supposed to be a very simple one. The server should just resolve the query, started from the client. Where can I find any code samples? It would really help me to get started. Thank you v

  • Problem faced when installing oracle 10g

    i faced this problem when intalling oracle 10g in windows xp. this dos prompt opens for 5 min. and then it get closed..after tht nuthing happens. Starting Oracle Universal Installer... Checking installer requirements... Checking operating system vers

  • Problems with DAAP sharing

    Hello guys, I've got a bit of problem that's driving me nuts ;-). On my Macbook, I've got iTunes running. I've set it up so that it shares my music over the network (iTunes uses DAAP). The network setup is fine, a firewall is running on neither of my