Maximum Number fields in a secondary index key

Hello All,
We created a secondary index on BSIS which we had to drop as system was hung up. My question is how many fileds SAP recommends in a secondary index key? Ours had 6 keys including mandt.
Thanks

Hi Sameer,
There is no real specification in number of fields for an index as fas as i know. Definitely 6 fields is allowed for a secondary
index.But it really matters with the number of secondary indices. So dont create too many secondary index for a single table.
Try to use other optimization techniques in the programming instead of creating secondary index.
//Kothand

Similar Messages

The maximum number of files have been indexed

Hi
I've just tried using Edge Code with a large project. Upon attempting to use Quick Edit on a class name I got the following error: "Error indexing files. The maximum number of files have been indexed. Actions that look up files in the index may function incorrectly."
After closing the pop-up window, the Quick Editor fails to work.
Are there any plans to increase the size of the index limit? I'm very impressed with the software so far, but not being able to use the quick edit function defeats the purpose of using Edge Code.
Cheers,
Roberto

Each device can only set up 3 iCloud accounts. After that, all you can do is re-use one of the accounts that has already been set up on this device, or set up a new account on a different device if you have one.

1 of the field in existing secondary index

hi,
if in the existing secondary index, among the field in the index, for example field1, field2, field3, field4;
if field3 is the only field that i need to define in the where clause in my program, do i need to create a new secondary index?
thanks

Are you executing your select clause with WHERE clause on only field 3?
If so adding your field on an existing index with 3 fields already, will not solve your purpose, if it is performance that you are looking for. You need to create a new index, if you use the select clause with only field3, in any case
That said, if you would use all field1, field2, field3, field4 in your query and the index does have only field1, field2, field4 as of now, still you should not insert field3 in the middles as all other queries dependent on previous index will now become partial key queries.
So I would suggest you to go with a new index, if the SELECT query that you are talking about is performance critical.

Maximum number of datasources for an index.

Hello,
Could someone comment on what is the maximum number of datasources allowed for an index-? Can we have 10 -15 datasources for a single index? I am not planning huge datasources ,each ds will be only a document in a FS rep.
bcause this is the only option.
Rgds

