Cube compression issue

Hello Gurus,
we have some strange behaviours with cube compression.
All requests are compressed, but in F table we still have some records.
The same records are stored in E table too, but with BEx query execution we can see correct result.
If we execute query in debug on RSRT, with SQL code display, the query reads only from F table or aggregates.
How it is possible?
We just provide to insert the COMPNOMERGE object in RSADMIN table, but only after the first compression. Do you think thath with a initialization of cube and a new compression with COMPNOMERGE object could solve our problem?
Could you help us?
Thanks in advance.
Regards.

Vito Savalli wrote:>
> Hi Lars, thanks for your support.
> We don't have an open support message for this issue, but if it will be necessary, we will open it.
>
> I - The same records are stored in E table too, but with BEx query execution we can see correct result.
> You - The first part of this sentence is technically impossible. At least the request ID must be different in F- and E-fact table.
>
> Ok for the request ID, I know it. But, if we don't consider request ID (of course isn't equal) and we check the characteristics values by SID analysis, we find the same complete key both in F and in E table.
>
Well, but that's the whole point - the request ID!
That's why we do compression for at all - to merge together the data for the same key figures if they exist in both tables.
It's completely normal to have this situation.
> I - If we execute query in debug on RSRT, with SQL code display, the query reads only from F table or aggregates. How it is possible?
> You - Easy - you're statement about all requests being compressed is not true and/or it reads the necessary data from the aggregates.
>
> I executed with RSRT one of record which is in both tables.
Well, obviously there was some other implicit restriction that lead to the selections made by OLAP.
Maybe the request read from the F-Facttable was neither rolled up nor compressed.
> Very helpful, thanks.
> Any others suggestions?
I'd check exactly the status of the requests and where they can be read from.
You may also try out to disable the aggregate usage in RSRT to see whether or not the data is also read from the E-facttable and check the result of the query.
regards,
Lars

Similar Messages

  • Cube compression will affect any data availability

    Hi,
    have an issue where I have a user running exactly the same report with the same selection criteria but getting different results.
    The report was run from backlog this morning at 09:56 and again at 10:23. Although the batch was delayed, the data was actually loaded prior to 09:45. However, there was a cube compress running between 09:45 and 10:11.
    So, the first report was run during the compress, the second after the compress was complete.
    Could the compress process affect data availability to the end users? I can find no other explanation for this behaviour.
    Thanks,
    R Reddy

    Hi,
    one thing in advance: The next only applies to oracle databases. I have no experience with other databases.
    the compression will usually not affect the reported data. But in case of the user doing the reporting while the compression is ongoing, it is indeed possible that the query will deliver wrong results. The reason is, that the collapsing collects the data of the not yet collapsed infopackages into the F table. The query will usually start parallel processes on all the available infopackage E tables and on the F fact table. Because of the amount of data F- table is larger, so the job there will be the longest running. After collecting the results, the results are added up.
    Depending on the timing of the collapse run and the timing of the query it is possible that the collapsed data package was already successfully packed in the fact table, but the deletion of the infopackage was not completed (result: Key figures to high). Or alternativly the infopackage was already deleted but the F-table not completly commited - because of the query (result Key figures to low).
    All in all I would strongly recommend to do collapsing at times where no query is run on the cube.
    Kind regards,
    Jürgen

  • Cube compression and DB Statistics

    Hi,
       I am going to run Cube compressions on a number of my cubes and was wondering few facts about DB Statistics. Like:
    1) How does the % of Info Cube space used for DB stats helps.  I know that the more % we use the bigger is the stat and faster is the access but stats run longer.  But would increasing the default value of 10% make any difference or overall performance improvements.
    2) I will compress the cubes on a weekly basis and most of them will have around one request per day so will probably compress 7 requests for each cube.  So it is advisable to run stats also on a weekly basis or can it be run on bi-weekly or monthly basis? and what factors does it depend on?
    Thanks.  I think we can have a good discussion on these apart from points.

    What DB are we talking about?
    Oracle provides so many options on when and how to collect statistics, even allowing Oracle itself to make the decisions.
    At any rate - no point in collecting statistics more than weekly if you are only going to compress weekly.  Is your polan to compress all the requests when you run, or are you going to leave the most recent Reqs uncompressed in case you need to back out a Req for some reason.  We compress weekly, but only Reqs that are more 14 days old so we can back out a Req if there is a data issue.
    As far as sampling percent, 10% is good, and I definitely would not go below 5% on very large tables.  My experience has been that sampling at less than 5% results in useful indices don't get selected.  I have never seen a recommendation below 5% in any data warehouse info I have seen.
    Are you running the statistics on the InfoCube by using the performance table option or process chain?  I can not speak to the process chain statistics aproach, but I imagine it is similar, but I know when you run the statistics collection from performance tab, it not only collects the stats on the fact and dimension tables, but it also gos after all the master data tables for every InfoObject in the cube. That can cause some long run times.

  • Cube compression before Change run

    Hello,
    This might sound foolish, but I need to be sure...
    Does anyone know if there's any implication if cube compression runs before attribute change run?
    Thank you.

    I don't think so either but I wanted to check if anyone experienced any issues arising from that sequence of execution. This cube contains a lot of data and I just want to be sure before proceeding.

  • Effect of Cube Compression on BIA index's

    What effect does cube compression have on a BIA index?
    Also does SAP recommend rebuilding indexes on some periodic basis and also can we automate index deletes and rebuild processes for a specific cube using the standard process chain variants or programs?
    Thank you

    <b>Compression:</b> DB statistics and DB indexes for the InfoCubes are less relevant once you use the BI Accelerator.
    In the standard case, you could even completely forgo these processes. But please note the following aspects:
    Compression is still necessary for inventory InfoCubes, for InfoCubes with a significant number of cancellation requests (i.e. high compression rate), and for InfoCubes with a high number of partitions in the F-table. Note that compression requires DB statistics and DB indexes (P-index).
    DB statistics and DB indexes are not used for reporting on BIA-enabled InfoCubes. However for roll-up and change run, we recommend the P-index (package) on the F-fact table.
    Furthermore: up-to-date DB statistics and (some) DB indexes are necessary in the following cases:
    a)data mart (for mass data extraction, BIA is not used)
    b)real-time InfoProvider (with most-recent queries)
    Note also that you need compressed and indexed InfoCubes with up-to-date statistics whenever you switch off the BI accelerator index.
    Hope it Helps
    Chetan
    @CP..

  • GZIP Compression Issue in Weblogic 8.1

    Has anyone experienced issues with gzip compression filtering in 8.1?
    After about 2 months of dev. and testing with the filter, a bug has been found
    in our portal, and I have traced it back to the filter that I downloaded from
    dev2dev code and utilities.
    It is strange. The only time I see an issue is when a user clicks the "back button"
    in the browser itself to go back to a previous page, AND then clicks a link (for
    example) in a portlet that is tied to an action in a jpf for that portlet. The
    error only happens for actions in a portlet that are local to that portlet (no
    forwarding to other portlets or anything fancy)...just pure "local internal forwards."
    If you do this, USING THE BACK BUTTON to get back to this page with the portlet,
    when you click the action, you are actually taken to the page where you were when
    you clicked the back button.
    I have re-created this is simple portals that have no content, so I know it is
    not something else I introduced.
    Any ideas? Maybe it is the filter-mapping pattern I am using??? I am currently
    mapping on *.portal, but this is the only situation that seems to break.

    For those interested, I have some updates on this subject and someone out there sent me a mail asking if I ever found anything out.
    Basically, when I encountered this issue the first time, I was working on a SP2 Portal. We were having numerous small bugs like this one with SP2 that centered around the back button or refresh button. BEA gave us a "super patch" back in July or so that when applied to our SP2 project, fixed our issue. I have sense moved onto SP3, and I did not see the compression issue (so I think SP3 must have the patches correctly setup...like I would assume it would).

  • Cube Compression - How it Affects Loading With Delete Overlapping Request

    Hi guys,
    Good day to all !!!
    Our scenario is that we have a process chain that loads a data to infocube and that has delete overlapping step. I just want to ask how does the cube compression affects the loading with delete overlapping request. Is there any conflict/error that will raise? Kindly advice.
    Marshanlou

    Hi,
    In the scenario you have mentioned:
    First the info cube would be loaded.
    Next when it goes to the step i.e delete overlapping request:  in this particular step, it checks if the request is overlapping (with the same date or accd to the overlapping condition defined in the infopackage, if the data has been loaded). 
    If the request is overlapping, then only it deletes the request. Otherwise, no action would be taken.  In this way,it checks that data is not loaded twice resulting in duplicasy.
    It has nothing to do with compression and in no way affect compression/loading. 
    Sasi

  • Basic cube compression

    Hi colleagues:
    I have started a basic cube compression. Considering there are lots of delta load requisitions, the entire process will take more than 30 hours.
    However I need to run the process chain to load delta in others data providers and also in the same basic cube that has being compressed.
    <b>May I run the delta loads in parallel to the compression process?</b>
    Best regards
    Waldemar

    I think Jkyle has probably identified the biggest concern.
    This is a good example of why you should break up large processes into smaller pieces - I can't imagine a requirement to compress everything at once on a large InfoCube.
    Always process manageable chunks of data whenever possible and benchmark before running larger processes, that way you can minimize:
    - impacts to system availability.
    - impact to system resources of large jobs.

  • 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.

  • Cube Compression & Process Chains

    Hello Friends
    Few Questions as I am a beginner.
    1) What is the entire concept behind Cube Compression. Why is it preferred for Delta uploads and not for full uploads.
    2) What do we mean by deleting and creating indexes using process chains.
    3) What is meant by the process chain "DB Statistics Refresh"? why do we need it.
    Any help is appreciated. Points will be generously assigned.
    Thanks and Regards
    Rishi

    Hello Rishi,
    As you may know, an InfoCube consists of fact tables and dimension tables. The fact table hold all key figures and the corresponding dimension keys, the dimension tables refer from dimension keys to InfoObject values.
    Now, there is not only one fact table but two - the F table and the E table. The difference from a technical point of view is just one InfoObject: 0REQID, the request number. This InfoObject is missing in the E table. As a result, different records in the F table could be aggregated to one record in the E table if they have the same key and were loaded by different requests.
    As you may know, you can delete any request from an InfoCube by selecting the request number. And here is the disadvantage of the E table. As there is no request number you cannot delete a request from this table.
    When data is loaded into an InfoCube it is stored in the F table. By compressing the InfoCube records are transmitted into the E table. Because of the disadvantage of the E table it can be defined per InfoCube if and when data has to be transmitted.
    More information can be found here: http://help.sap.com/saphelp_nw70/helpdata/en/ca/aa6437e7a4080ee10000009b38f842/frameset.htm
    An index is a database mechanism to accelerate the access to single records within a table. In BW indexes are used to increase the reporting speed.
    Whenever data in a table is added or deleted - in our case loaded - the index has to be modified. Depending on the amount of changes in the table it could be less time consumpting to delete the index, load without an existing index and to rebuild the index afterwards. This can be done in process chains.
    DB Statistics is something special for an Oracle database. As far as I know (I do not work with Oracle) it is used to optimize SQL commands which are needed for BW reports.
    I hope that these explanations are helpful.
    Kind regards,
    Stefan

  • Cube compression and partition related ?

    Hello BW Experts,
    Is it only possible to partition the cube after the cube compression. that means can we only parition the E table and not the F table.?
    Thanks,
    BWer

    InfoCube Partitioning is not supported by all DBs that BW runs on - the option is greyed out for DBs that do not support it.
    You can partition on 0FISCPER or 0CALMONTH, although if you have a need to partition on someting else it might be worth a customer message to SAP.  You should review any proposed partitioning scheme with your DBA in you are not familiar with the concepts and DB implications.
    The E fact table is what gets partitioned using this option.  The F fact table would already be partitioned by Req ID.   In 3.x, the partitioning you specify for the InfoCube is also applied to any aggregate E tables that get created if the partitioning characteristics (0FISCPER/0CALMONTH) is in that aggregate.  In NW2004s, you will have a choice whether you want the partitioning to apply to the aggregate or not.
    NW2004s also provides some additional partiion tools, e.g. the ability to change the partitioning.

  • Cube compression process chain creating

    Hi,
    I want to create Cube compression process chain so that it will automate the process to compress the cube.
    Could any please provide me the steps to create Process chain to automate the cube compression.
    Regards,
    Prem.
    Please search the forum
    Edited by: Pravender on Aug 27, 2010 11:54 AM

    Hi,
    You can modify ur process chain in RSPC.
    Get into change mode in planning view and in the left side check for the different process where you can find the Compression process.
    Drag the same to right section and create a variant for the same and give the cube name. Once done then you can put the same after the cube load process (If roll up is there then it shud be after rollup if not then cube load process).
    Once all changes are done then, activate it and collect the same in transport to move the changes to next level.
    Hope this helps.
    Murali

  • Cube Compression Problem

    In the middle of a cube compression that was running in the background, the job short dumped.
    I know why the job short dumped.  It was due an invalid SQL statement, presumably because I tried to compress too many requests.
    Problem is that the requests that I asked to be compressed in the cube are marked as "compressed".    How do I "uncheck" those requests that I know are not compressed?

    Wardell,
    Requests get compressed one by one when you compress requests - hence if you are compressing 10 requests then it starts from request 1. If the job ends halfway then the requests that have been compressed till then stay compressed. It does not mean that the request has an incorrect compression status. If the request was getting compressed / scheduled for compression - you will get a clock icon against the request.
    Also to double check - you refresh the screen and go to the collapse tab and see if the release button is not greyed out.
    And go back to RSA1 and refresh tree and then go back to the manage tab and see the status.

  • Gzip compression issues from using a proxy?

    Hello I am unable to load some websites now from suspected gzip compression issues? I have been using a proxy and now my firefox browser is messed up Plz Help [email protected]
    Thanks

    It is possible to autenticate to a proxy server, but the question is what tye of authentication your proxy is carrying out . "Basic" or "digest".If it is Basic then you can use Base64 authentication scheme. You have to first set the System property variable to find proxy server (like port and IP Address)

  • Cube Compression : How do I solve the issue

    Hello,
    I had 4 requests (21 million records)  in a cube to be compressed. The compression process started and successfully loaded the data into the E table of the cube and compression flag got checked into the cube. So I saw the records are successfully compressed.
    However when it was doing the next step , that is to  delete records from the F table , the server re-booted and SAP rollback the deletion from the F table.
    Question : How do I delete records from the F table. There are current 21 million records lying in Fact table for no reason. If retry to compress the request SAP gives an message request already compress.
    I tried loading one more request and compressing the requesting , however the program just delete records from F table for current loads and not previous loads.
    Please help.
    thanks,
    -HAri

    From the FAQ Note on Compression - 407260
    2. The data should never become inconsistent by running a compression. Even if you stop the process manually a consistent state should be reaches. But it depends on the phase in which the compression was when it was canceled whether the requests (or at least some of them) are compressed or whether the changes are rolled back. The compression of a single request can be diveded into 2 main phases.
    a) In the first phase the following actions are executed:
                   Insert or update every row of the request, that should be compressed into the E-facttable
                   Delete the entry for the corresponding request out of the package dimension of the cube
                   Change the 'compr-dual'-flag in the table rsmdatastate
                   Finally a COMMIT is is executed.
    b) In the second phase the remaining data in the F-facttable is deleted. This is either done by a 'DROP PARTITION' or by a 'DELETE'. As this data is not accessible in queries (the entry of package dimension is deleted) it does not matter if this phase is terminated.
                   Concluding this:
                   If the process is terminated while the compression of a request is in phase (a), the data is rolled back, but if the compression is terminated in phase (b) no rollback is executed. The only problem here is, that the f-facttable might contain unusable data. This data can be deleted with the function module RSCDS_DEL_OLD_REQUESTS. For running this function module you only have to enter the name of the infocube. If you want you can also specify the dimension id of the request you want to delete (if you know this ID); if no ID is specified the module deletes all the entries without a corresponding entry in the package-dimension.
                           If you are compressing several requests in a single run and the process breaks during the compression of the request x all smaller requests are committed and so only the request x is handled as described above.

Maybe you are looking for