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

Similar Messages

Issue with new secondary index

hi i have created new secondary index in VEPO table.( mandt, werks,lgort, sonum).index is activated. but when i am doing activate and adjacent in database in SE14.it is giving warings and error.
warning 1:
Enhancement category 3 possible , but include or subty. not yet classified.
index VEPO-ZS1 must be created in the database
test activation of Table VEPO successful.
Activation and DDL statments for Table VEPO required.
warning and error:
Enhancement category 4 possible , but include or subty. not yet classified.
create UNIQUE INDEX "VEPO~ZS1' ON "VEPO" ("MANDT", "WERKS", "LGORT","SONUM")
PCTFREE 10
INITRANS 002
TABLESPACE PSAPBTABI
STORAGE ( INITIAL 0000447920 K
NEXT 0000447920 K
MINIEXTENTS 0000000001
MAXEXTENTS UNLIMITED
PCTINCREASE 0000
FREELISTS 001)
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
DDL time(___1): ...378,823 milliseconds
The SQL statement was not executed
Statements for Table VEPO could not be executed
Request for VEPO could not be executed
When i m executing below select staments its taking more time.
For below Select Statments i m using :
if not t_vbap[] is initial.
      select venum
             vbeln
             unvel
             vemng
             matnr
             lgort
             sonum
             werks
      from   vepo
      into   table t_vepo
       for all entries in t_vbap
   where matnr in s_matnr
    and   werks = p_werks
    and   lgort in s_lgort
    and   sonum = t_vbap-sonum.
    else.
      select venum
         vbeln
         unvel
         vemng
         matnr
         lgort
         sonum
         werks
from   vepo
into   table t_vepo
where matnr in s_matnr
and   werks = p_werks
and   lgort in s_lgort.
    endif.

Oracle give you the answer
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
so you cannot create a unique index with those keys, add another key (or even the whole primary keys) or remove the unique constraint. (of course in some of your environment, e.g. DEV there could be no duplicate entries for those keys, but in at least one of your environment the problem arose)
Adding an unique constraint on a SAP standard table is not a good idea, if you were successful in a young (go live) system, you could get in trouble if standard reports dump cause of this unexpected constraint. (and they will according to [Murphy's_law|http://en.wikipedia.org/wiki/Murphy%27s_law])
Regards,
Raymond

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

Creation of secondary indexes due to heavy flow of messages in ecc smq2

Hi gurus,
So we are facing smq2 issues from last 15 days in Ecc system due to some Time Limit Exceed and some times Object is Locked by the user xxxx
So finally we decided to go for creating seconday indexes in Ecc side , So here my question is there any thing required from Pi side while creating
Secondary indexes why i am asking this question is there is no issues From PI end after reaching to target(ECC) system only messages got stucking
in smq2 and facing issues .Below is the interface details.
ECC-FSCM
SAP ECC 6.0
FSCM
CreditCommitment_In and CreditCommitment_Out
CC_ProxySender_FSCM
CC_ProxyReceiver_FSCM
Plz reply back .
Regards
Madhu

If you had gone through the replies in your previous post, Iñaki Vilaand myself already provided the report name which needs to be scheduled to clear the messages in queues.
Plz provide the permanent fix for this issue

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

Creation of secondary index on RSPCPROCESSLOG table

Hello guys,
We have detected severe performance issues while executing the transaction ST03n in our BW 3.5 System.
Looking in the OSS notes we found the note "SAP Note 841324 - ST03N: poor performance for process chain profile" where it recommends the creation of a secondary index in the table RSPCPROCESSLOG with the following features:
Create another secondary index on the RSPCPROCESSLOG table with the
following fields:
- INSTANCE
- TYPE
Can you please let us know what is the step by step to proceed with the creation of this secondary index?
Thanks for your help.
Kind regards

Please ask questions about Oracle Text (formerly interMedia text) in the Oracle Text forum. You will get a quicker, more expert answer there.

Transport of secondary index on /BIC/P table

Hi All,
I have created a secondary index on '/BIC/P table and it is not allowing me to assign a transport object as the table itself is temporary and it gets created automatically in the target system when we activate the info-object.
Is there any way to transport the secondary index directly on the /BIC/P table ?
Its urgent.
Thanks
Soumya

Soumya,
Sorry for not being clear enough: you can change the package of this index and transport it but since the P table could be regenerated automatically by the BW application when you change your IObj you may now get into troubles when importing a change.
Indeed having now a local $TMP table with a non-local object underneath may not please your target system and even not your DEV system...
One can always bypass SAP BW application; for instance creating indexes directly in the database; but this is at its own risk!
hoping this will explain a bit further your issue
Olivier.

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

Q1: Secondary Index. Q2: Fiscal Year /Period

Hi gurus,
I have two questions need your explain:
Q1: To improve the query performance I am going to create some secondary indexes on an ODS, I am wondering whether this action will remove the data from the ODS therefore I have to reset the data loading process and if these indexes can be maintained while data loading automatically ?
Q2: About fiscal year /period which technical name is 0fiscper. we know in sales order header, item also purchase order and billing ODS or CUBEs, FY/Period are existed in those models. but there are still some other dates e.g. delivery date, goods issue date, goods recieve date, document date, posting date and so on. So which date is used to generate FY/Period ?
Thanks in advance
Edited by: Leon Ouyang on Dec 3, 2008 4:27 PM
Edited by: Leon Ouyang on Dec 4, 2008 1:26 AM

Hi,
1)The creation of index have no effect on the data stored and you need not delete or relaod the data.
System will adjust the index with every data load to the DSO automatically.
2)Fiscal year period depeneds upon the module from which you are using the data and you can tweak the logic for this suit your need.
If the data source is providing the fiscal period values then well and good.
If not then generally its mapped to those dates which are driving date of the query or the date which is going to be used by the user for the input selections in the report.
for example if you want sales based on the posting date in the reports and user just wnt sale till month and not date then.......you map posting date to fiscal period in the transformation and use them in the reporting.
This can vary too...there is no hard fast rule for what date it should be mapped...and it all depends upon the reporting requirement
The good design practise is to fill it with the same date which is filling calday and calmonth objects.This will keep granuarlty as same...but if you want some other selection in the report then you can map calday to some other date and fiscal period to some thing else.
Ajeet

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

