Processing Queries 

A query can be divided into sub-queries by the system. This division is performed in the following circumstances:

●      The query contains cells with a constant selection or other definitions that cannot be read using a logical read operation.

●      The query is defined on the basis of a MultiProvider and, due to the selection conditions, data has to be read from a number of InfoProviders. See, Dividing a MultiProvider Query into Sub-Queries.

●      The query contains complex selections, such as calculated or restricted key figures with hierarchy conditions. In this case, the selections are split and accessed individually. This is similar to the process performed in order to use InfoCube aggregates.

●      The query is defined on the basis of an InfoCube, both fact tables contain data, and the database view does not use both fact tables to read the InfoCube.

If dividing the query results in more than one sub-query, the read operation is performed in parallel by default.

Parallel Processing

Several dialog work processes are required in order to execute queries in parallel. The maximum degree of parallelism determines the maximum number of work processes that are used for each query. This value is restricted to 6 by default. The maximum value can be changed to a value between 1 and 100 in the QUERY_MAX_WP_DIAG entry in table RSADMIN.

The actual degree to which queries are executed in parallel depends on the load on the system at any given time and lies between 1 (sequential processing) and the maximum value. If the number of sub-queries is greater than the maximum level of parallelism, all existing sub-queries are divided between the work processes determined by the degree of parallelism.

The results of all sub-queries are collected at a synchronization point and collated to form an overall result.

In sequential processing, the sub-queries are processed one after another. The interim result is immediately passed on to the analytic engine.

Sequential Processing

In the following cases, the system chooses sequential (non-parallel) processing:

●      In table RSADMIN, entry QUERY_MAX_WP_DIAG has value (column value) 1.

●      The entire query consists of one sub-access only.

●      The query is running in a batch process.

●      The query was started from the query monitor (transaction RSRT) using various debug options (for example, SQL query display, execution plan display). See, Dividing a MultiProvider Query into Sub-Queries.

●      The query requests non-cumulative key figures.

●      Insufficient dialog processes are available when the query is executed. These are required for parallel processing.

●      The query is configured for non-parallel processing.

●      You want to save the result of the query in a file or a table.

In Release SAP NetWeaver 7.0, the system can efficiently manage the large intermediate results produced by parallel processing. In previous releases, the system terminated when it reached a particular intermediate result size and proceeded to read data sequentially. This is no longer the case. Therefore, the RSADMIN parameter that was used in previous releases for reading a MultiProvider sequentially is no longer used.

Partial Parallel Processing

Queries that are based on non-cumulative InfoCubes have a high memory consumption and cannot be processed in parallel. For this reason, all queries that are based on non-cumulative InfoCubes are divided into sub-queries that are separated from the other sub-queries. The ‘normal’ sub-queries are processed in parallel first and the sub-queries that are based on the non-cumulatives are processed sequentially afterwards.