Secondary Index with or without MANDT field

HI ABAP Guru's,
What is necessary to add field MANDT while creation of secodary index in DBS.
But i some body my superiors challanged to me with out using MANDT our secoday index won't works.
But i tested few scenarios i am not get differnce.
please advice me exactly which scenarios it is mandatory.
Below are the Time taken with deffrent scnarios i created one test program to get the time with secondary index with out secodary index secondary index with mndat fiels
**&with out creation of seconday index
*1st time -57,103,681
2nd Time-55,388,294
**before creation of seconday index with out mandt
I1st time execution-324,119
2nd time progrm execution--391,134
3rd time progrm execution-327,046
4th time progrm execution336,774
5th time progrm execution359,100
6t time progrm execution-328,027
*before creation of seconday index with mandtiI1st time execution-367,623
2nd time progrm execution365,139
3rd-352,328
4th-369,122
5th-352,236
6th380,590
7th466,810
Thanks In Advance,
Kandula.
Edited by: Thomas Zloch on Nov 18, 2011 1:08 PM

Vishnu Tallapragada wrote:
So if you are maintaining multiple client data on the same database, then not adding MANDT to index will have undesirable effects as any select based on secondary index may return records that are not belonging to this client and deletes and additions on the index from multiple clients will lead to data integrity issues.
Wrong!
WHERE clause decides about data being selected, deleted or what-ever.
Index decides only about HOW data is accessed (if used), not WHAT data is accessed.
If your database returns a different result depending on the indexdefinition,
you should log a call at your DB vendor immediately, because this is a bug.
In general, as the client has usually only a small number of distinct values, it is not a good field,
to convince the database, that this index is a good idea. But on high volume tables it can be very selective
as far as the number of result records is concerned (might cut down 50% when 2 clients!).
In addition it is a very short field, so it should not cost much storage (esp. when compressable).
Szenario:
MANDT+IDX-Field with two clients and lets say 5000 record per client (so that idx access will be interesting),
assuming a given IDX value will return 50 records (25 in each client).
So the select will be
... WHERE MANDT=sy-mandt AND IDX=value
Accesing the index with only IDX will result in stepping down the index-tree (say 3 blocks) and then reading leafblocks
to get the 50 hits for IDX-value (assuming 30 records per leafblock -> 2 leafblocks required to gret the 50 records)
Right now you have accessed 5 blocks to get the address of 50 records that still need to be checked against MANDT.
So there is need to get 50 blocks (may be less, depending on clustering) to do a filter on MANDT
and get the final 25 records for the result.
If you put the MANDT field into the index it might require more space, so that we assume 20 records per leaf block now.
But since you can now filter MANDT already on the index blocks, you will again only need to get 5 blocks and
have the adress of the required 25 target records.
So getting the result is 55 blockinspections without MANDT in index and 30 blockinspections with MANDT in index in this case.
Now you can start pushing around values and statistics an calculate at what amount of data and average
size of resultsets it becomes right or wrong to include MANDT. It may turn out both ways, allthough I think
with MANDT being small, it is usually loss of brain cycles to calculate around for this.
You simply include it, it will cost only little space and it will never be wrong.
You leave it out, you will gain little space, but might end up with performance loss.
If you have only one client in the system, you can safely go with the saving space strategie, as long as you do not need
a UNIQUE secondary index.
Volker

Similar Messages

Secondary index issue

HI Experts
                I am having certain doubts in Secondary index i,e..
          for the table MSEG i created secondary index with LFBNR ,LFBJA, LFPOS fields ,Now in the select query if i used all these three fields in WHER condition then only the fetch will be fast ???
       OR if i use any ONE of these three fields in WHERE condition then the fetch will be normal as non-key field fetch ??
PLease clarify me
Regards,
Lokesh Rangappa

