BSAK Table -Index Issue

[Former Member]

Hi All,

I want to access BSAK table based on following fields: BUKRS, LIFNR, ZUONR, BLART and BSCHL.

It is not having any index which fully matches with the criteria we are providing in Where clause. Hence it's using index '4' (BSAK~4) which is partly accessed.

But this is taking huge amount of time. When I checked the cost of the select statement, estimated cost was 21617 (Which is pretty high) and storage quality of this index is 87%. I think that the rebuilding index would be not help us much.

I suggested creating of secondary index but the basis team is not happy with this suggestion as this would require disk space.

So Can you please suggest what can be done or if I can access any other index?

Regards,

Pooja

[Former Member]

Hi All,

I want to access BSAK table based on following fields: BUKRS, LIFNR, ZUONR, BLART and BSCHL.

It is not having any index which fully matches with the criteria we are providing in Where clause. Hence it's using index '4' (BSAK~4) which is partly accessed.

But this is taking huge amount of time. When I checked the cost of the select statement, estimated cost was 21617 (Which is pretty high) and storage quality of this index is 87%. I think that the rebuilding index would be not help us much.

I suggested creating of secondary index but the basis team is not happy with this suggestion as this would require disk space.

So Can you please suggest what can be done or if I can access any other index?

Regards,

Pooja

[Former Member]

Hello Pooja ,

Just check whether you can restrict the number of entries being selected.

For example : Before querying BSAK , Try to add the where condition so that only the needed records can be selected.

Take Needed BUKRS and LIFNR based on some condition from other table which is related to BSAK .

only For the Retrieved BUKRS and LIFNR query your BSAK.

[Former Member]

If you are using 'into corresponding fields of table', change it to 'into table'. It improves performance.

Also for your reference...

secondary indices use disk space which is roughly width times number of records, can be GBs.

Main disadvantages are:

+ indexes are updated when table is changed, i.e. the additional index makes other operations slower. You must check the importance of your application, if it is much lower than the standard usage than you can not create a secondary index.

+ Secondary indices can confuse the database optimzer, especially if you use field which appear also in other indices. DB calculates usefulness of different indices by some assumptions (check other sources for details), if two indices are similar, than the assumptions can lead to wrong decisions. Your new index can be used for other statements, even when it is not optimal there. Result your index causes problems somewhere else!

[HermannGahm]

Hi,

>I want to access BSAK table based on following fields: BUKRS, LIFNR, ZUONR, BLART and BSCHL.

Index 0 looks better i think:

MANDT <-specified

BUKRS <-specified

LIFNR <-specified

UMSKS

UMSKZ

AUGDT

AUGBL

ZUONR <-specified (can be used as a filter only)

GJAHR

BELNR

BUZEI

Index 4 doesn't look so good:

MANDT <-specified

BUKRS <-specified

REBZG

REBZJ

REBZZ

LIFNR <-specified (can be used as a filter only)

UMSKS

REBZT

Double check your statistics. Are they reflecting the current state of the table? If in doubt, update them.

You can try to force the query to use index 0 in order to see if the run time improves.

Kind regards,

Hermann

[ravi_lanjewar]

Hi,

I am agree with harmann

Where condition select most left part of index matching fields from Where condition.

You can also used index 1 for ecc6.0 application version.

MANDT <-specified

LIFNR <-specified

BUKRS <-specified

AUGDT

AUGBL

GJAHR

BELNR

BUZEI

but you should check index 0 and index 1 trace the program, Used whichever take least time from index 0 and 1.

Rgds

Ravi Lanjewar

[Former Member]

Created the secondary index for the BSAK table as none of the other tables, fields or indexes could be used instead...