Compress the Request with Zero Elimination

I delta load the transaction data into Infocube by InfoPackage and compress the Request ID manually without select 'with Zero Elimination'. Now I wanna Compress the request ID with Zero Elimination again. Could you give me some hits on that. Many Thanks .

hi,
There're two programs that work for me.
1. RSCDS_MERGE_DUPL_REF_POINTS - this is to actually compress the records.
2. RSCDS_NULLELIM : - To remove the records with 0 value i.e. null Elimination
Although, SAP doesn't recommend using them if your compression is working fine.
You may want to try them in your non-production system first.
-RMP

Similar Messages

Differences in compressing the requests.

Hi experts,
What is the difference between compressing the request with:
No marker update ( Checked ).
No marker update ( Not checked )
Zero elimination.
And also if we fill the setup tables through mcnb ( Initialization of stock ). What exactly it mean ? ( Is it the stock which is there at the time we fill the setup tables ? ).
And also suppose if we filled the setup tables of 2lis_03_bx through mcnb today and through oli1bw we need to the fill the historical data of 2lis_03_bf .
Here what should be the date range.Is it upto yesterday? ( Bcz we have filled setup tables of bx though mcnb today ).
Please explain me in simple words.Full points will be assigned.
Regards,
Bhadri M.

Hi
Stocks are calculated using the stock marker and appliying the movements types and quantities to that marker.
If you compress cube with no marker update checked, movements compressed doesn't update the stock marker and are viewed as historic data, then after initialization the mark must be uncheckd in order to update the stock marker.
To be more precise and simple marker update Updates the stock values and NO Marker does not.
Generally BX upload has to be compressed with marker update and BF(and UM) delta init has to be compressed with NO Marker because Stock was updated with BX. And delta loads of BF and UM has to be compressed with marker update because these brings new Material movements which will has to give effect to stock.
Sorry for edition but was unable to post
Zero Elimination Explaination
Compression is nothing but moving the data from F fact table to E fact table by losing its request numbers.
For cumulative key figures(compression)
Here we have a option called zero elimination (it is applicable only for cumulative key figures). If you want to avoid the Info Cube containing entries whose key figures are zero values (in reverse posting for example) you can run a zero-elimination at the same time as the compression. In this case, the entries where all key figures are equal to 0 are deleted from the fact table.
This is permitted only for Info Cubes , where key figures with the aggregation behavior SUM appear exclusively. In particular, you are not permitted to run zero-elimination with non-cumulative values.
Thanks
Edited by: Noor Ahmed khan on Jul 30, 2008 6:55 PM
Edited by: Noor Ahmed khan on Jul 30, 2008 6:59 PM

Compression pb with zero elimination

Hi,
In a BW3.1 SP22, We compress infocube with flag with zero elimination activated.
But occurrences having key figures null and which were just compressed are not deleted.
Few properties of this cube are :
     just cumulatives KF
     huge volume (approx 120 millions occurrences / 22 millions new non-deleted occurrences with all KF null)
     huge aggregates (biggest : 20 millions)
     partitioning by month (12)
     previously few requests were compressed without the flag « zero elimination » but obviously the occurrences described as non-deleted dont come from these old requests
In the same system, on others cubes with less datas, we tried to reproduce the case without success. In all scenarii we had tested, lines with KF nulls are correctly deleted.
We dont understand from where the problem could come.
If someone has an idea ...
Thanks by advance.

So you're saying you have rows in your E fact table that were created as part of this particular compression run where all KFs = 0? That certainly doesn't sound right.
The zero elimination is a multi-step process -
first excluding rows from the F fact table where all KFs are 0, then excluding any summarized rows where all KF = 0, and then finally, deleting rows from E fact table that were updated resulting in all KFs = 0. Were any compressions run on this cube previously without zero elimination specified?
What DB?
There have been some problems with Oracle 9.2 merge function.
https://websmp201.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=613701&_NLANG=E
https://websmp201.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=639253&_NLANG=E

Compression with zero-elimination