Hi Lokesh,
a secondary index is a fine way to get data faster, if you know the contents of the secondary key fields from the first on.
LFBNR is a very selective secondary key field, so you don't need to know the other secondary key fields and it should work fine.
It's a good idea to have the client field MANDT always as first secondary key field, and you don't need to ask for it in the SELECT query. This will be automatically done.
If you always know the year to access, then your secondary index should look like
MANDT LFBJA LFBNR LFPOS
to access data of the same year easier. If you don't kno the year, but you know the LFBNR, then your secondary index should look like
MANDT LBBNR LFPOS LFBJA
It is importatnt to know the first key fields of a secondary index (without the client, which will bea accessed according to SY-MANDT). And it is also important to know a selective secondary key field.
For example it is no good idea to create a secondary index with only field LFBJA in the first year, where all entries still have the same year.
You have to know the content of the first secondary key field(s), but you don't have to know the content of them all for SELECT queary.
Regards,
Klaus

Select query with secondary index

hi,
i have a report which is giving performance issues on a perticular select query on KONH table.
the select query doesnt use the primary key fields and table already has around 19 million entries.So there was a secondary index created for the fields in the table.
now, KONH is a client specific table, and hence has MANDT as the first field. when the table is not indexed it is sorted according to the order of fields, like first MANDT, then primary key fields and then remaining fields.. (correct me if i am wrong)
but the secondary index created doesnt has MANDT in it..(yea, a mistake! )...
but instead of correccting the secondary index, i am told to change the select query..
so, i used a "client specific" syntax to sort the issue.. but i dont understand whre i should put the "where mandt eq sy-mandt" clause..
should i put it right after all my secondary index fields are over? or what happens to the order of fields which are not present in the list of secondary index?
kindaly help.
thanx.

Hi chinmay kulkarni,
its better if you can ask concerned person to add MANDT field in your index as well....
Indexes and MANDT
If a table begins with the mandt field, so should its indexes. If a table begins with mandt and an index doesn't, the optimizer might not use the index.
Remember, if you will, Open SQL's automatic client handling feature. When select * from ztxlfa1 where land1 = 'US' is executed, the actual SQL sent to the database is select * from ztxlfa1 where mandt = sy-mandt and land1 = 'US'. Sy-mandt contains the current logon client. When you select rows from a table using Open SQL, the system automatically adds sy-mandt to the where clause, which causes only those rows pertaining to the current logon client to be found.
When you create an index on a table containing mandt, therefore, you should also include mandt in the index. It should come first in the index, because it will always appear first in the generated SQL.
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.)
For Example...
SELECT KUNNR KUNN2 INTO TABLE T_CUST_TERR
FROM KNVP CLIENT SPECIFIED
WHERE MANDT = SY-MANDT " here MANDT shd be first
AND KUNN2 IN S_TERR
AND PARVW LIKE 'Z%'.
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
Also pls have a look on below link
http://www.sapfans.com/sapfans/forum/devel/messages/30240.html
Hope it will solve your problem..
Reward points if useful...
Thanks & Regards
ilesh 24x7

How to rename database with secondary indexes.

Hi,
could somebody advise how to run correct next operation:
I have database with secondary indexes in a single file and I need to rename that db file.
As I understand I have to
1) close and delete all database handles
2) remove from db file all secondary indexes with DbEnv::dbremove
3) rename db file with DbEnv::dbrename
4) create primary db
5) create once again all secondary indexes and associate them with primary db
Appreciate in advance.

Hi,
Your question has two possible cases:
1. A single file contains main DB and its secondary indexes.
2. A file contains several secondary indexes of main DB, another file contains the main DB.
For the first case, the main database could be renamed directly, but all of the secondary databases do not continue to work. That means no new index items will be added automatically into exist secondary databases. So these secondary databases should be removed and created, you could also just run a DB->associate to re-associate it again. But in the later way, the re-associated secondary DB won't automatic index these records that are added before associating.
That means, if main db is renamed and then inserted a record 'A'. Then secondary DB is re-associated to main db. The secondary DB still does not index record 'A'. And currently there is not method to let secondary DB manually index 'A' again. So it is better to remove and create a new secondary DB with DB_CREATE flag. That will make the new secondary DB scan current items and index them.
For the second case, the result is the same, main database could be remained directly. Then all of the secondary databases should be re-created or re-associated. Still for the described reason, we prefer the first way.
And, removing old secondary databases before renaming main database is also work in above cases.
Thanks,
Victor Yang

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

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.

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

Two secondary indexes in a where clause

Hi All,
Can any one of you let me know wether DB optimizer will use two indexes if given in where clause........
example : primary index A,B.   secondary C,D,E.
select ................ where A in ....
                              B in ....
                              C in ....