Reoccuring missing secondary indexes in BI systems

Hi Gurus,
I'm been experiencing the problem of missing secondary indexes for some time, and I would like to get to the bottom of this problem.
These are a few of the missing indexes (from DB02):-
/BIC/F100294-900
/BIC/F100365-900
/BIC/F100366-900
/BIC/F100368-900
/BIC/F100369-900
/BIC/F100386-900
/BIC/FZCFIGRLP-900
/BIC/FZCGLECRD-900
/BIC/FZCGLECRD2-900
/BIC/FZCGLECRD3-900
TSP03-1
TSP03L-A
Any idea what could be causing this???
And how do I solve this problem??? And how can I prevent these from reoccuring again???
Thanks.
Cheers,
KeatSeong

I see missing indexes on DB02 as well and ran SAP_INFOCUBE_INDEXES_REPAIR and I just have a couple more questions that I think is relevant to this chain:
1) It repaired some fact indexes like /BIC/F* and dimension indexes like /BIC/D* but in the report showed as follows for those cubes:
0 ZPP_C008 : 0 secondary indexes repaired.
2) I had some other dimension indexes like /BIC/D* that did not get repaired and I'm wondering why. See 4) below for how I repaired those.
3) I ran RSRV and these missing indexes like /BIC/D* do not show up as being an issue
4) When I run RSDU_INFOCUBE_INDEXES_REPAIR on that missing index like /BIC/D* I get E_REPAIRED = 0 and system error: RSDU_INFOCUBE_INDEXES_REPA_ORA but when I refresh DB02 the index is gone. When I go to RSDU_INFOCUBE_INDEXES_REPA_ORA and run it I got e_reparied - 11
Thanks for all your help.
Mike
Edited by: Michael Hill on May 26, 2010 6:49 PM

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

Drilling down slow - Something wrong with Secondary Indexes

Hi,
I have a cube that on the whole works very well, but periodically when I drill down to some characteristics it runs extremely slowly.
The cube is in a our Test environment and is not being updated with data.
When I go to RSA1[Select Cube] Manage>Performance, the DB indexes are now green after reactivating the cube and recreating the indexes.
Yet, when I drill down to certain characteristics, I can see in SM50 the query is doing a sequential read. It looks as if the secondary index on this dimension is not doing its job or being ignored.
I have tried Checking the Cube Database Indexes in RSRV and all is okay. The Master Data in the relevant dimension all seems to be active.
Any suggestions on how to get to the bottom of this would be much appreciated.
A trace on the SQL is showing the following statement taking excessive time:
Select * from RSDCHABAS where CHABASNM = ? and OBJVERS = ?.
I'm not sure why it's getting stuck on this table and it just list of InfoObjects. It is not reading from the actual cube in this statement.
Regards
Adrian

