Using Secondary Index

Hi,
I have a secondary index with 3 key fields.While wrting the select query with these 3 key fields I am providing 2 more non-key fields. Now the problem is that the secondary index in not used in this case. Can anybody help me why it is not using the secondary index.
For example:
Seconday Index fields are : fd1, fd2, fd3
In select query:
select A B C from  <XYZ> into table I_XYZ
where  fd1 = 'a'     " key field
and fd2 = 'b'         " key field
and fd3 = 'c'         " key field
and fd4 = 'd'         " non-key field
and fd5 = 'e'.        " non-key field
Problem : Query is not using the seconday index.
Regards
Sanjay

hi,
Check if your secondary index is having mandt field or not.
system changes your select as
select A B C from <XYZ> into table I_XYZ
where <b>mandt = sy-mandt  and</b>
fd1 = 'a' " key field
and fd2 = 'b' " key field
and fd3 = 'c' " key field
and fd4 = 'd' " non-key field
and fd5 = 'e'. " non-key field
so, secondary index will be chosen only if mandt is there in the list of fields in secondary index.
Regards
sailaja.

Similar Messages

  • Use secondary index in internal tables.

    what are the uses of secondary index in internal table?

    http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eb47446011d189700000e8322d00/content.htm
    Creating Secondary Indexes
    Proceed as follows to create a secondary index on a table:
    In the field maintenance screen for the table, choose Goto --> Indexes.
    1. If you went to the field maintenance screen of the table in display mode, only correct the index (and not the table).
    If indexes already exist on the table, a list of these indexes is displayed. Choose Create. A dialog box appears in which you must enter the three-place index identifier. If there are no indexes, go directly to the dialog box.
    2. Enter the index identifier and choose Continue.
    You will go to the maintenance screen for indexes.
    3. Enter an explanatory short text in the field Short text.
    Choose TabFields.
    4. A list of all the fields of the table is displayed.
    5. Select the fields which you want to copy to the index.
    6. Choose Copy.
    The selected fields are copied to the index.
    7. If the values in the index fields already uniquely identify each record of the table, select Unique index.
    A unique index is automatically created on the database during activation because a unique index also has a functional meaning (prevents double entries of the index fields).
    8. If it is not a unique index, leave Non-unique index selected. In this case you can use the corresponding radio buttons to define whether the index should be created automatically on the database for all database systems, for selected database systems or for no database system.
    9. If you chose For selected database systems, you must specify these systems.
    You have two possibilities here:
    List of inclusions: The index is only created automatically during activation for the database systems specified in the list. The index is not created on the database for the other database systems.
    List of exclusions: The index is not created automatically on the database during activation for the specified database systems. The index is automatically created on the database for the other database systems.
    Click on the arrow symbol behind the radio buttons. A dialog box appears in which you can define up to 4 database systems. Use the corresponding radio buttons to decide whether this list should be treated as a list of inclusions or exclusions.
    10. Activate the index with Index ® Activate. The activation log tells you about the flow of the activation. Call it with Utilities ® Act.log. If an error occurred when activating the secondary index, you will automatically go to this log.
    The secondary index is automatically created on the database during activation if the corresponding table has already been created there and index creation was not excluded for the database system.
    Reward points if useful.

  • How to use secondary index

    Hi abapers,
    Iam creating secondary index for the database table MSEG. ....How to write select query for the secondary index that i have created..
    Regards,
    Ramya

    how to create secondary index in tables
    https://forums.sdn.sap.com/click.jspa?searchID=933015&messageID=2971112
    Guidelines to create secondary index
    https://forums.sdn.sap.com/click.jspa?searchID=933015&messageID=2009801
    Secondary index;
    http://help.sap.com/saphelp_47x200/helpdata/en/cf/21eb2d446011d189700000e8322d00/content.htm
    this will definitely help you, dont forget to award points if found helpful

  • "Improving SQL query performance using secondary indexes"

    I have a very old copy of this document from 1997. I'm hoping to find newer version, if one exists, but the search facility on SDN is not working at the moment. Does anyone have a more up to date copy or link they can point me to ?
    thanks,
    Malcolm.

    HI,
    check it out , may be it will help you
    [http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10743/schema.htm]
    [http://teradata.uark.edu/research/wang/indexes.html]
    [http://www.geekinterview.com/question_details/33720]

  • Secondary Index Select Statement Problem

    Hi friends.
    I have a issue with a select statement using secondary index,
    SELECT SINGLE * FROM VEKP WHERE VEGR4 EQ STAGE_DOCK
                                      AND VEGR5 NE SPACE
                                      AND WERKS EQ PLANT
            %_HINTS ORACLE
            'INDEX("&TABLE&" "VEKP~Z3" "VEKP^Z3" "VEKP_____Z3")'.
    given above statement is taking long time for processing.
    when i check for the same secondary index in vekp table i couldn't see any DB index name with vekp~z3 or vekp^z3 or vekp____z3.
    And the sy-subrc value after select statement is 4. (even though values avaliable in VEKP with given where condition values)
    My question is why my select statement is taking long time and sy-subrc is 4?
    what happens if a secnodary index given in select statement, which is not avaliable in that DB Table?

    Hi,
    > ONe more question: is it possible to give more than one index name in select statement.
    yes you can:
    read the documentation:
    http://download.oracle.com/docs/cd/A97630_01/server.920/a96533/hintsref.htm#5156
    index_hint:
    This hint can optionally specify one or more indexes:
    - If this hint specifies a single available index, then the optimizer performs
    a scan on this index.  The optimizer does not consider a full table scan or
    a scan on another index on the table.
    - If this hint specifies a list of available indexes, then the optimizer
    considers the cost of a scan on each index in the list and then performs
    the index scan with the lowest cost. The optimizer can also choose to
    scan multiple indexes from this list and merge the results, if such an
    access path has the lowest cost. The optimizer does not consider a full
    table scan or a scan on an index not listed in the hint.
    - If this hint specifies no indexes, then the optimizer considers the
    cost of a scan on each available index on the table and then performs
    the index scan with the lowest cost. The optimizer can also choose to
    scan multiple indexes and merge the results, if such an access path
    has the lowest cost. The optimizer does not consider a full table scan.
    Kind regards,
    Hermann

  • Effect of Secondary Index on Performance Tuning

    Hi,
    I have a select statement with the below where statement.
    WHERE keyz1 = IT_dfkkzk-keyz1
    AND bldat IN s_pblda
    AND valut IN s_pvalu.
    Table from data is accessed Primary key is a combination of two fields KEYZ1 & POSZA.
    We have a Secondary Index with OPBEL & KEYZ1.
    Will Optimizer will use Secondary Index?
    If we change the where statement as given Below
    WHERE keyz1 = IT_dfkkzk-keyz1
    Will the access be fast?
    Should i create a secondary index on keyz1 to make it fast?
    Thanks & Reagrds
    Lijo Joseph

    Hi Lijo Joseph,
    I think, optimizer will use primary key because "WHERE keyz1" references the first part of this key. Even if you change your WHERE-statement as considered, this will not change optimizer approach.
    And yes, this access should be the fastest way to access you data, besides you have more values to reduce the amount of resulting rows. For example if you could specifiy POSZA too, this would accelerate access.
    Creation of another secondary index on keyz1 will not make it faster, maybe if you include bldat and valut in this key. But notice, insertion and modification of data will then be slower.
    To get optimizer to use existing secondary index you have to specify OPBEL in your where condition like this:
    "where OPBEL = 'X' and KEYZ1 = ....."
    Herbert

  • Reg. Secondary indexes

    HI,
    While using Secondary index,
    If I am having a table and I set fields f3,f4,f5 as secondary index1, f6,f7,f8 as secondary index2, f9,f10,f11 as secondary index3 for using them for selecting fields for 3 different programs respectively.
    Here i have some doubts---
    For doing like this, will the table be affected performance wise? if yes how? Then what will be solution for using those fields?
    pls suggest.
    thanks
    points will be awarded

    Hi everyone,
    I agree with Rob, in the sense I would not create any secondary indices on standard tables, if possible (unless recommended by a SAP note).
    In Z tables -> well, the performance of SELECT statements for those fields is improved, for sure. But every time you want to INSERT/UPDATE/DELETE on the table, SAP takes more time to do the operation, because it has to populate the data in the table, and also update the indices. So be careful and check the performance on your test systems before transporting to productive environment.
    I hope it helps. Best regards,
    Alvaro

  • Using a byte[] as a secondary index's key within the Collection's API

    I am using JE 4.1.7 and its Collections API. Overall I am very satisfied with the ease of using JE within our applications. (I need to know more about maintenance, however!) My problem is that I wanted a secondary index with a byte[] key. The key contains the 16 bytes of an MD5 hash. However, while the code compiles without error when it runs JE tell me
    Exception in thread "main" java.lang.IllegalArgumentException: ONE_TO_ONE and MANY_TO_ONE keys must not have an array or Collection type: example.MyRecord.hash
    See test code below. I read the docs again and found that the only "complex" formats that are acceptable are String and BigInteger. For now I am using String instead of byte[] but I would much rather use the smaller byte[]. Is it possible to trick JE into using the byte[]? (Which we know it is using internally.)
    -- Andrew
    package example;
    import com.sleepycat.je.Environment;
    import com.sleepycat.je.EnvironmentConfig;
    import com.sleepycat.persist.EntityStore;
    import com.sleepycat.persist.PrimaryIndex;
    import com.sleepycat.persist.SecondaryIndex;
    import com.sleepycat.persist.StoreConfig;
    import com.sleepycat.persist.model.Entity;
    import com.sleepycat.persist.model.PrimaryKey;
    import com.sleepycat.persist.model.Relationship;
    import com.sleepycat.persist.model.SecondaryKey;
    import java.io.File;
    @Entity
    public class MyRecord {
    @PrimaryKey
    private long id;
    @SecondaryKey(relate = Relationship.ONE_TO_ONE, name = "byHash")
    private byte[] hash;
    public static MyRecord create(long id, byte[] hash) {
    MyRecord r = new MyRecord();
    r.id = id;
    r.hash = hash;
    return r;
    public long getId() {
    return id;
    public byte[] getHash() {
    return hash;
    public static void main( String[] args ) throws Exception {
    File directory = new File( args[0] );
    EnvironmentConfig environmentConfig = new EnvironmentConfig();
    environmentConfig.setTransactional(false);
    environmentConfig.setAllowCreate(true);
    environmentConfig.setReadOnly(false);
    StoreConfig storeConfig = new StoreConfig();
    storeConfig.setTransactional(false);
    storeConfig.setAllowCreate(true);
    storeConfig.setReadOnly(false);
    Environment environment = new Environment(directory, environmentConfig);
    EntityStore myRecordEntityStore = new EntityStore(environment, "my-record", storeConfig);
    PrimaryIndex<Long, MyRecord> idToMyRecordIndex = myRecordEntityStore.getPrimaryIndex(Long.class, MyRecord.class);
    SecondaryIndex<byte[], Long, MyRecord> hashToMyRecordIndex = myRecordEntityStore.getSecondaryIndex(idToMyRecordIndex, byte[].class, "byHash");
    // END

    We have highly variable length data that we wish to use as keys. To avoid massive index sizes and slow key lookup we are using MD5 hashes (or something more collision resistant should we need it). (Note that I am making assumptions about key size and its relation to index size that may well inaccurate.)Thanks for explaining, that makes sense.
    It would be the whole field. (I did consider using my own key data design using the @Persistent and @KeyField annotations to place the MD5 hash into two longs. I abandoned that effort because I assumed (again) that lookup with a custom key design would slower than the built-in String key implementation.)A composite key class with several long or int fields will not be slower than a single String field, and will probably result in a smaller key since the UTF-8 encoding is avoided. Since the byte array is fixed size (I didn't realize that earlier), this is the best approach.
    --mark                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • When is a secondary index used (in select or where)

    HI All,
    We are confused (and new to ABAP) on the various postings on SDN concerning this topic.  Replies seem to vary.
    We have the following select statement:
    SELECT date1 FROM table2
    WHERE material (from a stored internal table) = material-table2
    AND order (from a stored internal table) = order-table2
    AND delivery method (from a stored internal table) = specific value of table2.
    For a second index to be created, would we create the index for only date1 (since it's the only field we are selecting from table 2) or an index with date1, material, order, delivery method or just what's in the WHERE clause of material, order and delivery method?
    How can you be sure that an index will be used?
    Thank you!

    > We are confused (and new to ABAP)
    seem you are very very new.
    Your question is actually not ABAP indexes etc are SQL and can be found in many textbooks also on Wiki pages. ABAP uses SQL, but does not change much.
    The use index is determined nearly only by the WHERE clause. You want to know the phone number of somebody and you know the name and the address. The Index uses the name and the address as a telephone book. The phone number comes from the table not the index! This is not the secondary index, but the primary index.
    If you search in the internet for phone number, then you can use also a secondary index, i.e. you know only the complete address but not the name. A phone book would not help here.
    Which index is used, if often very simple as in the example, but can become very difficult. That is done by a sophisticated program of the database, the optimizer. Check other resoucres for details.
    Siegfried

  • Is it possible to use a secondary index in embedded persistent class

    Hi,
    I'm new to Berkely DB Java Edition and have just started playing with it.
    To express a relation between two entities Foo and Bar, I am trying with an assocation class FooBarAssociation that is not an entity but rather a @Persistent-annotated embedded class in Foo (Foo has a collection of FooBarAssociations). Now I'm looking for a way to find all Foos associated with a given Bar id by use of an index. Can this be done? Is the use of the SecondaryKey in the embedded class at all correct? If this is not the way to go, can it be done any other way (except from using three entities)?
    @Entity
    class Bar {
        @PrimaryKey
        private int id;
    @Persistent
    class FooBarAssocication {
        @SecondaryKey(relatedEntity=Bar.class, relate=Relationship.ONE_TO_ONE)
        private int barId;
    @Entity
    class Foo {
        @PrimaryKey
        private int id;
        private Set<FooBarAssocication> fooBarAssociations = new HashSet<FooBarAssocication>();
    }Any help much appreciated.
    /Martin Söderström

    Martin,
    So could this be done with the embedded persistent class like this, or should I give up and make the FooBarAssociation class an entity of its own?A separate relationship entity class will definitely work, as described in the SecondaryIndex javadoc.
    But SecondaryKey fields have to be at the top level of an entity class, so an embedded class that contains the secondary key (and other attributes) won't work.
    Logically, you have a one-to-many relationship from Foo-to-Bar, and the relationship has attributes.
    If you store the relationship in the Bar entity, then it's pretty easy because there is one Bar instance per relationship and other attributes can easily be stored there. I know you said you want to put it in the Foo class because it logically belongs there, but I'll show this alternative anyway for completeness:
    @Entity
    class Bar {
        @PrimaryKey
        private int id;
        @SecondaryKey(relatedEntity=Foo.class, relate=Relationship.MANY_TO_ONE)
        private int fooId;
        private Date createTime;
    @Entity
    class Foo {
        @PrimaryKey
        private int id;
    }If it's really important to put the relationship fields into the Foo class, then you can do something like the following. It's messy to attach relationship attributes, but it can be done with either a parallel list or map.
    Also, be sure to read the "Key Placement with Many-to-Many for Related Entities" section of the SecondaryIndex javadoc page.
    @Entity
    class Bar {
        @PrimaryKey
        private int id;
    @Entity
    class Foo {
        @PrimaryKey
        private int id;
        // Use one of the following, either this:
        @SecondaryKey(relatedEntity=Bar.class, relate=Relationship.ONE_TO_MANY)
        private List<Integer> barIds = new ArrayList<Integer>;
        private List<Date> barCreateTimes = new ArrayList<Date>;
        // Or this:
        @SecondaryKey(relatedEntity=Bar.class, relate=Relationship.ONE_TO_MANY)
        private Set<Integer> barIds = new HashSet<Integer>;
        private Map<Integer, Date> barCreateTimes = new HashMap<Integer, Date>;
    From reading the documentation I also get the feeling that I could use the Base API and set up a SecondaryDatabase to create a secondary index for a case like this (correct?).Yes, you could do that, but I would hate to see you move to the base API just for this issue. The DPL is much easier to use (and easier for us to support).
    Anyway, so far the BDBJE looks very promising to us. It may replace our current Hibernate solution.Great. We'd love to hear more about what you're doing, why JE works well for you, etc, either on the forum or privately if you prefer (mark.hayes at o.com). It helps us a lot to know what people are doing with JE.
    --mark                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • Use two secondary indexes in a select statement

    hi, i want to use two secondary indexes in a select statement.
    how can i do it?

    Hello,
    To do it use the WHERE stm in the same order as the secondary stm is on SE11....To check if the index is used go to tcode ST05.
    example
    select * from ztable
    WHERE BUKRS EQ 'BUK1' AND
                 ZFIELD EQ 'BOY'.
    on se11 on the ZTABLE indexes setion must have a secondary index with
    BUKRS and
    ZFIELD.
    BYE!!
    Hope this helps!!
    Gabriel

  • Partial fields of Secondary index being used by the DB Optimizer

    Hello,
    I have written the following Query to select an std. SAP Index from GLPCA~1. However, when i run the SQL trace although the index is selected by the DB optimizer the results say that only 3 matching columns were used.
    bold Index GLPCA~1. bold
    KOKRS
    RYEAR
    RPRCTR
    RVERS
    RACCT
        SELECT rldnr
               rrcty
               rvers
               ryear
               rtcur
               rpmax
               rbukrs
               rprctr
               rfarea
               kokrs
               racct
               hslvt
               hsl01
               hsl02
               hsl03
               hsl04
               hsl05
               hsl06
               hsl07
               hsl08
               hsl09
               hsl10
               hsl11
               hsl12
               kslvt
               ksl01
               ksl02
               ksl03
               ksl04
               ksl05
               ksl06
               ksl07
               ksl08
               ksl09
               ksl10
               ksl11
               ksl12
               FROM glpct
               INTO TABLE i_glpct
               WHERE kokrs = 'BFS'
                  AND ryear = p_gjahr
                  AND rprctr IN r_prctr
                  AND rvers = '000'
                  AND racct IN r_acct.
    Now i am not sure which of the above 3 fields of the where condition are being selected but probably KOKRS and RVERS are not being used by the optimizer.
    Any pointers on how to make the optimizer utilize all 5 fields would be greatly appreciated.
    Thanks,
    Minhaj.

    Hello,
    I have written the following Query to select an std. SAP Index from GLPCA~1. However, when i run the SQL trace although the index is selected by the DB optimizer the results say that only 3 matching columns were used.
    bold Index GLPCA~1. bold
    KOKRS
    RYEAR
    RPRCTR
    RVERS
    RACCT
        SELECT rldnr
               rrcty
               rvers
               ryear
               rtcur
               rpmax
               rbukrs
               rprctr
               rfarea
               kokrs
               racct
               hslvt
               hsl01
               hsl02
               hsl03
               hsl04
               hsl05
               hsl06
               hsl07
               hsl08
               hsl09
               hsl10
               hsl11
               hsl12
               kslvt
               ksl01
               ksl02
               ksl03
               ksl04
               ksl05
               ksl06
               ksl07
               ksl08
               ksl09
               ksl10
               ksl11
               ksl12
               FROM glpct
               INTO TABLE i_glpct
               WHERE kokrs = 'BFS'
                  AND ryear = p_gjahr
                  AND rprctr IN r_prctr
                  AND rvers = '000'
                  AND racct IN r_acct.
    Now i am not sure which of the above 3 fields of the where condition are being selected but probably KOKRS and RVERS are not being used by the optimizer.
    Any pointers on how to make the optimizer utilize all 5 fields would be greatly appreciated.
    Thanks,
    Minhaj.

  • Difference between primary eindex and secondary index?

    hi experts
    pls answer me
    difference between primary eindex and secondary index?
    rewads apply.
    thanks.
    naresh.

    hi,
    check this link.
    http://help.sap.com/saphelp_47x200/helpdata/en/cf/21eb2d446011d189700000e8322d00/frameset.htm
    A difference is made between Primary & Secondary indexes to a table. the primary index consists of the key fields of the table and a pointer to the non-keys-fields of the table. The Primary index is generated automatically when a table is created and is created in the datebase as the same times as the table. It is also possible to define further indexes to a table in the ABAP/4 dictionary, which are then referred to as Secondary indexes.
    Always it is not mandatory that an index should have all the key fields of a table. To see the index of a table
    goto SE11->specify table name->click on the indexes... button on the application toolbar.
    Based on your requirement you can you any of those index fields in the where clause of your query. Always its a better practice to use the index fields in the order specified. While selecting the records from a table it is always better to select the fields in the same order as specified in the table.

  • Regarding secondary index

    how and when we create secondary indexes and what are the advantages and disadvantages of secondary indexes?

    Hi
    Index: Technical key of a database table.
    Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
    Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
    Structure of an Index
    An index can be used to speed up the selection of data records from a table.
    An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
    When creating indexes, please note that:
    An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
    Only those fields whose values significantly restrict the amount of data are meaningful in an index.
    When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
    Make sure that the indexes on a table are as disjunctive as possible.
    (That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
    Accessing tables using Indexes
    The database optimizer decides which index on the table should be used by the database to access data records.
    You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
    The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
    If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
    When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
    Regards

  • What is the "No database index" means when you Creating Secondary Indexes?

    HI,
       I'm Creating Secondary Indexes in the maintenance screen of the table(se11)
       There are three options under "Non-unique Index":
       1.Index on all database systems
       2.For selected database systems
       3.No database index
    My questions is :
      What do u mean by "No Database Index" and when is it used.
      Can anybody plz tell me what's the difference of this three options ?
      Here is what i found in the help:
       No database index: The index is not created in the database. If you
       choose this option for an index that already exists in the database,
       it is deleted when you activate this option.

    Hi,
    It is clear from the help documentation,
    Here see what the help document says:
    Create the index in the database (selection)
    Whether an index improves or worsens performance often depends on the database system. You can therefore set whether an index defined in the ABAP Dictionary should be created in the database.
    This makes it easier to install a platform-specific customer system.
    You can set this option as follows:
    1. Index in all database systems: The index is always created in the database.
    2. In selected database systems: The index is created depending on the database system used. In this option, you must specify the databases in which the indexes are to be created. You can do this either on an inclusive (list of systems on which it should be created) or an exclusinve (list of systems on which it should not be created) basis. In either case, you can list up to four different database systems.
    3. No database index:: The index is not created in the database. If you set this option for an index that already exists in the database, it is deleted when you activate the table in the ABAP Dictionary.
    Note: Unique indexes have an extra function, and must therefore always be created in the database. The database system prevents entries or index fields being duplicated. Since programs may rely on this database function, you cannot delete unique indexes from the database.
    Hope it helps you,
    Regards,
    Abhijit G. Borkar

Maybe you are looking for