Hello Robert ,
Thanks for replying. I am not trying to index large datasources.
Each datasource would be only a single document in a FS rep.
i.e an index with about 10-15 datasources like this. I need to get this done for nearly 50 docs. Thats why I wanted to check how to split this up in a proper way.
This is a hard requirement , so no other option than to index individual docs in the repositories rather than the whole rep.So then 10 -15 datasources per index should be fine,is it?.
Currently made 6-9 data sources for an index(all docs in FS rep's), But index admin shows red and states that some document has not been indexed correctly.
There are no errors in the indexing/trex monitor.
Also search also picks up the document . Is this a known problem/bug?
Rgds

Maximum number of column in Composite Primary Key

Hi
I have read that composite primary key can contain maximum of 32 columns (Oracle 9i).
However I am able to create a primary key on 33 columns. It fails to create primary key on 34 columns. Below are the queries.
DROP TABLE XYZ;
CREATE TABLE XYZ
( N1 NUMBER
,N2 NUMBER
,N3 NUMBER
,N4 NUMBER
,N5 NUMBER
,N6 NUMBER
,N7 NUMBER
,N8 NUMBER
,N9 NUMBER
,N10 NUMBER
,N11 NUMBER
,N12 NUMBER
,N13 NUMBER
,N14 NUMBER
,N15 NUMBER
,N16 NUMBER
,N17 NUMBER
,N18 NUMBER
,N19 NUMBER
,N20 NUMBER
,N21 NUMBER
,N22 NUMBER
,N23 NUMBER
,N24 NUMBER
,N25 NUMBER
,N26 NUMBER
,N27 NUMBER
,N28 NUMBER
,N29 NUMBER
,N30 NUMBER
,N31 NUMBER
,N32 NUMBER
,N33 NUMBER
,N34 NUMBER
,N35 NUMBER
,N36 NUMBER
,N37 NUMBER
,N38 NUMBER
,N39 NUMBER
,N40 NUMBER
,N41 NUMBER
,N42 NUMBER
,N43 NUMBER
,N44 NUMBER
,N45 NUMBER
,N46 NUMBER
,N47 NUMBER
,N48 NUMBER
,N49 NUMBER
,N50 NUMBER
ALTER TABLE XYZ ADD CONSTRAINT XYZ_PK PRIMARY KEY
( N1,N2,N3,N4,N5,N6,N7,N8,N9,N10,N11,N12,N13,N14
,N15,N16,N17,N18,N19,N20,N21,N22,N23,N24,N25,N26
,N27,N28,N29,N30,N31,N32,N33,N34);
ALTER TABLE XYZ ADD CONSTRAINT XYZ_PK PRIMARY KEY
( N1,N2,N3,N4,N5,N6,N7,N8,N9,N10,N11,N12,N13,N14
,N15,N16,N17,N18,N19,N20,N21,N22,N23,N24,N25,N26
,N27,N28,N29,N30,N31,N32,N33);
Can someone let me know the lmit of maximum no. of columns in Primary Key?
Regards
Arun

SQL> select * from v$version;
BANNER
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
PL/SQL Release 9.2.0.1.0 - Production
CORE     9.2.0.1.0     Production
TNS for 32-bit Windows: Version 9.2.0.1.0 - Production
NLSRTL Version 9.2.0.1.0 - Production
SQL> ALTER TABLE XYZ ADD CONSTRAINT XYZ_PK PRIMARY KEY
2 ( N1,N2,N3,N4,N5,N6,N7,N8,N9,N10,N11,N12,N13,N14
3 ,N15,N16,N17,N18,N19,N20,N21,N22,N23,N24,N25,N26
4 ,N27,N28,N29,N30,N31,N32,N33);
Table altered.

Maximum Number of Keys

Hello, I'm doing a study on different database software and I was wondering what the maximum number of foreign, primary, and super keys that are allowed in a relational table?

This list might be one starting point for Oracle 10gr2.
The number of primary keys per table should be pretty much consistent in any rdbms;)

Maximum number of key for recno database

Hi
I have a question about Recno database.what is the maximum number that can be specified for key.can I chage maximum?
please help me
thanks
regards
saeed

Hi,
2**32
Here is a reference for more information:
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_conf/logrec.html
The maximum is not a configuration parameter so you can't change it without modifying source code.
Ron

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

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

Secondary index report

I would like to create a report that lists all secondary indexes including the columns indexed. What tables contain information on secondary indexes? Is there an FM to get information on secondary indexes?
Thanks In Advance.

Hi Brad,
The two tables you are looking for are DD12L and DD17S. Table DD12L gives you a list the seconday indexes and table DD17S gives you the list of all the fields in a secondary index.
1) Retrieve field INDEXNAME from table DD12L where SQLTAB = <Table name>.
2) Retrieve field FIELDNAME from table DD17S where SQLTAB = <Table name>
and INDEXNAME = DD12L-INDEXNAME.
This should be a simple 2 select report.
Let me know if this helps.
Regards,
Mark

Maximum Number of Indexes

Dear Guru's,
Pls let me know,maximum how many indexes we can create on a table in R/3.
Thanks

Dear Jyothi,
Visit [Managing Tables and Indexes|http://help.sap.com/saphelp_nw70/helpdata/en/29/581633f72011d2952900a0c930df15/content.htm]
Also, visit [What to Keep in Mind for Secondary Indexes|http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ea43446011d189700000e8322d00/frameset.htm]:
Creating an additional index could also have side effects on the performance. This is because an index that was used successfully for selection might not be used any longer by the optimizer if the optimizer estimates (sometimes incorrectly) that the newly created index is more selective.
The indexes on a table should therefore be as disjunct 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.
Regards,
Naveen

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

Maximum Number of Seconday index on ECC6.00

Hi all,
I tried created 22 seconday indexes for a table in ECC6.00 . This was just for testing purpose. Can anyone tell me the limit on number of seconday index on SAP table.
I searched forums before posting and found that 15 is the max limit.
Best Regards
Hari

Hi ,
There is no limit for the Secondary index, but we should be carefull not to repeat the fields ... Performnace optimizer will not identifies the correct index ...
Reagrds,
Bharani

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

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

Maximum Number fields in a secondary index key

Similar Messages

Maybe you are looking for