can I drop P-index of E-fact table after compression?

[former_member245939]

Hi, experts!

Maybe this question has been asked a lot of times, but I could not find the appropriate answer.

After an infocube has been compressed, its DB size increased in 2 times!

The reason is that the huge P-index was created. This index occupies the same DB space as the E-fact table! So P-index and E-table together are twice bigger than F-table was...

We have a lot of uncompressed infocube data in BW. So I am afraid of compressing it, because DB space is small.

Please explain me:

1) why this P-index is so huge?

2) can I drop it after compression has finished? is there any negative effects?

Thanks in advance.

[Former Member · Accepted solution]

Hi Sergey,

1) why this P-index is so huge?

P-index is a B-tree index, where as the primary cube index are bitmap , you can search the difference between these two for better understanding.

2) can I drop it after compression has finished? is there any negative effects?

Index on E-fact are necessary when compressing request(s) [ in case you drop them , then you have to regenerate for this reason]  see note : 407260 for more info on this

[former_member245939 · Accepted solution]

Hi Jyothi,

thanks for quick reply!

Am I right: P-index is necessary ONLY when compressing? Reporting does not use it?

If i am right, is there any tools where I can for example drop P-index after each compression automatically?

I suppose it is not normal condition, that an infocube after compression takes 2 times bigger DB place than before it...

I have not found any information from SAP concerning so large compression space costs.

Maybe there is SAP note on this issue? Note 407260 does not describe such space issue.

[Former Member · Accepted solution]

Hi Sergey,

Am I right: P-index is necessary ONLY when compressing? Reporting does not use it?

yes, you are right .

If i am right, is there any tools where I can for example drop P-index after each compression automatically?

you can create a program by calling FM to drop it RSDU_INFOCUBE_INDEXES_DROP (with parameters E fact table) and call this program in process chain after compression.

Similar create another program by calling the FM RSDU_INFOCUBE_INDEXES_REPAIR(with same E fact table) and call this in Process chain before doing compression (as P index is necessary )

and I am not sure about note that explains DB space issue after compression.

[former_member245939 · Accepted solution]

Thank you for these FMs, Jyothi! I'll keep in mind them.

As I checked, there is a possibility to send only P-index as a parameter in FM.

So P-index deletion won't damage another indexes and reporting.

One question does not allow me to calm down why there is such a few information can be found on space issue as a result of infocube compression. And I think not enough attention is paid to it... Moreover it can be solved easily with these FMs in process chain. But this problem is not on the surface, it can be found only in DB tables analysis with t-codes like SE14, DB02 for basis team, which are basically not permitted for developers in Production.

[Former Member · Accepted solution]

Hi Sergey,

as long as you are passing the P-index as a parameter, it wont disturb primary index( as primary index creation and deletion are done separately in process chain).

and to answer your interesting question, from my two cents, compression's are seen majorly in a huge advantage factor , take example of standard inventory cube? non-cumulative key figure should be compressed as they calculated on the fly. Not only this , any other cube for the matter when the F fact table is too high, compression reduces the records from F fact table which improves query performance.  Hope it helps! .. thanks

[Former Member]

Hi,

Question 2 : You can drop your P index after compression as this is related to the F table.

How ever the P index is required for the compression and will be used during the compression.

Pl refer sap note 407260.

thanks,

-j

[former_member245939]

Hi Jugal,

how P index is related to F table? If I drop P index and later create it before compression, this relation will remain consistent? Can any compression problems appear then?

[Former Member]

Hi Sergey,

Please refer the sap note mentioned above. You can also check this relation in SE11 /14.

If the P index is created before the compression it should not give any issue. Just make sure that this index is there (also statistics are updated) before the compression . Please refer the suggestion from Jyothi above how to do it.

Thanks.

-J