Hi Adrian,
In BW we are while tranforming data from source system we are using this table to dump the data in table RSDCHABAS. Which is nothing but use as buffer.
Basically this issue is due to low Temporary memory available on the system. Please check Temp memory available in DB02 and send this to your basis team to clear / entend this temp memory.
This will deffinately resolve this error.
Regards,
Mahesh

The fact table of InfoCube 0OPA_C11 is missing 2 secondary indexes

Hello experts,
in RSRV i got the above mentioned message for my InfoCube 0OPA_C11. Before I tried to delete, repair and build up my indices in performance tab of the InfoCube.
I followed SAP Note '401242 - Problems with InfoCube or aggregate indexes'.
-> SAP_INFOCUBE_INDEXES_REPAIR repaired indexes and show no further problem, but problem still exists, in performance tab light is red and RSRV brings same message.
Does someone have any idea what further I can do?
Best regards,
Peter

Peter, refer to note 928037, it's FAQ about MaxDB indexes. I gave it a quick reading and I believe the answer to this issue lies beneath this doc! There are ways to check consistency of individual index, bad indexes and ways of eliminating them.
Also, refer to the below blog. Check the status of the secondary index in this case. I suspect they are bad or missing. There are ways to recreate them. Keep your basis guys in the loop.
http://wiki.sdn.sap.com/wiki/display/MaxDB/MaxDBIndex%28Secondary+Key%29
Hope this helps.
Edited by: Mann Krishna on Sep 10, 2010 3:50 PM

Loads delayed due to Indexing Issue

HI SAP GURUS ,
Please suggest correct answer as we have an issue where Deletion / Creation of Index process takes long time to complete .
Also how does the partitions in an Infocube grows & to Increase the performance what steps one should take .
Full points will be rewarded for right answers
Regards ,
Subash Balakrishnan

Hi Subash,
Firstly your question sis vrey generic. It depends that it is taking time in creating Index on DSO or InfoCube.
InfoCubes are more prone to Index creation issue than DSO, due to high number of uncompressed requests. However this also depnds on the database due to archicture:
ORACLE:
With Oracle database, If you have a cube with 1000 uncompressed requests and 10 dimensions (every dimension brings with it a local bitmap index) you have 1000 partitions for the table itself and 10 x 1000 index partitions which makes a total of 11.000 database objects. This amount of objects hurts most when updating statistics or dropping/recreating secondary indexes. In situations with a high load frequency you will most certainly run into problems in this area sooner or later.
If you do a statistics update, all these 11.000 objects will receive new statistics which will take some time and may raise locking problems during execution or at least a serialization when changing the statistics fields in the database catalog tables.
If you drop/recreate secondary indexes, all these objects must be removed or created in the database catalog which also is a serial operation and may again rise locking situations and/or long runtimes. Additionally there is lots of DB cost for returning the allocated disk space.
You will not experience trouble from this direction in the beginning, when the number of partitions is low. But you will run into problems randomly at first, when the number of partitions increase, and permanently, after the number of partitions have exceeded some (not specifiable, system and context dependent) threshold.
SQL Server:
With SQL Server 2005 onwards, there is limitation of 1000 partitions for a table. And each loaded uncompressed request in InfoCube is a partition in SQL Server. In BW System, each uncompressed requests are loaded in one partition and once 1000 partition limit has been reached in a SQL Server database, it will continue writing each new request to the 1000th partition and will write an error to the system log (SQL Error 7719). This is done only to avoid a hard failure when loading data, it is not the recommended business process that one should keep loading requests to the last partition. Continuing to load to the 1000th partition could cause a performance problem later when trying to delete requests and creating indexes and updating statistics of the InfoCube.
How to check number of partitions on the SQL server database:
Execute report RSDD_MSSQL_CUBEANALYZE
- Menu Settings => Expert mode
- Press the Details button
- Choose the number of minimum partitions (choose let say 500)
- Press the button Start Checks
This will display all the tables with more than 500 partitions in the database.
So, to avoid this index creation issue for InfoCubes, it is suggested that one should keep the less number of uncomressed requests in the InfoCube. Compress the InfoCube with the latest request whereever possible.
Hope this helps. Award points if helpful.
Regards
Tanuj

Secondary index issue

Similar Messages

Maybe you are looking for