SAP Netweaver Business Intelligence BI / BW

Symptom

This note describes several technical query attributes in detail and recommends ways to set them.
Note 1022589 describes how you can check or set default values relevant for the InfoProvider and how you can reset attributes for several or all queries at the same time.
Note 1138864 describes the delta cache process in more detail.

Other terms

RSRT, query attributes, RSDIPROP, delta cache, ACTUALDATA, PARTITIONMODE, MultiProvider, hierarchy, CACHEDELAY

Reason and Prerequisites

The OLAP processor offers many options to optimize the reading of data.
As a result, the use of aggregates or a BIA index and the OLAP cache is reconciled and optimized with the special features of the query and the features of the different provider types.
In MultiProviders that have InfoProviders merged with several features, the processing should not be based on the weakest InfoProvider. Rather, each InfoProvider should not be more poorly processed in the MultiProvider than it is in a query that is defined seperately on this InfoProvider
In particular, the feature to deliver SID, to process hierarchies or to support the delta process of the OLAP cache are relevant here.
In addition, queries are often used for specific purposes; for example, queries for checking the completeness and accuracy of the data, queries for creating a data mart or queries for precalculating Web templates.
The optimal settings for these operating methods are usually different to the standard settings and, in particular cases, must be tested and adjusted seperately regarding performance and main memory requirements.
In particular, there should be a setting (for queries that are executed at the margins of technical possibility in 3.X), which delivers the same behavior in 7.0 and, therefore, does not require more main memory.
The special features of an input-ready query or a query within a planning template are to be taken into account.

Solution

