Cube compression WITH zero elimination option

Question

We have tested turning on the switch to perform "zero elimination" when a cube is compressed.  We have tested this with an older cube with lots of data in E table already, and also a new cube with the first compression.  In both cases, at the oracle level we still found records where all of the key figures = zero.  To us, this option did not seem to work. What are we missing? We are on Oracle 9.2.0.7.0 and BW 3.5 SP 17
Thanks, Peggy

Answer 1

Haven't looked at ZERO Elimination in detail in the latest releases to see if there have been changes, but here's my understanding based on the last time I dug into it -
When you run compression with zero elimination, the process first excluded any individual F fact table rows with all KFs = 0, then if any of the summarized F fact table rows had all KF  = 0, that row was excluded ( you could have two facts with amounts that net to 0 in the same request or different requests where all other Dims IDs are equal) and not written to the E fact table.  Then if an E fact table row was updated as a result of a new F fact table row being being merged in, the process checked to see if the updated row had all KF values = 0, and if so, deleted that updated row from the E fact table.
I don't beleive the compression process has ever gone thru and read all existing E fact table rows and deleted ones where all KFs = 0. 
Hope that made sense.  We use Oracle, and it is possible that SAP has done some things differently on different DBs.  Its also possible, that the fiddling SAP had done over that last few years trying to use Oracle's MERGE functionality at different SP levels comes into play.
Suggestions -
I'm assuming that teh E fact table holds a significant percentage of rows have all KFs = 0.  If it doesn't, it's not worth pursuing.
Contact SAP, perhaps they have a standalone pgm that deletes E fact table rows where all KFs = 0.  It could be a nice tool to have.
If they don't have one, consider writing your own pgm that deletes the rows in question.  You'll need to keep downstream impacts in mind, e.g. aggregates (would need to be refilled - probably not a big deal), and InfoProviders that receive data from this cube.
Another option would be to clone the cube, datamart the data to the new cube.  Once in the new cube, compress with zero elimination - this should get rid of all your 0 KF rows.  Then delete the contents of the original cube and datamart the cloned cube data back to the original cube. 
You might be able to accomplish this same process by datamarting the orig cube's data to itself which might save some hoop jumping. Then you would have to run a selective deletion to get rid of the orig data, or perhaps if the datamarted data went thru the PSA, you could just delete all the orig data from the cube, then load datamarted data from the PSA.  Once the new request is loaded, compress with zero elimination.
Now if you happen to have built all your reporting on the this cube to be from a MultiProvider on teh cube rather than directly form the this cube, you could just create anew cube, export the data to it, then swap the old and new cubes in the MultiProvider.  This is one of the benefits of always using a MultiProvider on top of a cube for reporting (an SAP and consultant recommended practice) - you can literally swap underlying cubes with no impact to the user base.