Show TOC

Background documentationProcessing Queries Locate this document in the navigation structure

 

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.

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:

  • 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 debugging 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.

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.