Not Using Parallel Processing 

Use

Parallel processing of a MultiProvider query is cancelled as soon as the overall result of sub-accesses to the InfoProvider involved with the MultiProvider exceeds 30,000 rows. The MultiProvider query is then automatically restarted and processed sequentially.

Because of this it seems as though it is quicker to process queries of this type sequentially. In reality, the parallel processing of that appears to be worse is equivalent to the subsequently executed sequential processing.

To save yourself unnecessary costs incurred by canceling parallel processing, change to sequential processing for these crucial queries.

Integration

Regarding entries in RSADMIN, follow these proposed solutions:

·        Switch off parallel processing for the MultiProvider for all queries

·        Copy the MultiProvider, switch off parallel processing for the copied MultiProvider, and assign queries not suitable for parallel processing to this MultiProvider

·        Parameterize the maximum possible size of overall results.

You will find additional information under Parallel Processing of Sub-Queries vs. Sequential Processing.

Prerequisites

You have identified the crucial queries in one of the following ways:

·        With MultiProviders that have the BI statistics data on queries specified, you are able to identify those queries that will have values of 30,000 or higher in the QDBTRANS column by using table RSDDSTAT (transaction SE16).

Make sure that not all queries executed in RSDDSTAT with QDBTRANS>= 30000 are included, but just those that are defined for a MultiProvider.

·        You are able to execute a query in transaction RSRT using  Execute + Debug" with the  MultiProvider Explain debug option. The system displays a message if parallel processing was cancelled and sequential processing started when a query was executed.

Features

If you choose the option Do Not Use Parallel Processing the selected query will be sequentially processed in future.