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 a MultiProvider, and the selection conditions dictate that the data has to be read from multiple 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 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 in the default setting.
Multiple 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 the other. The interim result is immediately passed on to the analytic manager.
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.
There are not enough dialog processes 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. All queries that are based on non-cumulative InfoCubes are therefore divided into sub-queries that are separated from 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.