Index impact on used memeory

Hi all,
I'm wondering what impact index has on the memory used by the grid?
I'm to keep some "tree like" objects in the grid. Object structure is quite simple. Object of type A contains a list of objects of type B. The list is accessible through A.getListOfB()
I would like to get all A objects that contain a given B object.
The idea was to use an index to fasten the query. The query itself is based on a filter like this:
B b = new B(...);
myCache().invokeAll( new ContainsFilter("getListOfB", b), entryProcessor);
However, before doing that, I'd like to clarify my understanding of index in Coherence.
What happens when we create an index of this kind : cache.addIndex(new ReflectionExtractor("getListOfB"), false, null);
Is it a kind of "inverted map" created in memory?
Is it efficient doing it that way?
What are the other options?
Rgds,
Harry

Here is the example codes I used to test it.
The filter class
public class ListFilter extends ExtractorFilter implements IndexAwareFilter {
     public ListFilter () {
          super();
     @Override
     public Filter applyIndex(Map mapIndexes, Set setKeys) {
          MapIndex index = (MapIndex)mapIndexes.get(new IdentityExtractor());
          if (index == null) {
               return this;
          Map mapContents = index.getIndexContents();
          for (Iterator iter = mapContents.entrySet().iterator(); iter.hasNext();) {
               Map.Entry entry = (Map.Entry) iter.next();
               /* the Entry we received here is B -> A like Robert mentioned, not {B1,B2,...} -> A */
               System.out.println(entry);
          return null;
     @Override
     public int calculateEffectiveness(Map arg0, Set arg1) {
          return 0;
     @Override
     protected boolean evaluateExtracted(Object arg0) {
          return false;
}The testing code
CacheFactory.ensureCluster();
NamedCache ca = CacheFactory.getCache("ACustomer");
ArrayList<String> list = new ArrayList<String>();
list.add("One");
list.add("Two");
list.add("Three");
ca.put("A", list);
ca.addIndex(new IdentityExtractor(), false, null);
ca.entrySet(new ListFilter());

Similar Messages

  • What is RID in non clustered index and its use

    Hi All,
    I need help regarding following articles on sql server
    1) what is RID in non clustered index and its use.
    2) What is Physical and virtual address space. Difference in 32 bit vs 64 bit Virtual address space
    Regards
    Rahul

    Next time Please ask single question in a thread you will get better response.
    1. RID is location of heap. When you create Non clustered index on heap and
    lookup happens to get extra records RID is used to locate the records. RID is basically Row ID. This is basic definition for you. Please read
    this Thread for more details
    2. I have not heard of Physical address space. I Know Virtual address space( VAS)
    VAS is simple terms is amount of memory( virtual )  'visible' to a process, a process can be SQL Server process or windows process. It theoretically depends on architecture of Operating System. 32 bit OS will have maximum range of 4 G VAS, it's calculated
    like a process ruining on 32 bit system can address max up to 2^32 locations ( which is equivalent to 4 G). Similarly for 64 bit max VAS will be 2^64 which is theoretically infinite. To make things feasible maximum VAS for 64 bit system is kept to 8 TB. Now
    VAS acts as layer of abstraction an intermediate .Instead of all request directly mapping to physical memory it first maps to VAS and then mapped to physical memory so that it can manage request for memory in more coordinated fashion than allowing process
    to do it ,if not it will  soon cause memory crunch.Any process when created on windows will see virtual memory according to its VAS limit.
    Please read
    This Article for detailed information
    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
    My Technet Wiki Article
    MVP

  • Index not getting used in spite of hints

    Its Oracle 10g Release 10.2.0.4.0 Hi All,
    I have this query in which there is are indexes on Intrument table like this:
    Instrument:
    idx 1 : (INSTRUMENT_ID, END_COB_DATE, CLOSE_ACTION_ID, PRODUCT_SUB_TYPE_ID, BEGIN_COB_DATE)
    idx 2 : ( INSTRUMENT_ID, INSTRUMENT_VN, END_COB_DATE, CLOSE_ACTION_ID)
    idx 3 : (CLOSE_ACTION_ID, END_COB_DATE)I tried all the possible ways but none of the indexes are getting used causing full table scans of this table. I need some guidance on how can I avoid this FTS so the query can run fast and use the index on Instrument table:
    query:
    select distinct i.instrument_id,
                    i.name,
                    case
                      when (mn2.display_name != 'DEBT PRIORITY CLASS' and
                           mn2.display_name is not null) then
                       mn2.display_name
                      else
                       mn1.display_name
                    end "DEBT_PRIORITY_CLASS"
      from instrument i, inst_debt id
      left join marsnode mn1 on (id.debt_priority_class_id = mn1.node_id and
                                mn1.close_date is null and
                                mn1.type_id = 58412926883279)
      left join marsnodelink mnl1 on (mn1.node_id = mnl1.node_id and
                                     mnl1.close_date is null and
                                     mnl1.begin_cob_date <=
                                     TO_DATE('27-Oct-2010', 'DD-Mon-YYYY') and
                                     mnl1.end_cob_date >
                                     TO_DATE('27-Oct-2010', 'DD-Mon-YYYY'))
      left join marsnode mn2 on (mnl1.parent_id = mn2.node_id and
                                mn2.close_date is null and
                                mn2.type_id = 58412926883279)
    where i.instrument_id = id.instrument_id
       and i.instrument_vn = id.instrument_vn
       AND i.end_cob_date > TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')
       AND i.close_action_id is null
       AND i.product_sub_type_id = 3
       AND i.begin_cob_date <= TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')This is the execution plan
    | Id  | Operation                       | Name              | Rows  | Bytes |TempSpc| Cost (%CPU)|
    |   0 | SELECT STATEMENT                |                   |  2026K|   407M|       |   509K (20)|
    |   1 |  HASH UNIQUE                    |                   |  2026K|   407M|   879M|   509K (20)|
    |*  2 |   HASH JOIN RIGHT OUTER         |                   |  2026K|   407M|       |   426K (23)|
    |*  3 |    TABLE ACCESS BY INDEX ROWID  | MARSNODE          |   501 | 23046 |       |   239   (3)|
    |*  4 |     INDEX RANGE SCAN            | FKI_38576_TYPE_ID | 10159 |       |       |    34   (6)|
    |*  5 |    HASH JOIN RIGHT OUTER        |                   |  2026K|   318M|       |   425K (23)|
    |*  6 |     TABLE ACCESS FULL           | MARSNODELINK      |   330 | 15510 |       |  6560  (16)|
    |*  7 |     HASH JOIN RIGHT OUTER       |                   |  2026K|   228M|       |   419K (23)|
    |*  8 |      TABLE ACCESS BY INDEX ROWID| MARSNODE          |   501 | 23046 |       |   239   (3)|
    |*  9 |       INDEX RANGE SCAN          | FKI_38576_TYPE_ID | 10159 |       |       |    34   (6)|
    |* 10 |      HASH JOIN                  |                   |  2026K|   139M|    34M|   418K (23)|
    |  11 |       TABLE ACCESS FULL         | INST_DEBT         |  1031K|    22M|       |  1665  (30)|
    *|* 12 |       TABLE ACCESS FULL         | INSTRUMENT        |  2062K|    96M|       |   413K (23)|*
    --------------------------------------------------------------------------------------------------predicate info
    2 - access("MNL1"."PARENT_ID"="MN2"."NODE_ID"(+))
    3 - filter("MN2"."CLOSE_DATE"(+) IS NULL)
    4 - access("MN2"."TYPE_ID"(+)=58412926883279)
    5 - access("MN1"."NODE_ID"="MNL1"."NODE_ID"(+))
    6 - filter("MNL1"."CLOSE_DATE"(+) IS NULL AND "MNL1"."END_COB_DATE"(+)>TO_DATE('
                2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "MNL1"."BEGIN_COB_DATE"(+)<=TO_DATE('
                2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
    7 - access("ID"."DEBT_PRIORITY_CLASS_ID"="MN1"."NODE_ID"(+))
    8 - filter("MN1"."CLOSE_DATE"(+) IS NULL)
    9 - access("MN1"."TYPE_ID"(+)=58412926883279)
    10 - access("I"."INSTRUMENT_ID"="ID"."INSTRUMENT_ID" AND
                "I"."INSTRUMENT_VN"="ID"."INSTRUMENT_VN")
    12 - filter("I"."PRODUCT_SUB_TYPE_ID"=3 AND "I"."CLOSE_ACTION_ID" IS NULL AND
                "I"."END_COB_DATE">TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                "I"."BEGIN_COB_DATE"<=TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))Regards,
    Aashish

    Aashish S. wrote:
    I tried all the possible ways but none of the indexes are getting used causing full table scans of this table. I need some guidance on how can I avoid this FTS so the query can run fast and use the index on Instrument table:I assume the last part of the above statement is what you actually need to achieve (i.e. improve execution time of the query) and the query not using index is what you think the "cause" for the actual "problem". I will try to answer the actual "problem". Based on what you have posted, some observations/suggestions
    1) Your plan shows the query is expected to retrieve 2026K rows. Are you sure you need to retrieve that many records? You may want to revisit the "requirement" here.
    2) Continuing above point, you may want to post details of how much time the query is taking to execute at present and how much time do you expect it to take. Another most important details will be how are you measuring the query execution time. With that huge number of records, it is quite possible that more time is being spent in just transferring the query results to the "client" than actual time taken by server to execute the query.
    3) If what you have posted is the order of columns in the indexes on INSTRUMENT table, then which index do you think will help the query execution and how? The order of columns suggest that none of the indexes will be good enough and that seems to be the right choice.
    4) Your predicate section states that filter predicate on INSTRUMENT table generates 2062K rows. How many records exist in INSTRUMENT table? You will need to have many times more records (besides other factors like ordering of table data etc.) in the table to justify the indexed access to fetch these huge number of rows.
    5) Finally, you may want to verify whether the statistics on tables and indexes used by the query are up-to-date.
    Hope this helps.

