Parallelization of Subqueries Versus
Sequential Processing 
Use
A query based on a MultiProvider is divided internally into sub-queries. There is a sub-query for each InfoProvider included in the MultiProvider. Refer to: Dividing a MultiProvider Query into Sub-Queries
By default, the existing subqueries are processed in parallel. This means that the existing sub-queries (usually one for each sub-InfoProvider) are sent in parallel. The results of these sub-queries are collected at a synchronization point and united to form an overall result.
In sequential processing, the sub-queries are sent one after another. An interim result is immediately passed on to the BW OLAP Engine. This brings the advantage of preventing the storage of what could be a very large overall result in the main memory of the application server. Nevertheless, this is usually accompanied by a loss in performance.
Functions
In the following cases, the system chooses a sequential (non-parallel) processing:
· An entry <technical name of MultiProvider> appears in the RSADMIN table with the value (column VALUE) NOPARALLEL.
· The MultiProvider query runs in a batch process.
· The MultiProvider query was initiated via the query monitor (transaction RSRT) using various debug options (SQL queries display, execution plans display, for example). Refer to: Dividing a MultiProvider Query into Sub-Queries
· The query requests non-cumulative key figures.
· Insufficient free dialog processes are available at the time of execution. These are required for parallel processing.
· The result of the MultiProvider query is to be saved in a file or a table.
In the following case, parallel processing is terminated, then automatically restarted and sequentially processed:
In cases where the interim result of a MultiProvider query started in parallel is too large (more than 30000 records), the system terminates the parallel processing. This is to prevent memory overflow. The query is then automatically processed sequentially.
Avoiding Termination of the Parallel Processing
Termination of parallel processing results in a loss of performance. If you want to improve the performance of a query for a MultiProvider, you can firstly check how the sub-queries are processed.
Execute the query via the query monitor (transaction RSRT) with the option Execute + Debug. Choose the MultiProvider Explain option. You can see messages in the upper part of the screen that displays the query result. Message DBMAN 146 shows you that parallel processing was terminated during query execution and the system restarted the process with sequential processing.
In
such cases, we advise you to deactivate parallel processing for the
MultiProvider. These functions can be found in the query monitor under query
properties. For more information, see 
Not Using Parallel
Processing.
With the indicator Not Using Parallel Processing, the table RSADMIN receives the value NOPARALLEL for this MultiProvider in the Value column. As a result, the sub-queries for this MultiProvider are processed sequentially from the start. This avoids the loss in performance resulting from the termination.
Nevertheless, this now means that all queries for this MultiProvider are processes sequentially, including those that could be successfully processed in parallel. You can use a command to circumvent this disadvantage:
Alternative Procedure:
We assume you have a MultiProvider M with queries Q1 and Q2. Q1 can be successfully processed in parallel, whereas parallel processing terminates with Q2. Proceed as follows:
...
1. Create a new MultiProvider M’ as a copy of M.
2. Deactivate parallel processing for the new MultiProvider M’. MultiProvider M should allow parallel processing however.
3. Copy query Q2 from MultiProvider M to MultiProvider M’. Do so via the SAP Menu, Business Explorer ® Query ® Copy.
4. Delete the query Q2 for MultiProvider M.
Using this constellation, all queries for M are now executed in parallel, and all queries for M’ sequentially. To a certain extent, M’ is the MultiProvider for the problematic queries.