so iam using all(two) fields of primary index and one field of secondary so will the DB optimizer search for the index blocks or directly the table blocks when it comes to the C field in the where clause......
Thanks in advance.

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

Guidelines to create secondary index

Hi Guys,
I'm trying to get a guidelines to create an optimize secondary index. For eg, how to analyze the list of fields should be included into the secondary index. What can be done and not.
Pls place your comment.
Thanks in advance.

Hi,
Basically index are provided to improver performance. i.e with index select on database tables retrieves data much faster.
If you are writting select statement on the table where in where clause you have non-primary keys then it takes longer to retriev data from Database table.
If you have select in dbtable on non-primary key you can create Secondary index with keys as per your where clause which result in faster Database table access.
But remember not to create too many secondary indexes on same table which could result in slow / degrage performance..
and also check this link :
http://help.sap.com/saphelp_470/helpdata/en/cf/21eb20446011d189700000e8322d00/frameset.htm
Regards
Appana

Using MANDT field in Inner joins

Experts,
I need your suggestions on using MANDT field in JOINS. Example
Select afield1 afield2 b~field1 from table1 as a
inner join table 2 b on amandt = bmandt
afield1 = bfield1
where......
Will it be a performance issue if I use the join without MANDT field?
Anand

probably stated in the note:
mandt in the WHERE condition is automatically added, but not in ON-condition.
Some databases had problems to figure out, that the mandit is always the same, i.e. did not use an index on second table. So adding mandt in ON condition can have impacts. In newer database releases this is no problem anymore. But anyway, the additional line in the ON-condition is no big deal.
Siegfried

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

C++ Secondary index multiple entries

Hi
I need to create a secondary index with multiple entries from a single primary record. I now that this is possible in the java version(SecondaryMultiKeyCreator), but I can't find the way to do it in c++.
Thanks in advance,
Rui Gil

Rui,
We think this would be a great capability to have in Berkeley DB.
At this time it is not supported. Consider this an item that we are considering (strongly) for a future release of Berkeley DB.
Regards,
Ron Cohen

Secondary Index Picked with one field short in select query

Hi,
We have a select query as follows
select single lgort       vgbel        vgpos
    into   (lips-lgort,lips-vgbel,lips-vgpos)
    from    lips
   where         vbeln          Eq p_zlcpp-vbeln
     and         matnr          Eq p_zlcpp-matnr
     and         charg          Eq p_zlcpp-charg
The secondary index ZB has the fields as follows:
MANDT     Client
MATNR     Material Number
CHARG     Batch Number
BWART     Movement Type (Inventory Management)
When seen in the trace it seems the select query picks this secondary index. Whether it is correct? since i find no BWART in the select query. Because of this index the query take large time. I used the Hint statement as follows:
select single lgort       vgbel        vgpos
    into   (lips-lgort,lips-vgbel,lips-vgpos)
    from    lips
   where         vbeln          Eq p_zlcpp-vbeln
     and         matnr          Eq p_zlcpp-matnr
     and         charg          Eq p_zlcpp-charg   %_HINTS ORACLE 'INDEX("LIPS" "LIPS~0")' .
and it now works fast. Please advice the best way to make the select query work on itself without using the hint statement to pick the index LIPS~0 instead of the invalid secondary index ZB.
Thanks & Regards,
Selvakumar M.
Edited by: Selva on Jun 17, 2011 7:35 PM

Hello Selva,
your problem here is the decision of the optimizer that does not exactly know the selectivity of the fields.
If your deliveries are normally small (not too many items), then selecting via the document number will be relatively fast.
And selecting via the material number + batch will be slow in case if many deliveries are having same product from the same batch delivered.
I assume that the latest is the case in your system. That's why the selection with ZB index is slow.
If the data distribution is as I described above, then your hint is quite OK and I advise you to stick to the hint.
From my PoV this is the better solution rather changing the coding and throwing out MATNR field from the WHERE clause to filter later in ABAP.
Another solution would be trying to play with histograms. But you'll need %SUBSTITUTE VALUES% or %SUBSTITUTE LITERALS% hint anyway, so I find your solution better.
So, please stay with hint. Even SAP standard development does it for some select statements.
Regards,
Yuri

