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.

Similar Messages

Cube Compression and InfoSpoke Delta

Dear Experts,
I submitted a message ("InfoSpoke Delta Mechanism") the other day regarding a problem I am having with running an InfoSpoke as a delta against a cube and didn't receive an answer that would fix the problem. Since that time I have been told that we COMPRESS the data in the cube after it is loaded. It is after the compression that I have been trying to run the delta InfoSpoke. As explained earlier there have been 18 loads to a cube since the initial (Full) run of the InfoSpoke. I am now trying to run the InfoSpoke in Delta mode and get the "There is no new data" message. Could the compression of the cube be causing the problem with the "There is no new data" message that appears when I try to run the InfoSpoke after the cube load and compression? If someone could explain what happens in a compression also this would be helpful.
Your help is greatly appreciated.
Thank you,
Dave

You need uncompressed requests to feed your deltas. Infocube deltas uses request ids. Compressed requests cannot be used since the request ids are set to zero.
You need to resequence the events.
1. Load into infocube.
2. Run infospoke delta to extract delta requests.
3. Compress.

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 and request's id

Can we decompress compressed cube using the request id's?
What happens to the request id's when the cube gets compressed?
rgds

Hi Nitin,
when you load data into the InfoCube, entire requests can be inserted at the same time.
Each of these requests has its own request ID, which is included in the fact table in the packet dimension. This makes it possible to pay particular attention to individual requests. One advantage of the request ID concept is that you can subsequently delete complete requests from the InfoCube.
However, the request ID concept can also cause the same data record (all characteristics agree, with the exception of the request ID) to appear more than once in the fact table. This unnecessarily increases the volume of data, and reduces performance in Reporting, as the system has to aggregate using the request ID every time you execute a query.
Using compressing, you can eliminate these disadvantages, and bring data from different requests together into one single request (request ID 0).
This function is critical, as the compressed data can no longer be deleted from the InfoCube using its request IDs.
Hope now is clearer (and don't forget to assign some points by clickin'on the star to the contributors that helped you !!!)
Bye,
Roberto

Cube Compression and Aggregation

Hello BW Gurus,
Can I first compress my infocube data and load data into the aggregates.
The reason being, that when the infocube is compressed the Request Id's are removed.
Are the Request Id's necessary for data to be transfered to the Aggregates and then later on for aggregate compression.
Kindly suggest.
regards,
TR PRADEEP

Hi,
just to clarify this:
1) you can compress your infocube and then INITIALLY fill the aggregates. The Request information is then no longer needed.
2) But you can NOT compress requests in your infocube, when your aggregates are already filled and these requests are not yet "rolled up" into the aggregates (this action is prohibited anyway by the system).
Hope this helps,
Klaus

Compress and rollup the cube

Hi Experts,
do we have to compress and then rollup the aggregates? what whappends if we rollup before compression of the cube
Raj

Hi,
The data can be rolled up to the aggregate based upon the request. So once the data is loaded, the request is rolled up to aggregate to fill up with new data. upon compression the request will not be available.
whenever you load the data,you do Rollup to fill in all the relevent Aggregates
When you compress the data all request ID s will be dropped
so when you Compress the cube,"COMPRESS AFTER ROLLUP" option ensures that all the data is rolledup into aggrgates before doing the compression.
hope this helps
Regards,
Haritha.
Edited by: Haritha Molaka on Aug 7, 2009 8:48 AM

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

Compression and Index

Hi BW Experts,
I deleted Indexes before loading the data.
Then I compressed the request without Creating the Indexes.
It is taking so much time to compress.
Is this the right procedure? Will it take too long to compress after deleting the index?
Thanks in advance.
Regards,
Anjali

hi anjali
Deletion of indexes , creation of index and then compression is the general procedure
if u r doing a data load in Cube then only its worth deleting and creating index,
As far as I know, for compression there is no significance of index operation as a separate E table will be generated as a result of compression whereas index works with F table only
if u r doing cube load followed by compression then standard steps are as below:
1.Delete cube contents (depends on yr req)
2.Delete index
3. load cube data
4.Compression
5.DB Statistics (u could skip this step if no performance issue)
6.Create Index
Very best method is not include the compression method in the Process chain. Because once the compression is done there is no possiblity to delete the data by requestwise. This may require if there is any error in data extraction.
Drop the index during data extraction because this may cause the performance problem during data loading.
Edited by: Amar on Oct 14, 2008 11:10 AM

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

Inventory cube compression

Hi
We are live with Inventory cube filling and delta of material movements, for past 1 year, However we had not automated compression of cube with marker update, What are the steps to automate rollup & compression of inventory cube, is this recommended as a standard practice?.

Dear Anil
I have followed the same procedure
i.e.
BX-init: Compression with marker update
BF-init: Compression without marker update
UM-init: Compression without marker update
BF-delta loads: Compression with marker update
UM-delta loads: Compression with marker update
But surprisingly the values are not reflecting correctly
Thanks & Regards
Daniel

Reporting on old and new statistics data

Hello,
I have an upgraded system from 3.5 to BI 7.o version, and i have installed the Admin cockpit for statistics content.
Also in 3.5 version we have created Z* reports based on the multiprovider.
After upgrade it is not possible to get data from RSDDSTAT because it is obsolete and we can get data from new tables.
Now i want report based on the old statistics content as well as with new content.
How can i report based on old data and new data?
Please help me with valuable inputs.
Thanks in Advance.
Regards
M.A
Edited by: M.A on May 3, 2010 12:31 PM
Please give me suggestion how we can report based on old and new statistics data..

Hello Anand,
Thanks for the response.
My requierment is I have my 3.5 statistics data in my info cube (0BWTC_C01 till C05). Now the system upgrade is done.
Now my report has to show me the statistics of 3.5 and BI 7.0 data together. Is it possible to create multiprovider based on 3.5 statistics content cube and BI 7.0 statistics cube?
Thanks,
Regards
M.A

Request mechanism to retrieve usage and performance statistics in BPC?

Hi BPC Gurus,
We have just completed rolling out BPC 5.1 and were interested in monitoring the health & user adoption (e.g. number of users logged in, how many times they logged in, what kind of reports they ran, how long the EVDRE query for those reports took etc).
I have scoured through all the available tables for the Appset & the audit database at the SQLServer level and could not find any table that holds information around this. The only information I found was around the logged in statistics for Administrators via table tblLoggedIn and the statistics of who keyed in data using Input templates via the audit tables.
Is there some roundabout way to get this information at least something to the tune of who logged in and when?
On the BW side, there is a rich set of information through the use of pre-delivered Statistics cube that provides myriad details which can be used to monitor the health and usage of the system. Are there plans to include this kind of statistical information in BPC 7.0?
Your help and guidance would be greatly appreciated.
Thanks,
Abhay Shanbhag

Yes, BPC 7.0 has a statistics mechanism.

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

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

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

Similar Messages

Maybe you are looking for