BW MultiProvider

Table of Contents

Introduction

SAP Online Documentation

• Creating MultiProviders
• Semantically Partitioned Objects (SPO)

What is a Multiprovider?

• A MultiProvider is a 'union' of Infoproviders, please see the simple examples below and SAP note 379736
• The MultiProvider does not itself contain any data, it comes entirely from the InfoProviders on which it is based on: InfoCube, DSO object, InfoObject, InfoSet...
• For comparison only: InfoSets are created using 'joins' (intersection)

There are 2 types of Multiprovider:

Homogeneous Multiprovider

• There are the same characteristics and key figures in all participating Infoproviders.
  • Example: Multiprovider with identical Infocubes
    • Infocube 1: data for EUROPE
    • Infocube 2: data for ASIA
    • Infocube 3: data for AMERICAS
    • Purpose: logical partitioning on Infoprovider level

Heterogeneous Multiprovider

• Only a subset of common characteristics / key figures
• Integrating scenarios that share some semantics combine differing aggregation levels (e.g. plan – actual scenarios)

How to define a multiprovider?

Transaction RSDMPRO

• select the participating infoproviders
• select participating characteristics (out of all chars that are available in the partproviders)
• select participating key figures (out of all kyfs that are available in the partproviders)
• define mapping rules for characteristics
• define mapping rules for key figures

• Important Table
  • RSDICMULTIIOBJ – assignment infoobjects <-> partprovider (mapping rules)
• Transactions
  • RSDIPROP
  • RSDMPRO
• Reports
  • report RSR_MULTIPROV_CHECK  - run this report with flag 'rebuild' to update the run time object for a multiprovider. In this way to make sure metadata buffer is consistent.

Three Very Simple Multiproviders

The following schematic display of MultiProviders should help to get an idea of the basic concept: Examples

See also: MultiProvider: Inconsistent Mapping of Navigation Attribute.

Queries based on MultiProviders

Three very simple multiprovider queries

The following examples should help to better understand how queries work, in particular when certain partproviders are omitted: Examples

Multiprovider Query Processing

• A query defined on a Multiprovider is physically split into sub-queries (accessing the partproviders) which are processed in parallel in order to improve the performance. The default parallel degree = 6 for BW7x systems which can be changed by an RSADMIN parameter as discussed in SAP note 895530. It is possible switch off parallel processing for specific queries in RSRT -> button 'Query Properties', for more information please click here.

• In RSRT there is a button called 'Execute&Debug' which offers many helpful functions (e.g. 'show SQL statement', 'no parallel processing', 'Multiprovider Explain' and many more - please see SAP note 1591837). The function 'Multiprovider Explain' displays details on how a multiprovider query is split up and which partproviders were read - please see SAP note 489135 and Online Docu for further details. The following simple example should help to understand the meaning of the most important messages: Examples

Buffering of the MultiProvider Runtime Object

There is an identification table (RSDICMULTIIOBJ) for a MultiProvider which describes which InfoObject of the MultiProvider is identified with which InfoObject of the PartProvider. This table can become big and stores also redundant information (in case of homogeneous PartProviders). Therefore the system buffers the necessary records in order to improve the runtime.
Errors in the runtime objects, which could have developed with inconsistent program statuses, can be eliminated with the help of the report RSR_MULTIPROV_CHECK. It can be used to delete and recreate the buffered MultiProvider runtime object.
The report RSR_MULTIPROV_CHECK is not required in normal operation. During the rebuild, all additional checks of the OLAP processor are
executed, and all errors and warnings are displayed.

Pruning (Logical Partitioning, RRKMULTIPROVHINT)

If a MultiProvider or HCPR is based on many PartProviders, it is useful to use 'pruning' for this Provider. The query workload is then reduced by checks to determine whether an PartProvider contains any data for the selection range of the query. InfoProviders that are not relevant are then not queried at all. In case of SPOs(Semantically Partitioned Objects) and Semantic Groups, the pruning is done automatically according to the definitions of these objects.

There are different ways how pruning can be used for queries:

• Based on the definition of a constant (InfoObject, Provider Specific Property)
• Based on a restriction of metadata:
  • Semantically partitioned Objects: SPO
  •  Pruning based on the InfoProviders involved: report RSPP_PART_MAINTAIN
  • Semantic Groups
  • ADSO where InfoObjects are restricted by so called 'Criterias'
• Based on the posted data: subqueries on InfoCubes using RRKMULTIPROVHINT

In case prunig does not work as expected for a certain query, follow the check list of note 2228499.

A detailed discussion of this topic can be found in the fiollowing wikwi page:

Improving BW Query Performance by Pruning

SAP Consulting Notes

Please click on the number to get the note displayed: