Hello ABAPers, a simple yet useful questions which I have been asked in many interviews having close to 4 yrs of experience in ABAP"How you will determine the fields to be used for creating secondary index if primary index is of no use for query?Even if SQL trace will be used for it then which factor will let you decide to choose specific field to be used??"

>You should consider the factor that SELECT statement is performing really poor and HINTS also are of no use apparently, then you should see the execution plan in ST05 and accordingly judge how to proceed for secondary index, usually fields in WHERE clause are the part of secondary index, in some cases you have index but its not hit then you can modify SELECT statement to manipulate database to look for index.

>correct me if I am wrong, the fields which are more often getting used in where conditions other than primary keys can be considered as a part of secondary indexes, which I had answered many a times but still interviewer are not that satisfied and wanted to know the FACTORS which decides the basis for choosing specific fields for that..

>Not necessarily, "often getting used" but not having any impact on performance then? In LIKP, there is no index on TRAID or BOLNR, I am selecting data based on TRAID or BOLNR Only, since LIKP is a huge table and selecting from LIKP based on TRAID or BOLNR or both, without specifying any other WHERE condition which tells database to hit INDEX, in this condition I have to create a Secondary Index since no other index is useful.... keep in mind if no other index is getting hit, OR you cannot change your SELECT query in such a way so that it hit the right index ..and thus program is performing really poor and no way out..then you have to create the secondary index based on those fields.. !!>See as far as I understand about secondary index... It's basically creates a index with ur secondary keys along with primary... And then primary keys are used to fetch the relevant record.... Now which fields to be used falls to just the relevant fields... As more fields u will add it will be using combinations thereby making it less relevant for a less amount of fields.. And as for sql trace u see the time factor for fetching the same record... But the real complications will arise when you have multiple combinations of secondary fields across ur program>yeah I understand this, we usually avoid to create more than 4 secondary indexes sharing fields among them because the dB optimiser find it difficult in that case to select the relevant index to be used unless we explicitly mention the index name in where condition with %_hints syntax>1. Number of fields selected in a query has NO bearing on a Secondary Index. 2. No of fields specified in the where clause has ALL the bearing on the secondary Index. Factors determining fields of secondary Index -> 1. Fields used in the where clause2. Order of the fields specified in the S-index are ( Field 1, Field 2, Field 3) but in Where clause on Field1 and Field3 used then In S-Index is pretty much useless 3. S-Index fields must be mutually exclusive as possible 4. Data in the table should not change quite often- because indexes work on sorting 5. Primary and Foreign Keys are already indexed so adding additional index on them is no good 6. However the order may be used to create a secondary index example - if A, B and C are key elements - then A, AB, and ABC are automatically indexed, but you could and sometimes do have to create an index on B and BC etc. -- here is a link to elaborate this>