Q: BWA Index compression issue...

[Former Member]

Hi Gurus,

We have a problem with our BWA and I would like to know if there is a good solution for it.

The basic problem is that we have an item-based cube, where we use exception aggregation for "number of headers". When a change is done to the data, we will get one row in the InfoCube with 0's only and one with the real values. Exception aggregation will then in some cases (depending on drill-down) count this header twice. This can be solved by compressing the InfoCube.

The problem with BWA is that even if we compress the infoCube, the BWA index is still not compressed, and the only solution we have found is to delete, create and fill the index again (which of course takes time and we would like to avoid doing this daily). We are not using BWA delta index for this Cube.

Has anyone experienced this before and do have any solution?

Thank you in advance,

Mikael

[jgleichmann]

Hi Mikael,

this is normal behaviour, when you change data on BW (compress data or load data) and don´t load this changed data into BWA then the size won´t change on BWA side. If you load the F-tables with the request IDs into BWA, compress the cube afterwards and delete the request IDs (compress the cube) than on BWA must be more data... Your statement "BWA index is still not compressed" isn´t true anyway, because all data inside the TREX engine is compressed in memory.

So if you change data in a cube you have to reload/recreate this data on BWA. It´s just a normal behaviour. The BWA index won´t change itself alone

Regards,

Jens

[Former Member]

Hi Jens,

Thank you for your reply. The fact that this is normal behaviour does not really solve my problem

I know that BWA data is compressed, but not in the way that InfoCube data can be compressed. It is compressed by storing the data differently, not by removing technical keys (request ids) and rows where all key figures are zero.

What I would like to do is to ensure that the BWA index will give the same "count" result as the InfoCube, i.e. basically I would like to run a compression with zero elimination of the BWA index instead of having to drop/create/fill the index daily.

Any ideas?

Best regards,

Mikael

[jgleichmann]

mhhh ok, I think there was a similar post in the past. Check [this|] one here. May be it answers your questions regarding zero elimination.

Cheers

Jens

[Former Member]

Hi Jens,

I have seen that post and the "solution" is: Check whether the query delivers correct result (which it does not if you use count). Not using the Accelerator is a solution, but I do not think end-users will appreciate it

Therefore I was hoping there was some solution other then delete/create/fill index that could ensure correct result even when using count.

Best regards,

Mikael