  • Index not being used in Select statement

    Friends
    I have the following SQL statement:
    SELECT
    a.acct,
    a.date_field,
    UPPER(b.feegroup) feegrp,
    SUM (a.fee1) fee1,
    SUM (a.fee2) fee2,
    SUM (a.fee3) fee3
    FROM table1 a, table2 b
    WHERE 1 = 1
    AND a.fee_id = b.fee_id
    GROUP BY a.acct, a.date_field, b.feegroup;
    Both the tables have index on fee_id column. When I run the explain plan for this statement, I am getting the following output:
    Operation | Option | Object Name | Position
    SELECT STATEMENT | | | 560299
    HASH | GROUP BY| |1
    TABLE ACCESS | FULL| table2 | 1
    TABLE ACCESS | FULL| table1 | 2
    Why Oracle is not using the index?
    Edited by: darshilm on Dec 10, 2009 3:56 PM

    The proposed plan is the optimal according to your current conditions in the "where clause" where you have only the equality join condition and therefore the CBO can use HASH JOIN. Using any kind of index access would just increase the amount of required work unless you would add some very restrictive conditions which will select rows from relatively small amount of blocks. Here I have to mention that what really counts in the CBO cost calculation is the amount of blocks accessed and not the number of rows. The "currency" for I/O in Oracle is a block and not a row. CBO always uses an assumption that there is nothing in the buffer cache and it will have to perform a physical read for every block.
    How many blocks will actually be accessed depends on the data distribution. It can happen that every single row that you have to retrieve resides in a different block and although you access only 1000 rows out of a million row table you would have to visit almost every block of that table. For such a situation a FULL TABLE SCAN is the best access path and Oracle will use multiblock I/O for that. On the other side you can have those 1000 rows only in a few blocks and then the index access would be the most appropriate one. For index access Oracle uses single block I/O. Usually the actual situation is somewhere between this two extreme situations. But you can run some tests by yourself and see when an index access will be replaced by a full table scan while you will make your predicates less selective.
    HTH, Joze
    Co-author of the forthcoming book "Expert Oracle Practices"
    http://www.apress.com/book/view/9781430226680
    Oracle related blog: http://joze-senegacnik.blogspot.com/
    Blog about flying: http://jsenegacnik.blogspot.com/
    Blog about Building Ovens, Baking and Cooking: http://senegacnik.blogspot.com

