cancel
Showing results for 
Search instead for 
Did you mean: 

report perforence of multi-provider

Former Member
0 Kudos

Hi, experts,

we can not create aggregates on the multi-cube, thus, is multi-cube will invoke the aggregates of basic cube?

if no, how to improve the report perforence which based on multi-cube ?

Thanks in advance

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi dear!

Clearly multicube can use the underlinked aggregates of the basic cubes...

Let me know your mail or, if you have the access, go to

https://websmp204.sap-ag.de/~sapidb/011000358700009385892004E

Bye,

Roberto

Former Member
0 Kudos

Hi,

Roberto is right. If you goto rsrt in BW and run your query in debug mode, the system will show you which cubes and aggregates it is using or which aggregates on which cubes you need to create in order to get a good query performance.

regards

Siggi

Answers (1)

Answers (1)

edwin_harpino
Active Contributor
0 Kudos

hi,

there is option 'noparallel' for multi-cube/multi-provider, which according to the documentation

can only be found out by testing if access to the different MultiProviders is faster by using this NOPARALLEL option or not.

oss note 327876

Former Member
0 Kudos

Hi,

As A.H.P Mentioned the note, you have to decide according to your queries, whether parallel processing is benifictiory or Using Multi aggregates (on base cube)is benifictiory.

To find out this one, execute the queries and note the time needed for that with parallel processing and with out parallel processing.And make sure Cache is not being used for that in both cses.

With rgds,

Anil Kumar Sharma .P

Message was edited by: Anil Kumar Sharma

Former Member
0 Kudos

Generally speaking, executing in parallel will be faster. The problem is that BW under certain circumstances, cancels parallel procesing after it has been running, and restarts the query over in sequential order.

SAP BW provides an option at system, InfoProvider, or query level to suppress parallel. Why would you want to do this?

BW has a hard coded limit in the parallel processing (actually in the most recent Svc Pk or two, I believe they allow you to adjust this setting) that if your parallel query returns more than 30,000 rows to the OLAP processor, BW stops the query, and restarts it in sequential mode.

It does this to protect the Application Server memory from being completely used up on the query.

So it can seem like a query that is set to run in parallel takes longer than when it is set to run in sequential mode, because it starts to run in parallel, then cancels and restarts in sequential, whereas when set in sequential mode it just starts that way and doesn't waste time trying to run the query in parallel.

Your Early Watch report will identify queries that you should consider setting to run in sequential mode because they sometimes return more than 30,000 rows. You have to be the judge and determine what percentage of the time the user query does this. If it is all the time, then set it for sequential, but if it is only a small number of the queries that transfer more than 30,000 rows to the OLAP processor, then it is probably better left in parallel processing mode.