Hi experts,
"If you want to avoid the InfoCube containing entries whose key figures are zero values (in reverse posting for example) you can run a zero-elimination at the same time as the compression. In this case, the entries, where all the key figures are equal to 0, are deleted from the fact table"
I am looking for clarification regarding the note above.
I understand that Compressing the InfoCube eliminates the duplicate records by converting all request IDs to 0 and rolling up the key figures for records that have common values for all characteristics
If I have 1 record with more than 3 KFs for example; within those 3 KFs, 2 have the value 0.
Does compression with zero-elimination with only set the request id to 0, keeping the value 0 for the 2 KFs like before compression or do we will have blank space (deleted) insteadt?
Does the zero-elimination is only possible when all KFs in the same record are equal to 0?
Thanks.

Hi Blaiso ,
Zero Elimination means deleting the record from the cube after compression if and only if, the entire key figures of the particular record is zero. If there are two key figures A & B, A = 0, B = 10, then this record will not be deleted from the cube.
So the answer to your question is if in a particular record there are 3 KF with 1 as non zero then this record will not be deleted but request ID would be deleted .
Please check the below link for complete information on compression :
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c035d300-b477-2d10-0c92-f858f7f1b575?QuickLink=index&overridelayout=true
Hope it helps .
Thanks
Kamal Mehta

Cube compression WITH zero elimination option

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

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.

Compress infocube with zero elimination

Experts, Is that true you should always check "with zero elimination" when you compress infocubes? I was reading the famous SAP doc "How to Handle Inventory Management Scenarios in BW", the screen shots for cube compression does not have that checkbox checked. Does anybody know why?
Thanks!

Hello,
Using the zero elimination the entries where all key figures are equal to zero are deleted from the fact table during compression. You don't want that in Inventory Management.
Regards,
Jorge Diogo

Compression with zero elimination (reverse postings)

I executed a compression with zero elimination in a custom InfoCube in order to avoid entries that only contain zero values as key figures (for example reverse posting) are contained in the InfoCube after compressing.
However, not all the entries where all the key figures are blank have been deleted.
This cube contains the following standard key figures:
-0DEB_CRE_DC;
-0DEB_CRE_LC;
-0DSCT_DAYS1;
There are also two other custom key figures, created as copy of 0DEB_CRE_LC.
Have you any suggestion?

So you're saying you have rows in your E fact table that were created as part of this particular compression run where all KFs = 0? That certainly doesn't sound right.
The zero elimination is a multi-step process -
first excluding rows from the F fact table where all KFs are 0, then excluding any summarized rows where all KF = 0, and then finally, deleting rows from E fact table that were updated resulting in all KFs = 0. Were any compressions run on this cube previously without zero elimination specified?
What DB?
There have been some problems with Oracle 9.2 merge function.
https://websmp201.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=613701&_NLANG=E
https://websmp201.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=639253&_NLANG=E

Unable to Compress the request of a Cube

Hi All,
I was trying to compress the cube data,At one request I got stuck. When ever I try to compress that request manually, but it is unable to compress the request and sends the following job logs
Job started
Step 001 started (program RSCOMP1, variant &0000000000190, user ID XXXXXX0006)
Performing check and potential update for status control table
No requests needing to be aggregated have been found in InfoCube 0XX_X01
Compression not necessary; no requests found for compressing
Compression not necessary; no requests found for compressing
Job finished
After further analysis, I observed the request which I am compressing , has an selective deletion.Since its is 2year old data I would like to compress the data,please suggest is it possible to compress,If the request has selective deletion.
please suggest.
Thanks & Regards,
Abdul

Hi Abdul,
Check that, if the cube that is being compressed feeds the data to a different InfoProvider, if yes then complete that laod first and then do the compression. this might be the reason sometimes. if the cube is not feeding anything currently try compressing the request again.
In some cases ,when the compression is manually performed (in the tab collapse of the cube) no compression would be done. In those cases you can try creating a process chain with only the compression step. This often solves the problem.
If both the above process don't solve your problem,
Try the SAP note :407230 (such problems occure after installing SP15.)
Regards,
Sudheer.

Does Safari use up bandwidth if I leave it running in the background with zero tabs open? Do I have to quit the application each time I am done to avoid exceeding my internet usage/host quota?

If I leave Safari running in the background with zero tabs open, does it still use up bandwidth? Do I have to quit the application each time I am done to avoid exceeding my internet usage/host quota? I'd rather not have to since quitting the application and restarting it when I need to will quickly become tedious, but if that saves me on bandwidth usage, I'll do it. Thanks!

iStat pro is another good means of checking your Mac's activity. Set it up within Dashboard. It is a free facility.
iStat pro for Mac - CNET Download.com