  • Index is not used (why and what should i do) table too big

    hi guys,
    having a headache now. (on 10gR2 on linux system)
    I used to have a large table and this is how i managed it. (i am on standard edition (thus i have no partitioning)
    i would have a
    1) cron job run daily to keep track of the lowest and highest ID of the table PER MONTH (inserted into a table)
    2) below is the table
    CDR     MONTH     01-AUG-11 00:00:00     94118236     97584656
    CDR     MONTH     01-SEP-11 00:00:00     97581362     100573669
    CDR     MONTH     01-OCT-11 00:00:00     100570865     103631203
    CDR     MONTH     01-NOV-11 00:00:00     103629760     106497084
    CDR     MONTH     01-DEC-11 00:00:00     106494085     107306335
    so as you can see, for the month of dec for example, the lowest CDR is 10649408 and the highest is 107306335.
    3) so everytime i write a sql on this table if i want to get data for NOV
    select * from cdr where ID >= get_cdr_id('CDR','NOV','SMALLEST');
    and it would be
    select * from cdr where ID >= 103629760;
    In the past, the index will be used (index range scan), but now the optimiser is doing a FTS and is taking too much time.
    therefore i went to force the index
    select /*+INDEX(C, CDR_PK)*/* from cdr C where cdr_id > 103629760 and cdr_id < 106497084;
    and the COST -> 1678927 (CDR, INDEX_ROWID)
    13158 (CDR_PK, RANGE SCAN)
    -- the result return is fast and good.
    without the index
    select * from cdr C where cdr_id > 100570865 and cdr_id < 103631203
    the COST -> 440236 (CDR,FULL)
    -- but the result return is slow like anything
    My question is
    1) which cost should i look at ?
    the one with index hint have much higher COST, but the results return are so FAST.
    1678927 (with hint) compare with 440236 (FTS)
    2) is using the index is the correct way, why isnt my optimiser using it ?! how do i make the optimiser used it ?
    Regards,
    Noob

    Iordan Iotzov wrote:
    About the clustering factor– I think there are two possibilities:
    1) The “clustering factor” is generally correct, i.e. it represents the true value of how the data is “scattered” through the table. The clustering factor for the fragment of data you are interested in (where cdr_id > 100570865 and cdr_id < 103631203), however, is different (smaller).
    2)Oracle did not compute the “clustering factor” correctly. It is not uncommon occurrence, particularly in 10g. This blog entry by Randolf Geist is quite informative - http://oracle-randolf.blogspot.com/2010/01/clusteringfactor-what-if-analysis.html. Comprehensive information on that topic is available in Jonathan Lewis’ book Cost Based Oracle Fundamentals (chapter 5).
    You can make the index more attractive by setting lower “clustering factor” value using DBMS_STATS.SET_INDEX_STATS. If you choose to do that, you should review your whole stats gathering procedure, because the next gathering would most likely reset the “clustering factor” to its old (high) value.
    Iordan Iotzov
    http://iiotzov.wordpress.com/

  • Why index is not used by this table

    Dear all,
    Currently I'm facing problem with tuning one sql statement.
    It shows that full table scan in ZTLTBC_FILTER cost 15:19.
    But in table ZTLTBC_FILTER, it have index with field
    index 1    MANDT INT_NAME FNAME VALUE
    index 2    MANDT EXEC_ID COUNTER
    index 3    MANDT INT_NAME VALUE
    the last statistic date for these index is three months before
    Could you please help to find out the reason why index is not used?  statistics are old or small distinct value for field INT_NAME?
    How to solve this full table scan problem?
    Thanks & Regards,
    Chris
    sql statement
    SELECT T_00."MANDT",T_00."EXEC_ID",T_00."COUNTER",T_00."FNAME",T_00."INT_NAME",T_00."VALUE"
    FROM "ZTLTBC_FILTER" T_00
    WHERE T_00."MANDT"=:A0 AND T_00."INT_NAME"=:A1 AND EXISTS
    (SELECT T_100."INT_NAME"
    FROM "ZTLTBC_MIRR_BUFF" T_100
    WHERE T_100."MANDT"=:A2 AND T_100."INT_NAME"=:A3 AND T_100."EXEC_ID"=T_00."EXEC_ID" AND
    T_100."COUNTER"=T_00."COUNTER")
    | Id  | Operation            | Name               | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |                    |       |       |       |   176K(100)|          |
    |*  1 |  HASH JOIN RIGHT SEMI|                    |  9958K|  1111M|   598M|   176K  (2)| 00:17:53 |
    |*  2 |   INDEX RANGE SCAN   | ZTLTBC_MIRR_BUFF~0 |  9958K|   484M|       |  6265   (1)| 00:00:39 |
    |*  3 |   TABLE ACCESS FULL  | ZTLTBC_FILTER      |    13M|   822M|       |   150K  (2)| 00:15:19 |
       1 - access("T_100"."EXEC_ID"="T_00"."EXEC_ID" AND "T_100"."COUNTER"="T_00"."COUNTER")
       2 - access("T_100"."MANDT"=:A2 AND "T_100"."INT_NAME"=:A3)
       3 - filter(("T_00"."INT_NAME"=:A1 AND "T_00"."MANDT"=:A0))

    Hello Bret,
    I'm using oracle 11.2
    Thanks & Regards,
    Chris

  • Index not being used (again)

    Dear All,
    Having real trouble these days with the indexes.
    I have a query below:
    SELECT MAX(A.ID) PRID,TIMEPERIODID,RESOURCEID
                          FROM   TIMESHEET A, TIMEPERIOD B
                          WHERE A.STATUS IN (1,3,4) AND A.ISADJUSTMENT = 0  
                             AND A.timeperiodid = B.id
                             AND TRUNC(B.PSTART)>=TRUNC(NEXT_DAY(SYSDATE-28,'MONDAY'))
                             GROUP BY TIMEPERIODID,RESOURCEID
    The explain plan for this query is as below:
    Plan     COST
    SELECT STATEMENT       2720
    SORT GROUP BY      2720
      HASH JOIN       2520
       TABLE ACCESS FULL TIMEPERIOD     2
       TABLE ACCESS FULL TIMESHEET     2516As you can see, table access full on timesheet table. However, I have an index on timeperiodid column of the table. Despite using it as hint, the index is not being used. Is it that indexes are not used with GROUP BY?
    Please help.
    Thanks,

    and the explain plan:
    Plan
    SELECT STATEMENT  ALL_ROWSCost: 18,747  Bytes: 105  Cardinality: 1                                                    
         34 SORT GROUP BY  Cost: 18,742  Bytes: 105  Cardinality: 1                                               
              33 FILTER                                          
                   21 NESTED LOOPS  Cost: 18,727  Bytes: 105  Cardinality: 1                                     
                        18 HASH JOIN  Cost: 18,722  Bytes: 415  Cardinality: 5                                
                             11 TABLE ACCESS BY INDEX ROWID TIMEENTRY Cost: 14  Bytes: 144  Cardinality: 9                           
                                  10 NESTED LOOPS  Cost: 15,980  Bytes: 15,552  Cardinality: 243                      
                                       8 HASH JOIN  Cost: 15,588  Bytes: 1,344  Cardinality: 28                 
                                            3 HASH JOIN  Cost: 4,050  Bytes: 24,876,930  Cardinality: 829,231            
                                                 1 TABLE ACCESS FULL TEAM Cost: 3,394  Bytes: 879,444  Cardinality: 48,858       
                                                 2 INDEX FAST FULL SCAN NON-UNIQUE TASK2 Cost: 396  Bytes: 11,656,104  Cardinality: 971,342       
                                            7 VIEW index$_join$_003 Cost: 10,376  Bytes: 24,981,984  Cardinality: 1,387,888            
                                                 6 HASH JOIN  Cost: 15,588  Bytes: 1,344  Cardinality: 28       
                                                      4 INDEX FAST FULL SCAN UNIQUE ASSIGNMENT1 Cost: 3,835  Bytes: 24,981,984  Cardinality: 1,387,888 
                                                      5 INDEX FAST FULL SCAN UNIQUE ASSIGNMENT4 Cost: 3,835  Bytes: 24,981,984  Cardinality: 1,387,888 
                                       9 INDEX RANGE SCAN NON-UNIQUE TIMEENTRY5 Cost: 2  Cardinality: 12                 
                             17 VIEW USER25. Cost: 2,741  Bytes: 553,812  Cardinality: 29,148                           
                                  16 SORT GROUP BY  Cost: 2,741  Bytes: 1,107,624  Cardinality: 29,148                      
                                       15 HASH JOIN  Cost: 2,540  Bytes: 1,107,624  Cardinality: 29,148                 
                                            13 TABLE ACCESS BY INDEX ROWID TIMEPERIOD Cost: 1  Bytes: 140  Cardinality: 10            
                                                 12 INDEX RANGE SCAN NON-UNIQUE TIMEPERIOD2 Cost: 1  Cardinality: 2       
                                            14 TABLE ACCESS FULL TIMESHEET Cost: 2,537  Bytes: 12,040,224  Cardinality: 501,676            
                        20 TABLE ACCESS BY INDEX ROWID TIMEPERIOD Cost: 1  Bytes: 22  Cardinality: 1                                
                             19 INDEX UNIQUE SCAN UNIQUE TIMEPERIOD1 Cardinality: 1                           
                   32 NESTED LOOPS  Cost: 5  Bytes: 75  Cardinality: 1                                     
                        29 NESTED LOOPS  Cost: 4  Bytes: 63  Cardinality: 1                                
                             27 NESTED LOOPS  Cost: 2  Bytes: 37  Cardinality: 1                           
                                  25 NESTED LOOPS  Cost: 2  Bytes: 31  Cardinality: 1                      
                                       23 TABLE ACCESS BY INDEX ROWID OBS_TYPES Cost: 1  Bytes: 18  Cardinality: 1                 
                                            22 INDEX UNIQUE SCAN UNIQUE OBS_TYPES_U2 Cardinality: 1            
                                       24 INDEX RANGE SCAN NON-UNIQUE PROJECT_INDX1 Cost: 1  Bytes: 13  Cardinality: 1                 
                                  26 INDEX UNIQUE SCAN UNIQUE PROJECTS_PK Bytes: 6  Cardinality: 1                      
                             28 INDEX RANGE SCAN NON-UNIQUE OBS_ASSOCIATIONS_N3 Cost: 2  Bytes: 26  Cardinality: 1                           
                        31 TABLE ACCESS BY INDEX ROWID OBS_UNITS Cost: 1  Bytes: 12  Cardinality: 1                                
                             30 INDEX UNIQUE SCAN UNIQUE OBS_UNITS_U1 Cardinality: 1                           

  • Index is not used

    I have a simple query to select from a huge table and where clause has a function to return a single value like this:
    select id from tab where status=get_status(flag);
    However, it's doing a full-table scan which cause problem for us. If I replace the function with a value or add a hint, then it's using indexes:
    select id from tab where status='L'; or select /*+ index (tab, status) */ id from tab where status=get_status(flat);
    What could be the cause of the index not being used in the original query?

    I suppose that 'flag' is a column in the table. If so then a full table scan (or full index scan) will probably be the fastest method to get the result.
    You could try to create an index on a function like
    decode(status,get_status(flag),1,null)and then have
    decode(status,get_status(flag),1,null)=1in your where clause.
    One peace of warning: if status is NULL and get_status(flag) also is null then this function will 1 and not null.

  • Index not getting used

    Hi,
    Oracle version 10g
    I have created a partitioned table and it has the below columns:
    The table is partitioned on the created_date.
    How data gets inserted into this table:
    we have a staging table which will get first populated and then using Exchange partitionis populated.
    statement which populates rel_table
    ' ALTER TABLE ' || table1 ||
    ' EXCHANGE PARTITION ' ||partitionname ||
    ' WITH TABLE ' || table2 ||
    ' WITH VALIDATION UPDATE GLOBAL INDEXES';
    after exchange partition the indexs gets rebuild
    The table would have millions of records.
    Now if i issue a query
    plz help...                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    But the indexed column is used in the join, so the index should get used right?Not necessarily. How many rows are in the table? How many rows have that column > 0?
    Please read these:
    When your query takes too long
    When your query takes too long ...
    How to Post a SQL statement tuning request
    HOW TO: Post a SQL statement tuning request - template posting

  • Newly created index not being used

    Hello friends,
    I am observing that a newly created index on a z table with mandt & a new field is not being used. I have already rebuild index & updated stats for table.
    when we query on this table with where clause having same 2 fields mandt & other.. we expected this index to be used. This table is very large. What more i can do now ?
    In trace/SQL session, we can see it is going full table scan.. and takes very long time.
    this new field contain no data as of now for all existing rows. Is this the reason ? or sometihng else ?
    SQL Statement
    SELECT
    FROM
      "ABSA"
    WHERE
      "MANDT" = :A0 AND "ZABCD" = :A1
    Execution Plan
    Explain from v$sql_plan not possible ->  Explain from PLAN_TABLE is displayed !
    No values in v$sql_plan for Address: 0000000166710240 Hash_value:  3891403872 Child_number:  0 Sql_id:
    SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
            1 TABLE ACCESS FULL ZABSA
              ( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
              Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
              Filter Predicates
    NONUNIQUE  Index   ZABSA~Z01
    Column Name                     #Distinct
    MANDT                                          1
    ZABCD                                         1
    thanks & regards
    ashish
    Edited by: ashish vikas on Mar 3, 2012 9:05 PM

    ashish vikas wrote:
    > Execution Plan
    > Explain from v$sql_plan not possible ->  Explain from PLAN_TABLE is displayed !
    > No values in v$sql_plan for Address: 0000000166710240 Hash_value:  3891403872 Child_number:  0 Sql_id:
    >
    >  SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
    >
    >         1 TABLE ACCESS FULL ZABSA
    >           ( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
    >           Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
    >           Filter Predicates
    >
    > NONUNIQUE  Index   ZABSA~Z01
    > Column Name                     #Distinct
    > MANDT                                          1
    > ZABCD                                         1
    Hi,
    with this WHERE clause, both columns just one distinct value, the Full Table Scan is indded the best approach, beside
    the point you only need a check to evaluate a value is NOT in the result.
    In this case you should HINT the statement to the new index, because the DB will always assume that this index is non-selective.
    Volker

  • How can i know which index will be used when executing the query ?

    1 ) I have query in which i have 3-4 tables but there multiple index on one column .
    so how can i know which index will be used when executing the query ?
    2) I have a query which ia taking too much time . how can i know which table is taking too much time ?
    3) Please Provide me some document of EXplain plan ?

    Hi Jimmy,
    Consider the below example
    /* Formatted on 2011/02/04 21:59 (Formatter Plus v4.8.8) */
    CREATE TABLE FIRST AS
    SELECT * FROM all_objects;
    UPDATE FIRST
    SET object_name = 'TEST'
    WHERE owner != 'SCOTT';
    CREATE INDEX idx_first ON FIRST(object_name);
    SELECT *
    FROM FIRST
    WHERE object_name = 'TEST';
    It has not used index
    Execution Plan
    Plan hash value: 2265626682
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 58678 | 7334K| 163 (4)| 00:00:02 |
    |* 1 | TABLE ACCESS FULL| FIRST | 58678 | 7334K| 163 (4)| 00:00:02 |
    /* Formatted on 2011/02/04 21:59 (Formatter Plus v4.8.8) */
    SELECT *
    FROM FIRST
    WHERE object_name = 'emp';
    This has used the index
    Execution Plan
    Plan hash value: 1184810458
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 128 | 1 (0)| 00:00:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| FIRST | 1 | 128 | 1 (0)| 00:00:01 |
    |* 2 | INDEX RANGE SCAN | IDX_FIRST | 1 | | 1 (0)| 00:00:01 |
    From this we can come to the conclusion that, whether to use one index or not by oracle
    would also depend on the data which is present in the table. This has to be this way as
    we see in the bind peeking, if oracle sticks to only one plan, say only use the full table
    scan, it would be a performance hit when it searches for the second query ie where object_name
    ='emp';
    2.
    If we have a query like below.
    select * from emp
    where upper(ename) = upper(:p_ename);
    Evenif we have the index on ename column, oracle wouldn't be able to use the index, as there is a function in the predicate column. If you need oracle to use the index, we need to create a function based index as below.
    Create index idx_ename on emp(upper(ename));
    Regards,
    Cool

  • Performance Impact of Using Sessions

    All,
    I have a general question regarding the performance impact of using Sessions
    within a Servlet. Specifically, I'm working with a group that wants to use
    the Session object to store customer contacts temporarily. The application
    is expected to service 2000 concurrent users, each maintaining no more then
    200 contacts each of which is about 1KB. The planned configuration is for a
    cluster of 10 instances of WLS. That said do we have any benchmark data
    that might assist in the session replication design, i.e. using in-memory
    across the cluster, using DBMS, etc.?
    Any information would be appreciated.
    Later,
    Jim Harrald
    BEA Systems
    Office: (901)263-4097
    Cell: (901)568-9267
    email: [email protected]

    All,
    I have a general question regarding the performance impact of using Sessions
    within a Servlet. Specifically, I'm working with a group that wants to use
    the Session object to store customer contacts temporarily. The application
    is expected to service 2000 concurrent users, each maintaining no more then
    200 contacts each of which is about 1KB. The planned configuration is for a
    cluster of 10 instances of WLS. That said do we have any benchmark data
    that might assist in the session replication design, i.e. using in-memory
    across the cluster, using DBMS, etc.?
    Any information would be appreciated.
    Later,
    Jim Harrald
    BEA Systems
    Office: (901)263-4097
    Cell: (901)568-9267
    email: [email protected]

  • Change array index font size using VI scripting

    Hello All,
                         I have a array control in my front panel, I'm wondering is there any way to change that "array index" font size using VI scripting?
    Example:
    1. I have this array
    2. Manually I have changed the font size of the array in "Selection Font" panel as below
    3. Through VI scripting I'm able to control control font size, label font size.,.. But not the index font size. So it looks odd.
    4. I'm expecting to be modify this array as same as picture 1 through VI scripting.
    Note: It may not have any practical application, but some time it will be helpful for the programmers to make a quick drop. If anybody have any idea, please share.
    <Electro Sam>
    ELECTRO SAM
    For God so loved the world that he gave his one and only Son, that whoever believes in him shall not perish but have eternal life.
    - John 3:16

    Raven - you are right, Actually I'm looking for options to change the font size of the array index.
    Actually we have coding standard to follow. In that, all the front panel controls needs to be in Font size 14 and the size should be 25X120, so I'm trying to write a code which automatically converts the VI FP control sizes to be in standard size.
    I'm not only using one customer VI, I'm handling various customer VIs, so each one VI FP control sizes are different. So I'm developing this utility to standardize the VI's as per the guidelines we have.
    Except this array index most of the VI FP control elements I have handled, Only this array is troubling me.
    Appreciate your support guys, please share your thoughts.
    <ElectroSam>
    ELECTRO SAM
    For God so loved the world that he gave his one and only Son, that whoever believes in him shall not perish but have eternal life.
    - John 3:16

  • How to assure index is being used for Query

    Hi All,
    Indexed are best way to speedup the data retrieval process selectively.
    however i wanted to how to trace that weather index is being used in a particular query.
    1. Table tab1 has composite index on a and b.
    2. Select a,b,c from tab1 where a>500 ;
    Will this query use index create from 1 ?
    Conceptually it should not because where as part contains only field A where as index is composit on field A and B.
    However , i wanted to know to trace that a perticual query is using index or not ?
    This question was asked to me in an interview.
    Pls le me know at [email protected]
    Thanks in Advance
    Alok

    Hi,
    Use explain plan to know if index is use.
    As you can see in the following example, even if index is composed and I use only a part in query, index can be used :
    SQL> create table test (col1 number, col2 number, col3 varchar2(10));
    Table created.
    SQL> insert into test select object_id, data_object_id, substr(object_name,1,10) from dba_objects;
    70211 rows created.
    SQL> create index idx on test(col1,col2);
    Index created.
    SQL> explain plan for
      2  select col1,col2,col3 from test where col1 > 500;
    Explained.
    SQL> @$ORACLE_HOME/rdbms/admin/utlxpls
    PLAN_TABLE_OUTPUT
    | Id  | Operation                   |  Name       | Rows  | Bytes | Cost  |
    |   0 | SELECT STATEMENT            |             |       |       |       |
    |   1 |  TABLE ACCESS BY INDEX ROWID| TEST        |       |       |       |
    |*  2 |   INDEX RANGE SCAN          | IDX         |       |       |       |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       2 - access("TEST"."COL1">500)
           filter("TEST"."COL1">500)
    Note: rule based optimization
    16 rows selected.
    --If stats are collected, index is no more used
    SQL> analyze table test compute statistics;
    SQL> explain plan for
      2  select col1,col2,col3 from test where col1 > 500;
    Explained.
    SQL> @$ORACLE_HOME/rdbms/admin/utlxpls
    PLAN_TABLE_OUTPUT
    | Id  | Operation            |  Name       | Rows  | Bytes | Cost  |
    |   0 | SELECT STATEMENT     |             | 69808 |  1227K|    16 |
    |*  1 |  TABLE ACCESS FULL   | TEST        | 69808 |  1227K|    16 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       1 - filter("TEST"."COL1">500)
    Note: cpu costing is off
    14 rows selected.
    --But if you use an equlity in your query instead of >, index is still used
    SQL> explain plan for
      2  select col1,col2,col3 from test where col1 = 500;
    Explained.
    SQL> @$ORACLE_HOME/rdbms/admin/utlxpls
    PLAN_TABLE_OUTPUT
    | Id  | Operation                   |  Name       | Rows  | Bytes | Cost  |
    |   0 | SELECT STATEMENT            |             |     1 |    18 |     3 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| TEST        |     1 |    18 |     3 |
    |*  2 |   INDEX RANGE SCAN          | IDX         |     1 |       |     2 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       2 - access("TEST"."COL1"=500)
    Note: cpu costing is off
    15 rows selected.
    SQL> Nicolas.

  • Index isn't used when specifying IS NULL

    Hello,
    I'm using Oracle 10.2.0.4. When I run this statement, the explain plan shows that a composite index is used which is expected.
    select * from isis.cour_off where orga_# = 4
    However, when I run the following statement, the explain plan shows FULL TABLE SCAN:
    select * from isis.cour_off where orga_# IS NULL
    Is this to be expected? If so, then why?

    Centinul wrote:
    If I had to wager a guess it's probably because the OP is selecting all the columns anyways so it's probably more efficient to use multi-block reads to retrieve the entire rows from the table. However, that's hard to say without data.Not really. It is not data what drives optimizer to use index or not in the first stage. In case of single column index main question is: is column NULLable? But, as you noted, OP has composite index . Therefore, question "is column NULLable" transforms into are all index columns NULLable? If they are - index can't be used no matter what, since it is possible table has rows where all index columns are NULL and therefore there will be no index entry for such row. If at least one index column is NOT NULL, index can be (doesn't mean will be) used:
    SQL> create table tbl
      2  as
      3  select level id,case mod(level,1000) when 0 then to_number(null) else level end val from dual connect by level <= 100000;
    Table created.
    SQL> create index tbl_idx on tbl(val,id);
    Index created.
    SQL> exec dbms_stats.gather_table_stats('SCOTT','TBL');
    PL/SQL procedure successfully completed.
    SQL> explain plan for select * from tbl where val is null;
    Explained.
    SQL> @?\rdbms\admin\utlxpls
    PLAN_TABLE_OUTPUT
    Plan hash value: 2144214008
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |   100 |   900 |    53   (8)| 00:00:01 |
    |*  1 |  TABLE ACCESS FULL| TBL  |   100 |   900 |    53   (8)| 00:00:01 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       1 - filter("VAL" IS NULL)
    13 rows selected.
    SQL> alter table tbl modify id not null;
    Table altered.
    SQL> explain plan for select * from tbl where val is null;
    Explained.
    SQL> @?\rdbms\admin\utlxpls
    PLAN_TABLE_OUTPUT
    Plan hash value: 2817369304
    | Id  | Operation        | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT |         |   100 |   900 |     2   (0)| 00:00:01 |
    |*  1 |  INDEX RANGE SCAN| TBL_IDX |   100 |   900 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       1 - access("VAL" IS NULL)
    13 rows selected.
    SQL> As you can see, even though column ID did not have any NULL values index wasn't used since potentially ID can be null. As soon as column ID was set to NOT NULL optimizer started using index.
    SY.

Maybe you are looking for

  • VPN DNS Problem

    Hi Everybody 302016 192.168.77.20          60817          FileServer_DNS          53          Teardown UDP connection 1003725 for outside:192.168.77.20/60817 to inside:FileServer_DNS/53 I am getting this error on my asa 5505 firewall and VPN user is

  • With version 9.0.1 I can no longer switch between Google accounts properly

    I have a personal Google account and a Google apps account (via my employer, with a custom domain). I normally can log into either one and switch between the two using the "switch accounts" function. This currently works in chrome, and worked in Fire

  • IPod Touch 2nd Gen Won't Turn On

    A few days ago i did a system restore on my ipod touch. I did it on the ipod touch and at first it was going well. The loading bar showed and it loaded all the way and then the apple symbol popped up. Unfortunately, it has had the same apple symbol f

  • Quality of Service Attributes in SOA Suite 10.1.3.4

    Hello, How do you setup QoS attributes for a ESB project in SOA Suite 10.1.3.4 ? In our project we have one Inbound JMS adapter and one Outbound JMS Adapter. I need to set up qualityOfService Element to 'best-effort'. Is there any oracle documentatio

  • Blank Screen and sound

    Today My Iphone Had Suddenly Turned Blank I Am Receiving A call but i cant hear any sound and the display went blank what is the reason for this ??I Updated My Phone To Ios 5 The Day Before Today I'm experiancing this problem Any Body Pls Help Me...