Hierarchy
SAP_BW (Software Component) SAP Business Warehouse⤷
BW (Application Component) SAP Business Information Warehouse⤷
RS (Package) BW: General Business Information Warehouse
Basic Data
| Data Element | RRSNOPARALLEL |
| Short Description | no parallel processing |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | RS_BOOL | |
| Data Type | CHAR | Character String |
| Length | 1 | |
| Decimal Places | 0 | |
| Output Length | 1 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 12 | no paral- |
| Medium | 16 | no paral.process |
| Long | 30 | no parallel processing |
| Heading | 30 | no parallel processing |
Documentation
Use
Parallel processing can be deactivated for an individual query. This can be beneficial because the query then uses fewer system resources if you use non-parallel processing.
In the case of queries with very fast response times, the effort required for parallel processing can be greater than the achievable time gain. In this case, it may also make sense to turn off parallel processing.
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 data has to be read from a number of InfoProviders on account of the selection conditions. See Dividing a MultiProvider Query into Sub-Queries.
- The query contains complex selections, like calculated or restricted key figures with hierarchy conditions. In this case, the selections are split and accessed individually. This is similar to the process for using 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
To run queries in parallel, multiple dialog work processes are required. The maximum degree of parallel processing determines the maximum number of work processes used for each query. In the default setting, this is set to 6. The maximum value can be changed to 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:
- Entry QUERY_MAX_WP_DIAG is set to 1 in the VALUE column in table RSADMIN.
- The entire query is made up of just one part access.
- The query runs in a batch process.
- The query was started from Query Monitor (transaction RSRT) using various debug options (like SQL query display, execution plan display). See Dividing a MultiProvider Query into Sub-Queries.
- The query is for non-cumulative key figures.
- Not enough 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.
The system can efficiently manage large intermediate results produced by parallel processing. In previous releases, the system terminated when it reached a particular intermediate result size and switch to sequential processing. This is no longer the case. The RSADMIN parameter used in previous releases for reading a MultiProvider sequentially is therefore no longer used.
Partial Parallel Processing
Queries that are based on non-cumulative InfoCubes use a lot of memory space and are therefore not suited for parallel processing. This behaviour can be changed by setting NCUM_PARALLEL_PROC in table RSADMIN by entering 'X' in the VALUE column. Parallel processing is then also possible for non-cumulative accesses.
There are also special Infoproviders whose implementation requires interaction with and access to main memory structures in the Analytical Engine, such as information about hierarchy drilldown attributes. These providers also have to be processed sequentially.
All non-parallelized accesses of this type are separated from the other sub-queries. Firstly, the #normal# sub-queries are processed in parallel. The sub-queries that cannot be processed in this way are then processed sequentially.
Features
If you select Do Not Use Parallel Processing, the selected query will be processed sequentially in future.
History
| Last changed by/on | SAP | 20130604 |
| SAP Release Created in | 20B |