When do we compress the request in cube. ?

Hello all,
We have been live for a few months now. After how many days/weeks/months should we compress the request in cube. ?How often do we have to compress the data in the cube.
I know once compress than we cannot delete the data by request but we there is an issue and we need to delete data completely from the cube that is possible right ?
Thanks in advance

How often Compression needs to be done depends on the volume of data that is loaded everyday. Unless the volume of records loaded everyday is unusually high, doing compression once a week might be good enough.
Also you are right abt losing the ability to delete by request in the infocube after compressing the request. But we dont necessarily have to delete the whole cube incase of issues. There is always the option of doing 'SELECTIVE DELETION'.
Next, when doing the compression you have an option of mentioning the date range. Choose the option of compressing requests that are older than 4 days (arbitrary) to have a buffer for deleting the request incase of issues.
Hope this helps!

How to compress the requests selectively

Hi Gurus,
i have 4 requests , i would like to compress the 2dn one
if i compress 2nd request 00 to 2 request will be compressed, but i don't want like that i want compress the
2nd requet only not from 00 to 2
how can i do that ,
thanks
Anil

hi Shreya,
The latest requests are related to Inverty management i
i.e BF(goods movements) and UM(Stock revalution)
i have to compress these(BFandUM) without marker update
if i compress the requests, it will compress 00 to the latest request,
this nomarker update will effect the older request, why because they are not compressed yet.
wat i have to doo,
Anil

Credit memo request with zero net value

Hello all,
when we create a credit memo request (VA01, doc type CR) and put a material quantity into the credit memo request that falls below the scale in VK13, the net value for the material will be zero.
We do not want to allow to save the credit memo request with a zero net value, but SAP will just allow us do that.
I was wondering if there is a way to pop up a warning or even an error message that avoids saving the document in case of a zero net value?
Thanks
Anne

Hi,
You can make the condition type (for which $0.00 is not allowed) as mandatory condition type in the pricing procedure. By this way the system will give error and wont allow to proceed any further unless the data is complete. (make sure this is not affecting your regular sales order cycle).
Or if you just want to give a pop-up message then you can use user exit USEREXIT_SAVE_DOCUMENT_PREPARE in include MV45AFZZ
Regards,

Update rules deactivated after transporting cube with zero elimination on

Hello,
The update rules were deactivated in the quality system after transporting the cube with the zero elimination flag switched on. However, the update rules in development were not deactivated when setting the zero elimination flag. So, the update rules in the "From" system were not deactivated. This only happened in the "To" System. Does anyone know why?
Thanks,
Maureen

If there is any change you did on cube, you need to re-activate your update rules.
Re-activate your UR and transport it. It should be ok.
Hope it helps..

Compress the request of inventory cube 0ic_c03

Hi experts,
I want to compress the infocube 0ic_c03 daily for the delta requests through process chains.
In the process chain, process types there are 2 options:
1.Collapse only those requests that were loaded XXX days ago
2.Number of requests that you do not want to collapse
Which one i should select and how many days i need to go.
I want to the daily delta request to be compressed.
Pls guide me accordingly.
Regards,
Nishuv.

Hi,
Inventory data is non-cumulative data and we usually keep 30 days. Once compressed we cannot make any changes if there are any errors on particular day. We had problem when FICO consultants changed valuation in the systems directly and we were not aware of that. Later when values in the FICO is different in Inventory then we figured out that there were some manual changes in FICO. Luckly we didn't compress those requests. Later thru some routines we fixed the issue.
Thanks
Srikanth

Compress the requests without opening PRD client

Hello experts,
Everytime we take INIT loads into 0IC_C03, we have to compress the BX,BF & UM requests. But it is only possible after opening the PRD client.
Can anyone guide how to compress these requests without opening client? Is there any special auth. required for this?
Please reply.
All answers will be rewarded.
Regards,
Roy.

Roy,
When you open the client and compress - are you asked for any request.
What I think is happening is that there might be some tables which have entries being deleted and recreated. For deleting the entry you will have to open the client if the table is not maintainable.
As a process if no request is triggered then it is a table issue - check if you can set any namespace to modifiable and resolve this or if you are getting a request then you will have to open the client.
Arun

Compress the Request with Zero Elimination

Similar Messages

Maybe you are looking for