Issue with select query for secondary index

Hi all,
I have created a secondary index A on mara table with fields Mandt and Packaging Material Type VHART.
Now i am trying to write a report
Tables : mara.
data : begin of itab occurs 0.
include structure mara.
data : end of itab.
*select * from mara into table itab*
CLIENT SPECIFIED where
MANDT = SY-MANDT and
VHART = 'WER'.
I'm getting an error
Unable to interpret "CLIENT". Possible causes of error: Incorrect spelling or comma error.
if i change to my select query     to
*select * from mara into table itab*
where
MANDT = SY-MANDT and
VHART = 'WER'.
I'm getting an error
Without the addition "CLIENT SPECIFIED", you cannot specify the client     field "MANDT" in the WHERE condition.
Let me know if iam wrong and we are at 4.6c
Thanks

Like I already said, even if you have added the mandt field in the secondary index, there is no need the use it in the select statement.
Let me elaborate on my reply before. If you have created a UNIQUE index, which I don't think you have, then you should include CLIENT in the index. A unique index for a client-dependent table must contain the client field.
Additional info:
The accessing speed does not depend on whether or not an index is defined as a unique index. A unique index is simply a means of defining that certain field combinations of data records in a table are unique.
Even if you have defined a secondary index, this does not automatically mean, that this index is used. This also depends on the database optimizer. The optimizer will determine which index is best and use it. So before transporting this index, you should make sure that the index is used. How to check this, have a look at the link:
[check if index is used|http://help.sap.com/saphelp_nw70/helpdata/EN/cf/21eb3a446011d189700000e8322d00/content.htm]
Edited by: Micky Oestreich on May 13, 2008 10:09 PM

Help me with Points to be noted While creating a Secondary Index.

Hi,
There is a Secondary index created on a Z table which already have 9 secondary indexes. This is the 10th index that is created.
The Index is created as follows
MANDT             Client
DOCNUM_REF     Document number
The Table data is huge and it is more than 4Lakh records.
I have done the following analyses.
1) The fields to be used are not in any other indexes.
2) The Data is mostly different, i.e. The document reference field is having distinct data
select a~docnum a~werks_o a~docnum_ref a~natop
         a~m_icms a~m_ipi
         b~lgort_out b~mov_est
         b~item b~matnr
    appending table ti_requisicoes
    from zsytmm_reqnfcb as a
   inner join zsytmm_reqnfit as b
      on a~branch_o eq b~branch_o
     and a~requi    eq b~requi
     and a~mask     eq b~mask
     for all entries in ti_doc_saida_del
   where a~docnum_ref   eq ti_doc_saida_del-docnum.
What else I need to check , so that the index improves the performance. The table is using in 300 reports.

Ravishankar Lanjewar wrote:
@SAP LEARNER,
>
> There is a Secondary index created on a Z table which already have 9 secondary
> indexes. This is the 10th index that is created.
>
>
> I will not recommand to create index any more on this table. If you want to create secondary index for on above table which you have mention. You don't create index only for hamper of performance of single program/report.
>
> Don't create more than 4 to 5 index on sinlge table.
>
> Refere the tread Link:[Why to create Secondary index ?|Re: When is a secondary index used (in select or where)]
Sounds like another myth that is widely spread across SAP community.
Remember, complex systems like modern DBMS do not like generalizations. I personally know standard SAP tables with 9 standard secondary indexes. In the meantime the hardware became fast enough to update several secondary indexes without really significant problems. Of course indexes require space, of course one should create indexes that are not similar and differ from each other with more than one field for example. In other words, think before creating!
But it's again incorrect to say "do not create because you already have 9 others". You did not even ask what fields are in the affected table, what are the existing indexes.
Ravishankar Lanjewar wrote:
> I will recommand to delete all the index and create 4 to 5 fresh index while doing analysis for all SQL statement using where use list depends on where condition of SQL.
I am now trying to imagine the effort to analyze 300 reports using this table and all corresponding selects. And probably you will drop supporting indexes for several reports. Some of them may be CEO/CFO-relevant reports that will run minutes/hours instead of seconds. And I would like to see the reaction of CEO when he finds out that it was the result of your "optimization" activities.

Secondary Index with or without MANDT field

Similar Messages

Maybe you are looking for