Question:
hi all,
between Basic Cubes and Multi Providers , which is better for Reporting ?
( considering all the aspects..)
Please take time to explain and be descriptive
Thankyou all
Atulam
Answer:
Basic Cube.
Answer:
Was told MultiProviders has better performance by a person who has 3 and half years exp in BW.(think people make mistakes)...
so is the Question.
thanx again..
Answer:
A multi provider will never work faster than a basic cube which has aggregates and partitioned and/or compressed fact.
Now .... sometimes you have to use a multicube ..... (design issues)
So its really in context of what you are planning to do ....
Its like saying what will kill a man effectly - a gun or a axe.
you will still achieve you goal using any one .....
get the picture ....
Answer:
Rubbish!
A multicube doesn't actually do anything except send the query to the multiple basic cubes and execute them in parallel, then collect the data and report. The query sent to the basic cubes does use the aggregates etc.
Generally reporting on a multicube will be faster since query is running in parallel on the basic cubes.
Answer:
There are several documents in SDN about this. one is called "Efficient Usage of BW InfoProviders" (pdf), other is called "Performance tuning for SAP BW" (doc), other "Accelerating Reporting Performance" (ppt). These are the ones I recall useful.
Leandro
Answer:
Wait a minute guys .... not so fast ...
Multicube performance really depends on the joins you have made.
Now if you take the same cube and split it in several cubes and then use a multicube ..... yes your query performance will be better .....
In alll other cases the answer will be no. (again depends on your join condition i.e if you use a navigational attrib in a join.)
Again if your the data set returned is not the same from each query then bring the data together is not done effitiently.
it also depends on your join conditions if the basic cube aggregates are used or not.
Please consider all these conditions ....
Now every thing also depends on the volume of data you are dealing with. A few million does not really make a difference but when you reach 50 million + you will be talking a very different story.
Now if you compress and partition your fact ... you will also have parallel queries running on each partition or run on aggregates alrady built.
Again every thing is based on the context of the question.
it really comes down to your design and types of reports you run.
Answer:
in my experience not_yet_a_bw_guru pretty much is right on the mark. (the axe is much more fun)
the real big deal about performance with multiproviders is a now and then situation. when the multicube first came out the performance was horrible; now the multiprovider allows a certain level of parallel processing so the performance doesn't suck.
the multiprovider is a great additon to the feature R BW product tool set, as are cubes, ODS's, master data infoproviders, infosets, infospokes, aggregates, RRI, extracton cockpits, ABAP, value sets, prequeries, cell references, etc. but good design and successful implementation is based on thorough understanding of ALL aspects of the tool and using what makes sense to solve the problem. (i don't think XML is included in that list because XML is for weenies)
_________________
when in danger or in doubt, run in circles, scream and shout.
Answer:
Further Information
Excerpt from note 607164
During parallel processing of MultiProvider queries, subprocesses that process the partial accesses to the InfoProviders in the MultiProvider are separated from a parent process.The parent process provides a synchronization point where the overall result is collected.In contrast to sequential processing, which permits partial results to reach the OLAP processor, parallel processing requires that the overall result be first collected at the synchronization point.
To avoid an overflow of the process memory at this point in time, parallel processing is cancelled as soon as the overall result collected contains 30000 rows or more.The MultiProvider query is then re-started automatically and processed sequentially.
This strategy explains why sequential processing appears to be faster than parallel processing in the case of queries like these:What appears to be parallel processing corresponds to sequential processing plus the preceding phase of parallel processing up to the termination.
How can I recognize the queries that are affected?
MultiProviders for which BW statistics for queries are created can be found if you search in table RSDDSTAT in transaction SE16 for queries for which the value of the QDBTRANS column accepts values of 30000 or higher.Note that not all queries listed in RSDDSTAT with QDBTRANS >= 3000 are affected, but rather only those that are defined on a MultiProvider (therefore no queries on InfoCubes, ODS objects, and so on).
As of BW 3.0B Support Package 12 (corresponds to BW 3.10 Support Package 6), you can execute the query using transaction RSRT, "execute + debug" ("run + debug") and the "MultiProvider Explain" option (see note 489135).Message DBMAN 146 then indicates that parallel processing was cancelled and restarted with sequential processing when the query was executed.
Answer:
Aditionally, I have recently used this debug option to troubleshoot a Multiprovider design issue. It does a pretty decent job of explaining what is going on. (There is a corresponding OSS listed in the explain which tells you in more detail what each of the codes mean.)
- Stephen
_________________
As a rule I don't answer Questions in PM.
(this is not to be a d**k, but it is to allow everyone to benefit from information. Not just one person.) Ask a question in the forum and I will answer it if I can.