This note describes the individual attributes and their values, and the data element documentation, which you should have studied before reading this note are discussed more technically and in more detail. In particular, it is difficult to understand how the individual attributes interact. This depends on when and how often the data is loaded, how much data is displayed and how you navigate in the query.
Note that the default values of the system (if they were determined correctly in accordance with Note 1022589) are usually a good option for normal querys. Several settings are useful in only very specific situations.
Read mode (RSRREADMODE):
As described in the documentation for the data element RSRREADMODE, the read mode should be set to “H”. The system automatically changes the read mode to “X” for InfoProviders that do not support hierarchies.
Small hierarchies (less than 100 nodes and leaves -> RSRHIEDIR_OLAP-READMODE) are always read completely. Furthermore, an optimization is implemented to read all the subnodes (”grandchildren” and “great-grandchildren”) immediately when you expand a hierarchy node, provided the node has only a few “children”.
Request status/data validity (RRACTUALDATA):
This generalizes and refines the 3.X variables 0S_RQMRC, 0S_RQTRA and 0S_RQALL to the “chatacteristic” 0REQUID (most recent query).
The effect of ACTUALDATA for various InfoProviders is entered in the following table. The table applies to the InfoProvider itself and to the InfoProvider of a MultiProvider.
+——————————————————————–+
| InfoCube / InfoProvider || ACTUALDATA ||Delta- |
+—————————-||—–|—–|—–|—–|—–||——-|
|TRANSACT AGGR PLANNING || 0 | 1 | 2 | 3 | 9 ||Cache=X|
+—————————-||—–|—–|—–|—–|—–||——-|
| – X – ||R| R | Q | G | A || R |
| – – – ||Q| Q | Q | G | A || Q |
| X X – || R |Q| Q | G | A || R / Q |
| X – || Q |Q| Q | G | A || Q |
| X X X || R |A| A | A | A || R / Q |
| X X || Q |A| A | A | A || Q |
+—————————-||—–|—–|—–|—–|—–||——-|
| IF_RSD_DELTA_CACHE_SUPPORT ||RQTS0|(1)| A | A | A || RQTS0 |
| RSDCUBE-CACHEDELAY ||(2)| (2) | A | A | A || A |
| others ||A| A | A | A | A || A |
+——————————————————————–+
TRANSACT (in the first six lines) is a transactional InfoCube (RSDCUBE-TRANSACT “X”), AGGR “X” means that aggregates (for example, a BIA index) are created for the InfoCube, and PLANNING indicates whether the transactional InfoCube is currently set to planning or loading.
In the seventh line there are InfoProviders, for which the delta process is implemented. The eighth line is a virtual InfoCube, for which a CACHEDELAY time is set in the RSDCUBE. ACTUALDATA does not influence the other InfoProviders; they are always read completely.
In the column for ACTUALDATA, the following mean that:
Rall requests that are smaller or the same as RSMDATASTATE-ROLLUP
Qall requests that are smaller or the same as RSMDATASTATE-QUALOK
Gall green (and not yellow or red) requests
Aall data including, for example, started yellow or red requests
are read.
RQTS0is exactly the value that is issued from the method GET_RQTS for the data characteristic.
(1)Depends on the attribute N_LIKE_TRANSACT.
(2)For virtual InfoCubes with a CACHEDELAY greater than 0, only the data is read again when you start the query, if the data of the cache is older than the CACHEDELAY specified.
All other InfoProviders are always read completely. However, the ACTUALDATA of the relevant InfoProvider can be specified for the definition of an InfoSet.
The system proposal is highlighted.
The last column specifies which part of the read data is written to the cache if DELTACACHE is “true”. If CACHEMODE is greater than 0, DELTACACHE is false and ACTUALDATA is less than 9, all read data is written to the cache. However, this must usually be rejected soon.
When you generate a query, the 3.X requid variables are translated to the values of ACTUALDATA and maximized with the query settings:
0S_RQTRA -> ACTUALDATA “1″
0S_RQMRC -> ACTUALDATA “3″
0S_RQALL -> ACTUALDATA “9″
Note that the 3.X 0S_RQMRC is not exactly the same as the 7.x ACTUALDATA “3″. ACTUALDATA “3″ still even reads green requests that are larger than a red or yellow InfoCube request. In 3.X, the system reads only to TECHOK for 0S_RQMRC. Furthermore, the requid variables influence only Basis InfoCubes.
Cache mode (RSRCACHEMODE, RSRPERSISTMODE):
Here, the OLAP cache is activated and the cache mode is set. If the cache objects are to be persistent, you can specify the storage medium in RSRPERSISTMODE.
Delta cache (RRDELTACACHE):
In addition to partitioning (see below), the delta cache is the most important performance improvement to 7.X. If you treat the (persitent) OLAP cache as a query-specific aggregate, the delta cache process corresponds to the aggregate rollup.
In each cache object, the “watermark” is kept for each InfoProvider in the same way as RSMDATASTATE. Theerefore, the system notes to which request ID the data is read in the cache object. To use the cache object, only the new requests added are read. These are assigned to the cache object via “collect” and the cache object is written back afterwards.
An equivalent to the change run; that is, an adjustment to the cache object during master data changes or hierarchy changes, is not (and will not be) supported.
To read the requests missing for a cache object, 0REQUID must still be visible in the InfoCube. If the system automatically compresses an InfoCube when loading, the delta process is ineffective since the delta can no longer be accessed. If the system compresses the aggregates after the rollup, the delta process loses a lot of its effectiveness. However, the system can still decide to read the delta requests from the fact table, or completely from the aggregate. The system actually tries to optimize this.
An InfoProvider can participate in the delta process if a class, which implements IF_RSD_DELTACACHE_SUPPORT, is specified for it. In addition to the normal Basis InfoCubes, this is currently the case only for the virtual InfoCubes of SEM-BCS (CL_RSSEM_DC_SUPPORT_VP_BCS).
For the rest of the InfoProviders or for queries with DELTACACHE “false”, the OLAP cache behaves as it does in 3.X. The cache object must be rejected as soon as new data is added. However, the determination of the timestamp (CL_RSD_DTA->GET_DATA_TIMESTMP) is improved.
As a result, for example, InfoSets are also capable of cache.
SP grouping (RRSPPARTITION):
The disadvantage to 3.X is that the cache capability and the read mode for a query on a MultiProvider have to conform to the weakest InfoProvider used. Therefore, the system automatically sets the read mode to “X” and deactivates the cache when the MultiProvider contains only one virtual InfoCube in addition to many InfoProvider (cube).
In 7.0, the system can read, cache and process the data of the various InfoProviders seperately in the OLAP processor. Shortly before the output to the front end (that is, before formulas, conditions and exceptions are calculated and before sorting), the data of the “partitions” (identified internally by the field CGID) must be merged again.
You get the typical conflict between runtime optimization and memory space optimization
due to this partitioning.
PARTITIONMODE “0″is used to conserve main memory;
PARTITIONMODE “1″should be an appropriate compromise and is the default value;
PARTITIONMODE “2″is useful if the individual InfoCubes of the MultiProvider are loaded and immediately compressed at different times.
PARTITIONMODE “3″is rarely useful.
This partitioning is used by the OLAP processor to solve other internal tasks in addition to the optimization of the InfoProvider regarding read mode and cache capability, Currently (7.0, Support Package 17), the structure elements with constant selection are created in user-defined partitions.
Furthermore, for a query with ACTUALDATA greater than 0, the system writes all data that is greater than the saved status (ROLLUP) to a specific partition.
Finally, there is a user-defined partiton for the near-line storage data.
Default values (also refer to Note1022589):
The system cannot automatically find the optimal setting for the many options and influencing factors. However, the system should usually provide an appropriate proposal, which you should change only if necessary:
Read mode “H”
Request status “0″ or “1″, if the MultiProvider contains a transactional InfoCube,
Cache mode “1″ or higher,
Delta cache “true”,
SP grouping “1″
Examples:
1.Plan/Actual comparison
MultiProvider “M” (A,P,V) consists of InfoCube “A” for actual data, transactional InfoCube “P” for planning data and virtual InfoCube “V”. The actual data should be visible only after the load and check, and after the aggregates are rolled up. Planning data should be visible immediately.
By using read mode “H”, request status “1″, delta cache “true” and SP grouping “1″, you get the following:
Three partitions are used with:
CGID “1″ for the data from “A” with a request smaller than ROLLUP, and the data from “P” with a reuest smaller than QUALOK
CGID “3″ for the data of virtual InfoCube “V” and
CGID “-1″ for the yellow open request of transactional InfoCube “P”.
The data for CGID “1″ is taken from the cache. If a new request is loaded for “A” or a yellow request of “P” is closed automatically, then only this is read in the delta reading process and added to the relevant cache object. The data of the virtual InfoCube CGID “3″ can be used from the cache until the CACHEDELAY time is exceeded (also refer to Note 822302). The CGID “1″ contains the open yellow request of planning InfoCube “P” exactly, if it exists. CGID “-1″ cannot be cached.
The yellow open request of a transactional InfoCube is closed automatically after approximately one hour if no new data is posted. With this setting, the query can obtain its data completely from the cache even though it displays current data.
A presentation hierarchy is read for CGID “1″ when you expand it (read mode “H”); the hierarchy is read completely for CGID “3″ and “-1″.2.System behaving like 3.X:
The setting
read mode “H”, cache mode greater than “0″, delta cache “false” and SP goruping “0″
should ensure that the system behaves exactly the same as in 3.X.
3.Minimizing the memory requirement:
Queries are often used in some way to create a dataset and a bottleneck may occur in the main memory. Therefore, it is not useful to generate an OLAP cache in this case. We recommend:
Read mode “H”, cache mode “0″, and SP goruping “0″.
In this case, only one partition is created for a request status that is greater than “0″.4.Check query
If you use a query like a Listcube to technically check the data or just to check its existence, the request status should be set to “9″. This automatically deactivates the cache and the system reads all the red requests (dirty read).5.Hosting query
The data is loaded to an InfoCube from semantically different data sources, in which each of these loading processes receives a user-defined request. By setting the request status to “3″, you may be able to display the following green (successfully loaded) requests, even though one or more of the loading processes were terminated previously and are, therefore, red requests.6.Input-ready query
Input-ready queries play an important role; they are queries that contain an aggregation level as an InfoProvider on an aggregation level or on MultiCubes. The following is a detailed explanation.
The OLAP processor is provided with the data of InfoProvider “P”, which can be planned not directly, but as a special virtual InfoProvider “A” of type ALVL. In an application (Web or Excel) that contains an input-ready query, planning data that is created or changed by input or a planning function is visible immediately for all queries and items. This applies not just to queries that are defined on aggregation level “A” but to all queries that are defined in InfoProvider “P” itself (which can be planned) or in a MultiProvider “M” (which contains P or A as an InfoProvider) or another aggregation level “A1″ using “P”.
Queries in “P” or “M” in the same application sensitize themselves automatically to all new data of InfoProvider “P”, even data that has not yet been saved . Furthermore, it is irrelevant in which sequence the items are processed or if the planning item is started subsequently for the first time.
Queries that were not created originally for planning and that are added to a planning application to display, for example, the affects of the new planning data immediately, that is, before you save (control query), automatically switch to current data, regardless of their setting in RSRT.
Technically, this is implemented by the delta buffer. Within the application, the changed or new planning data is kept in a delta buffer for each InfoProvider “P” to be planned. When you create delta buffer “Dp” for “P”, all application queries that obtain data from “P” are internally set to ACTUALDATA “1″ with regard to “P”automatically, and are sensitized to the data of delta buffer “Dp”. New planning deltas are added in the delta reading process of all queries affected.
When you save the planning data, the system writes the data of the delta buffer(s) to the database, the delta buffers are deleted, it is unlocked and all application queries affected are rebuilt.
Aggregation level “A” is implemented internally by the automatically created query “P/!!1P” (plan buffer query). This query acts like an InfoProvider. It reads the data of the database or provides the data from InfoProvider “P”, it adds the data of the delta buffer “Dp” (or the delta buffer Dpi if P is a MultiProvider with several PartProviders Pi that can be planned) and transfers the data manager as data of the InfoProvider “A” of type “ALVL”. The query “P/!!1P” can use aggregates and the cache; this is exactly like each normal query in “P”. If “P” is a MultiProvider, it is useful to set PARTITIONMODE to “1″.
For the query “P/!!1P” that is created automatically for an aggregation level or for all aggregation levels using the InfoProvider P, we recommend the following setting:
Read mode “H”, request status “1″, cache mode “1″ or higher, delta cache “true” and SP grouping “1″.
Furthermore, the selection to use the structure element (KIDSEL) should be “true”.
The input-ready queries in “A” should not, and cannot, use a cache. The request status is irrelevant since queries in “A” are automatically set to current data. The delta buffer does not currently support hierarchy processing. Therefore, aggregation level “A” cannot completely support read mode “H”. For input-ready queries at A:
Read mode “X”, request status “0″, cache mode “0″.
The delta cache and SP grouping are not visible.